You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Samisa Abeysinghe <sa...@gmail.com> on 2006/05/16 07:11:42 UTC
[Axis2] Breaking up independent components and moving those to WS-Commons
Hi All,
As Axis2/C is growing, it would be worth considering breaking up the
independent components as separate projects and move those to WS commons.
The possible components are:
1. Util
This has environment with allocator, log, error and thread structs,
containers (hash map, stack etc)
2. OM (AXIOM/C)
This includes parser abstraction, OM, SOAP and MTOM related stuff
3. XML Schema
XML schema parsing based on OM
4. WSDL implementation (Wooden/C)
WSDL parsing support for both 1.1 and 2.0 versions
5. Guththila parser
We would also like to have Sandesha/C and Neethi/C
The above has to be moved into WS-Commons project. The benefit is that
those who want to use them as independent components can easily use them.
If we are to move them, this is the right time, as it would be hard to
manage it looking at the phase we are developing the stuff.
There would surely be some concerns, e,g, what happens to prefix of OM
methods, do we have to change it from axis2_om to axisom? IMHO, we
better keep the current prefix.
Thanks,
Samisa...
Re: [Axis2] Breaking up independent components and moving those to
WS-Commons
Posted by Samisa Abeysinghe <sa...@gmail.com>.
OK, At least for the time being, lets have seperate build systems for
seperate components
Thanks,
Samisa...
Samisa Abeysinghe wrote:
> Damitha Kumarage wrote:
>
>> Hi Samisa,
>> AFAIK Commons projects are well fermented, well tested projects.
>> AXIOM/C, Util may be suitable to be moved there.
>
>
> Is it the case that we only can have completed project in commons? I
> am not sure on this. Even if that is the case, XML Schema and Woden
> are not to be held within Axis2/C, so at least they have to be moved
> to a scratch pad or a sandbox section in svn, for sure Axis2/C cannot
> have them.
>
> I am specially annoyed at the fact that there are packing problems due
> to long names of XML schema. This would not happen if it was a
> seperate project. I really had a hard time packaging the release due
> to problems casued by XML schema, I would like them fixed now rather
> than wating till late.
>
> Also we have to test them as independant project, with independent
> build systems etc. Hence better move now rather than waiting till last
> minute.
>
> Samisa...
>
>> But XML Schema C and Woden C are not even finished yet. I suggest to
>> keep these two projects inside Axis2 C until they are matured within
>> Axis2 C.
>> thanks
>> Damitha
>>
>> Samisa Abeysinghe wrote:
>>
>>> Hi All,
>>> As Axis2/C is growing, it would be worth considering breaking up
>>> the independent components as separate projects and move those to WS
>>> commons.
>>> The possible components are:
>>> 1. Util
>>> This has environment with allocator, log, error and thread
>>> structs, containers (hash map, stack etc)
>>> 2. OM (AXIOM/C)
>>> This includes parser abstraction, OM, SOAP and MTOM related stuff
>>> 3. XML Schema
>>> XML schema parsing based on OM
>>> 4. WSDL implementation (Wooden/C)
>>> WSDL parsing support for both 1.1 and 2.0 versions
>>> 5. Guththila parser
>>>
>>> We would also like to have Sandesha/C and Neethi/C
>>>
>>> The above has to be moved into WS-Commons project. The benefit is
>>> that those who want to use them as independent components can easily
>>> use them.
>>>
>>> If we are to move them, this is the right time, as it would be hard
>>> to manage it looking at the phase we are developing the stuff.
>>>
>>> There would surely be some concerns, e,g, what happens to prefix of
>>> OM methods, do we have to change it from axis2_om to axisom? IMHO,
>>> we better keep the current prefix.
>>>
>>> Thanks,
>>> Samisa...
>>>
>>
>>
>
>
Re: [Axis2] Use of AXIS2_CONFIGURATION_RESOURCE
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Ok, then the solution is to remove the deault location and error if
deploy is missing. If this is fair enough I am going to do this.
Samisa...
Sahan Gamage wrote:
>Hi,
>
>A grep on my svn copy gave me the following results :
>
>include/platforms/unix/axis2_unix.h:#define AXIS2_CONFIGURATION_RESOURCE
>"/usr/local/axis2/axis2.xml"
>include/platforms/windows/axis2_windows.h:#define
>AXIS2_CONFIGURATION_RESOURCE "" /* should be set */
>modules/core/deployment/dep_engine.c:
>AXIS2_STRDUP(AXIS2_CONFIGURATION_RESOURCE, env);
>modules/core/deployment/dep_engine.c: dep_engine_impl->conf_name
>= AXIS2_STRDUP(AXIS2_CONFIGURATION_RESOURCE,
>modules/core/deployment/dep_engine.c: dep_engine_impl->conf_name
>= AXIS2_STRDUP(AXIS2_CONFIGURATION_RESOURCE, env);
>
>I exmined the dep_engine.c and it seems that the
>AXIS2_CONFIGURATION_RESOURCE is used as the default location for the
>axis2.xml. Bad thing is we haven't set it in Windows (or have set a
>path in Damitha's machine - which caused the JIRA)
>I think we can remove it and stop assuming the location. (i.e If it is
>not set we simply exit - no default locations)
>
>- Sahan
>
>Samisa Abeysinghe wrote:
>
>
>
>>What is the use of AXIS2_CONFIGURATION_RESOURCE? Are we not picking
>>the axis2.xml file from deploy folder?
>>
>>This is related to http://issues.apache.org/jira/browse/AXIS2C-152?
>>
>>Thanks,
>>Samisa...
>>
>>
>>
>
>
>
>
Re: [Axis2] Use of AXIS2_CONFIGURATION_RESOURCE
Posted by Sahan Gamage <sa...@wso2.com>.
Hi,
A grep on my svn copy gave me the following results :
include/platforms/unix/axis2_unix.h:#define AXIS2_CONFIGURATION_RESOURCE
"/usr/local/axis2/axis2.xml"
include/platforms/windows/axis2_windows.h:#define
AXIS2_CONFIGURATION_RESOURCE "" /* should be set */
modules/core/deployment/dep_engine.c:
AXIS2_STRDUP(AXIS2_CONFIGURATION_RESOURCE, env);
modules/core/deployment/dep_engine.c: dep_engine_impl->conf_name
= AXIS2_STRDUP(AXIS2_CONFIGURATION_RESOURCE,
modules/core/deployment/dep_engine.c: dep_engine_impl->conf_name
= AXIS2_STRDUP(AXIS2_CONFIGURATION_RESOURCE, env);
I exmined the dep_engine.c and it seems that the
AXIS2_CONFIGURATION_RESOURCE is used as the default location for the
axis2.xml. Bad thing is we haven't set it in Windows (or have set a
path in Damitha's machine - which caused the JIRA)
I think we can remove it and stop assuming the location. (i.e If it is
not set we simply exit - no default locations)
- Sahan
Samisa Abeysinghe wrote:
> What is the use of AXIS2_CONFIGURATION_RESOURCE? Are we not picking
> the axis2.xml file from deploy folder?
>
> This is related to http://issues.apache.org/jira/browse/AXIS2C-152?
>
> Thanks,
> Samisa...
>
[Axis2] Use of AXIS2_CONFIGURATION_RESOURCE
Posted by Samisa Abeysinghe <sa...@gmail.com>.
What is the use of AXIS2_CONFIGURATION_RESOURCE? Are we not picking the
axis2.xml file from deploy folder?
This is related to http://issues.apache.org/jira/browse/AXIS2C-152?
Thanks,
Samisa...
Re: [Axis2] Breaking up independent components and moving those to
WS-Commons
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Damitha Kumarage wrote:
> Hi Samisa
> Samisa Abeysinghe wrote:
>
>> Damitha Kumarage wrote:
>>
>>> Hi Samisa,
>>> AFAIK Commons projects are well fermented, well tested projects.
>>> AXIOM/C, Util may be suitable to be moved there.
>>
>>
>>
>> Is it the case that we only can have completed project in commons? I
>> am not sure on this. Even if that is the case, XML Schema and Woden
>> are not to be held within Axis2/C, so at least they have to be moved
>> to a scratch pad or a sandbox section in svn, for sure Axis2/C cannot
>> have them.
>>
>> I am specially annoyed at the fact that there are packing problems
>> due to long names of XML schema. This would not happen if it was a
>> seperate project. I really had a hard time packaging the release due
>> to problems casued by XML schema, I would like them fixed now rather
>> than wating till late.
>
>
> Oh, I already created two separate build systems for xml_schema and
> woden in the hope that they will be moved to a separate place in svn.
> But it seems that i have forgotten to remove the references to them in
> the main axis2 C build system. That's why it has given problems to
> you. I'll remove those references now.
Cool, that makes life much better :-)
Please updated the build.sh file as well to build these seperate projects.
Also lets seperate OM and UTIL build systems as well. This way we can
move those to commons one day with little effort.
Thanks,
Samisa...
>
> thanks
> damitha
>
>>
>> Also we have to test them as independant project, with independent
>> build systems etc. Hence better move now rather than waiting till
>> last minute.
>>
>> Samisa...
>>
>>> But XML Schema C and Woden C are not even finished yet. I suggest to
>>> keep these two projects inside Axis2 C until they are matured within
>>> Axis2 C.
>>> thanks
>>> Damitha
>>>
>>> Samisa Abeysinghe wrote:
>>>
>>>> Hi All,
>>>> As Axis2/C is growing, it would be worth considering breaking up
>>>> the independent components as separate projects and move those to
>>>> WS commons.
>>>> The possible components are:
>>>> 1. Util
>>>> This has environment with allocator, log, error and thread
>>>> structs, containers (hash map, stack etc)
>>>> 2. OM (AXIOM/C)
>>>> This includes parser abstraction, OM, SOAP and MTOM related stuff
>>>> 3. XML Schema
>>>> XML schema parsing based on OM
>>>> 4. WSDL implementation (Wooden/C)
>>>> WSDL parsing support for both 1.1 and 2.0 versions
>>>> 5. Guththila parser
>>>>
>>>> We would also like to have Sandesha/C and Neethi/C
>>>>
>>>> The above has to be moved into WS-Commons project. The benefit is
>>>> that those who want to use them as independent components can
>>>> easily use them.
>>>>
>>>> If we are to move them, this is the right time, as it would be hard
>>>> to manage it looking at the phase we are developing the stuff.
>>>>
>>>> There would surely be some concerns, e,g, what happens to prefix of
>>>> OM methods, do we have to change it from axis2_om to axisom? IMHO,
>>>> we better keep the current prefix.
>>>>
>>>> Thanks,
>>>> Samisa...
>>>>
>>>
>>>
>>
>>
>
>
Re: [Axis2] Breaking up independent components and moving those to
WS-Commons
Posted by Damitha Kumarage <da...@gmail.com>.
Hi Samisa
Samisa Abeysinghe wrote:
> Damitha Kumarage wrote:
>
>> Hi Samisa,
>> AFAIK Commons projects are well fermented, well tested projects.
>> AXIOM/C, Util may be suitable to be moved there.
>
>
> Is it the case that we only can have completed project in commons? I
> am not sure on this. Even if that is the case, XML Schema and Woden
> are not to be held within Axis2/C, so at least they have to be moved
> to a scratch pad or a sandbox section in svn, for sure Axis2/C cannot
> have them.
>
> I am specially annoyed at the fact that there are packing problems due
> to long names of XML schema. This would not happen if it was a
> seperate project. I really had a hard time packaging the release due
> to problems casued by XML schema, I would like them fixed now rather
> than wating till late.
Oh, I already created two separate build systems for xml_schema and
woden in the hope that they will be moved to a separate place in svn.
But it seems that i have forgotten to remove the references to them in
the main axis2 C build system. That's why it has given problems to you.
I'll remove those references now.
thanks
damitha
>
> Also we have to test them as independant project, with independent
> build systems etc. Hence better move now rather than waiting till last
> minute.
>
> Samisa...
>
>> But XML Schema C and Woden C are not even finished yet. I suggest to
>> keep these two projects inside Axis2 C until they are matured within
>> Axis2 C.
>> thanks
>> Damitha
>>
>> Samisa Abeysinghe wrote:
>>
>>> Hi All,
>>> As Axis2/C is growing, it would be worth considering breaking up
>>> the independent components as separate projects and move those to WS
>>> commons.
>>> The possible components are:
>>> 1. Util
>>> This has environment with allocator, log, error and thread
>>> structs, containers (hash map, stack etc)
>>> 2. OM (AXIOM/C)
>>> This includes parser abstraction, OM, SOAP and MTOM related stuff
>>> 3. XML Schema
>>> XML schema parsing based on OM
>>> 4. WSDL implementation (Wooden/C)
>>> WSDL parsing support for both 1.1 and 2.0 versions
>>> 5. Guththila parser
>>>
>>> We would also like to have Sandesha/C and Neethi/C
>>>
>>> The above has to be moved into WS-Commons project. The benefit is
>>> that those who want to use them as independent components can easily
>>> use them.
>>>
>>> If we are to move them, this is the right time, as it would be hard
>>> to manage it looking at the phase we are developing the stuff.
>>>
>>> There would surely be some concerns, e,g, what happens to prefix of
>>> OM methods, do we have to change it from axis2_om to axisom? IMHO,
>>> we better keep the current prefix.
>>>
>>> Thanks,
>>> Samisa...
>>>
>>
>>
>
>
Re: [Axis2] Breaking up independent components and moving those to
WS-Commons
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Damitha Kumarage wrote:
> Hi Samisa,
> AFAIK Commons projects are well fermented, well tested projects.
> AXIOM/C, Util may be suitable to be moved there.
Is it the case that we only can have completed project in commons? I am
not sure on this. Even if that is the case, XML Schema and Woden are not
to be held within Axis2/C, so at least they have to be moved to a
scratch pad or a sandbox section in svn, for sure Axis2/C cannot have them.
I am specially annoyed at the fact that there are packing problems due
to long names of XML schema. This would not happen if it was a seperate
project. I really had a hard time packaging the release due to problems
casued by XML schema, I would like them fixed now rather than wating
till late.
Also we have to test them as independant project, with independent build
systems etc. Hence better move now rather than waiting till last minute.
Samisa...
> But XML Schema C and Woden C are not even finished yet. I suggest to
> keep these two projects inside Axis2 C until they are matured within
> Axis2 C.
> thanks
> Damitha
>
> Samisa Abeysinghe wrote:
>
>> Hi All,
>> As Axis2/C is growing, it would be worth considering breaking up
>> the independent components as separate projects and move those to WS
>> commons.
>> The possible components are:
>> 1. Util
>> This has environment with allocator, log, error and thread
>> structs, containers (hash map, stack etc)
>> 2. OM (AXIOM/C)
>> This includes parser abstraction, OM, SOAP and MTOM related stuff
>> 3. XML Schema
>> XML schema parsing based on OM
>> 4. WSDL implementation (Wooden/C)
>> WSDL parsing support for both 1.1 and 2.0 versions
>> 5. Guththila parser
>>
>> We would also like to have Sandesha/C and Neethi/C
>>
>> The above has to be moved into WS-Commons project. The benefit is
>> that those who want to use them as independent components can easily
>> use them.
>>
>> If we are to move them, this is the right time, as it would be hard
>> to manage it looking at the phase we are developing the stuff.
>>
>> There would surely be some concerns, e,g, what happens to prefix of
>> OM methods, do we have to change it from axis2_om to axisom? IMHO, we
>> better keep the current prefix.
>>
>> Thanks,
>> Samisa...
>>
>
>
Re: [Axis2] Breaking up independent components and moving those to
WS-Commons
Posted by Damitha Kumarage <da...@gmail.com>.
Hi Samisa,
AFAIK Commons projects are well fermented, well tested projects.
AXIOM/C, Util may be suitable to be moved there.
But XML Schema C and Woden C are not even finished yet. I suggest to
keep these two projects inside Axis2 C until they are matured within
Axis2 C.
thanks
Damitha
Samisa Abeysinghe wrote:
> Hi All,
> As Axis2/C is growing, it would be worth considering breaking up
> the independent components as separate projects and move those to WS
> commons.
> The possible components are:
> 1. Util
> This has environment with allocator, log, error and thread structs,
> containers (hash map, stack etc)
> 2. OM (AXIOM/C)
> This includes parser abstraction, OM, SOAP and MTOM related stuff
> 3. XML Schema
> XML schema parsing based on OM
> 4. WSDL implementation (Wooden/C)
> WSDL parsing support for both 1.1 and 2.0 versions
> 5. Guththila parser
>
> We would also like to have Sandesha/C and Neethi/C
>
> The above has to be moved into WS-Commons project. The benefit is that
> those who want to use them as independent components can easily use them.
>
> If we are to move them, this is the right time, as it would be hard to
> manage it looking at the phase we are developing the stuff.
>
> There would surely be some concerns, e,g, what happens to prefix of OM
> methods, do we have to change it from axis2_om to axisom? IMHO, we
> better keep the current prefix.
>
> Thanks,
> Samisa...
>