converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 79:||Line 79:|
| * chat log Dec09 [http://wiki.apache.org/ws/Axis2/HackathonDec2005/chatlog]
* chat log Dec10 [http://wiki.apache.org/ws/Axis2/HackathonDec2005/chatlog10]
| * chat log Dec09 [[http://wiki.apache.org/ws/Axis2/HackathonDec2005/chatlog]]
* chat log Dec10 [[http://wiki.apache.org/ws/Axis2/HackathonDec2005/chatlog10]]
* Walk through a few simple scenarios (one-way message in, one-way out, req-resp, module engagement, data binding, etc) in the debugger and make a list of places people think need improving. Maybe make small changes as we go, and write down larger ones.
* Scan through open JIRA issues.
* Prioritize the above lists into work items and start fixing/coding.
* We'll hopefully get a bunch of actual work done here, but also let's assign specific action-items to invididuals for afterwards (I'm guessing we won't finish everything
In the hackathon when everybody got together .. if possible check the method signature consistancy in the ContextHierachy. Specially how the context are created out of configurations. I am thinking about something like for every context. e.g. XXConfiguration.createXXContext(MessageContext);
kind of methods and have it uniformly everywhere. And if possible discuss bit about the lifecycles of the Context in the server and the client side.
When do you have the hackathon? Can someone give me a ping? but Give up if I am offline. Got two exams monday and wednsday ..but will try to make it for at least for short time.
When I try to write the DynamicInvoker setting up the contexts is quite unintivitive me. (I mean not uniform). Pls dicuss it if possible.
- Client API support Attachments (like Axis 1.X)
- Use case: want to write an intermediary that peeks just the soap
headers and forwards messages with MTOM or SwA attachments. i don't think our users can implement this with current public API. They would have to muck around with the internals which can change. Also, we need streaming support similar to one that was added in Axis 1.3
- Dispatchers. Need a major rehaul. One additional use case we shoudl support is peek into a doc/lit message (say it uses echoRequest inside the soap body, while echo is the operation) and make sure that the dispatch happens correctly
- Codegen. for example in Axis 1.X we use wsdl:service/wsdl:port/@name as the name of the service, where as in Axis2 we seem to be using wsdl:portType/@name as the name of the service. we need a comprehensive comparison to make sure that we are doing the right thing.
- Decorating WSDL's at runtime. Need to work on the runtime api to make sure modules can indeed add stuff to the wsdl at runtime (like policy). May be we should hook up securitypolicy while we are at it as a test case.
To be done
AxisConfiguration abstraction so that it doesn't depend on a particular implementation. (Deepal & Glen)
phase handler stuff (Deepal & Glen)
- - engaging part - expressivity part - dis-engage part
- improved client API (Sanjiva)
- JIRA issues
- Axis2-332 Use of Local Transport instead of HTTP for tests
- removing the initialization of transports when we build the configuration
- differ service loading until first access
chat log Dec09 http://wiki.apache.org/ws/Axis2/HackathonDec2005/chatlog
chat log Dec10 http://wiki.apache.org/ws/Axis2/HackathonDec2005/chatlog10