Re: refactoring jaxws support
Axis2 refactoring is now done in trunk too. Currently, I'm *not* planning to refactor Axis since there isn't much interest in JAX-RPC based web services (unless of course somebody really wants it). Jarek On 9/27/07, Jarek Gawor [EMAIL PROTECTED] wrote: FYI, CXF refactoring is now done in trunk. Everything seems to be working and I can now install the cxf-deployer/car plugin onto the minimal assembly and successfully deploy and run JAX-WS (Serlvet-based) web services. I'll work on Axis2 next. Jarek On 9/19/07, Jarek Gawor [EMAIL PROTECTED] wrote: As we talked about making things more modular for 2.1, I'm planning to split the CXF and Axis2 modules into smaller units. The main purpose of the split is to separate the EJB bits from Servlet bits so that we can create a minimal server with JAX-WS support but without installing OpenEJB first. Separating the EJB bits from Servlet bits will require moving some code into new modules and creating a few new configs. It will probably require creating 2 new modules, and 2 new configs per each engine implementation and 2 new modules, 2 new configs for shared code and configuration. So at the end it might be quite a few new modules and configs (unless I find or somebody suggests a better way to split this up). This is just a plan right now and things might change as I work through it. Jarek
Re: refactoring jaxws support
FYI, CXF refactoring is now done in trunk. Everything seems to be working and I can now install the cxf-deployer/car plugin onto the minimal assembly and successfully deploy and run JAX-WS (Serlvet-based) web services. I'll work on Axis2 next. Jarek On 9/19/07, Jarek Gawor [EMAIL PROTECTED] wrote: As we talked about making things more modular for 2.1, I'm planning to split the CXF and Axis2 modules into smaller units. The main purpose of the split is to separate the EJB bits from Servlet bits so that we can create a minimal server with JAX-WS support but without installing OpenEJB first. Separating the EJB bits from Servlet bits will require moving some code into new modules and creating a few new configs. It will probably require creating 2 new modules, and 2 new configs per each engine implementation and 2 new modules, 2 new configs for shared code and configuration. So at the end it might be quite a few new modules and configs (unless I find or somebody suggests a better way to split this up). This is just a plan right now and things might change as I work through it. Jarek
Re: refactoring jaxws support
Excellent!!! thanks david jencks On Sep 27, 2007, at 12:23 PM, Jarek Gawor wrote: FYI, CXF refactoring is now done in trunk. Everything seems to be working and I can now install the cxf-deployer/car plugin onto the minimal assembly and successfully deploy and run JAX-WS (Serlvet-based) web services. I'll work on Axis2 next. Jarek On 9/19/07, Jarek Gawor [EMAIL PROTECTED] wrote: As we talked about making things more modular for 2.1, I'm planning to split the CXF and Axis2 modules into smaller units. The main purpose of the split is to separate the EJB bits from Servlet bits so that we can create a minimal server with JAX-WS support but without installing OpenEJB first. Separating the EJB bits from Servlet bits will require moving some code into new modules and creating a few new configs. It will probably require creating 2 new modules, and 2 new configs per each engine implementation and 2 new modules, 2 new configs for shared code and configuration. So at the end it might be quite a few new modules and configs (unless I find or somebody suggests a better way to split this up). This is just a plan right now and things might change as I work through it. Jarek
refactoring jaxws support
As we talked about making things more modular for 2.1, I'm planning to split the CXF and Axis2 modules into smaller units. The main purpose of the split is to separate the EJB bits from Servlet bits so that we can create a minimal server with JAX-WS support but without installing OpenEJB first. Separating the EJB bits from Servlet bits will require moving some code into new modules and creating a few new configs. It will probably require creating 2 new modules, and 2 new configs per each engine implementation and 2 new modules, 2 new configs for shared code and configuration. So at the end it might be quite a few new modules and configs (unless I find or somebody suggests a better way to split this up). This is just a plan right now and things might change as I work through it. Jarek
Re: refactoring jaxws support
Sounds great! +1 -Donald Jarek Gawor wrote: As we talked about making things more modular for 2.1, I'm planning to split the CXF and Axis2 modules into smaller units. The main purpose of the split is to separate the EJB bits from Servlet bits so that we can create a minimal server with JAX-WS support but without installing OpenEJB first. Separating the EJB bits from Servlet bits will require moving some code into new modules and creating a few new configs. It will probably require creating 2 new modules, and 2 new configs per each engine implementation and 2 new modules, 2 new configs for shared code and configuration. So at the end it might be quite a few new modules and configs (unless I find or somebody suggests a better way to split this up). This is just a plan right now and things might change as I work through it. Jarek smime.p7s Description: S/MIME Cryptographic Signature
Re: refactoring jaxws support
This sounds a great plan! What you proposed seems a intuitive way to do this... Lin Jarek Gawor wrote: As we talked about making things more modular for 2.1, I'm planning to split the CXF and Axis2 modules into smaller units. The main purpose of the split is to separate the EJB bits from Servlet bits so that we can create a minimal server with JAX-WS support but without installing OpenEJB first. Separating the EJB bits from Servlet bits will require moving some code into new modules and creating a few new configs. It will probably require creating 2 new modules, and 2 new configs per each engine implementation and 2 new modules, 2 new configs for shared code and configuration. So at the end it might be quite a few new modules and configs (unless I find or somebody suggests a better way to split this up). This is just a plan right now and things might change as I work through it. Jarek
