You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Saminda Abeyruwan <sa...@gmail.com> on 2008/06/12 18:27:17 UTC
Extensions to Axis2/Java deployment engine
Hi Devs,
Dims has started the work on providing the OSGi extension to Axis2. This
extension is a single bundle which consist of all the jars needed to run
axis2. It uses OSGi Bundle events to update AxisConfiguration. Main aspect
of OSGi is version and modularity. In order to get the full power of OSGi,
we need to consider the following,
1. Modules and Service loading
2. Using OSGi services
I would consider the first section. Second section has a broad scope and
lets discuss that in a separate thread.
With the OSGi, one could be able to write aar & mar as OSGi bundles. Thus,
when Axis2 start, one can give a repository where services & modules
available and one could use bundles to mimic this behaviour. When it's
come to bundles, they could either exist or remove from the system any-time.
This is dynamism of OSGi and this behaviour is currently not possible with
current module & service loading mechanism.
Current architecture requires, modules to be available first before services
are loaded, if modules are referenced by theses services. Thus, services
have a direct dependency to modules. Even if the service is not faulty, if
the referenced module is not available, that service become faulty. This
behaviour contradicts the nature of dynamic behaviour.
Thus, what would really need is modules to be loaded and initialize
orthogonal of service load and initialization. If loaded service reference
to a module that is not available yet, marked that service as "unresolved"
until the module is available. Once the module is available it would be
easily go thorough the "unresolved" services and marked the relevant
services as "resolved". Everything will be handle using OSGi events, which
is very powerful and flexible. There could be other events that make the
service "unresolved", but the major one is module.
Where there are 100s of bundles available in the system, its not practical
to assume a start level to bundles. These bundles may mimic Axis2
services/module or other 3rd party bundle.
I am totally fine with current deployment mechanism, but in order to obtain
a tighter integration we would have to revisit the current deployment
semantics. In addition to this standardizing this on Axis2 provide unique
user experience among the Axis2 community.
I am really appreciate if Axis2 folks comment on prior.
Thank you!
Saminda
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Correct. Deployment units of Axis2 will be aar/mar. What we are looking for
an extension from Axis2 kernel, which would allow to inject services and
modules as bundles. In order to achieve this, there are few deployment
semantics that needed to be addressed in kernel, it to be fully flexible.
Thank you!
Saminda
On Sat, Jun 14, 2008 at 5:20 AM, Nadir Amra <am...@us.ibm.com> wrote:
> Just want to make sure that the current deployment method for mars and web
> services (aar structure) is unchanged....you just want add additional
> feature which is support of OSGI, right?
>
> Nadir Amra
>
>
> "David Illsley" <da...@gmail.com> wrote on 06/13/2008 02:26:42 AM:
>
> > On Fri, Jun 13, 2008 at 7:56 AM, Deepal Jayasinghe
> > <de...@opensource.lk> wrote:
> > >
> > >> Hi Deepal,
> > >> I know decisions were made about various things before I was on the
> > >> scene,
> > >
> > > ;-)
> > >
> > > And we did not know about OSGi when we design Axis2.
> > >
> > >> but nothing is unchangable, and what Saminda is suggesting
> > >> sounds really cool and useful.
> > >
> > > I agree, but I do not like to change Axis2 fundamentals then are there
> ,
> > > because over 50K download taking place per month due to fact that
> people out
> > > there happy what Axis2 does now. So why worry of changing that. Thats
> the
> > > only worry I have. Just because OSGi is there and it is cool , we
> should not
> > > change our code base to support those. As I mentioned I have no
> objection
> > > on implementing new AxisConfigurator based on OSGi and do what ever
> we want
> > > , but I do not like changing the current core code base to support
> OSGi.
> > > Because I do not see a value of doing that.
> >
> > OK, so I disagree with this position. Yes, we get lots of downloads,
> > but those are of releases, and no-one is suggesting that big changes
> > should go in just before a release. I don't believe we would release
> > if something as fundamental as module deploy was broken - is there
> > some approach we can come up with that allows further innovation in
> > Axis2 without putting our release users at risk? What do you think?
> >
> > I personally think that OSGI is beyond just *cool* - It's the
> > foundation for a number of Java web services hosting environments
> > (including, but not limited to: Glassfish, SpringSource App Platform,
> > WebSphere, JOnAS, and BEA) and so better integration with it will be a
> > good thing.
> >
> > David
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Nadir Amra <am...@us.ibm.com>.
Just want to make sure that the current deployment method for mars and web
services (aar structure) is unchanged....you just want add additional
feature which is support of OSGI, right?
Nadir Amra
"David Illsley" <da...@gmail.com> wrote on 06/13/2008 02:26:42 AM:
> On Fri, Jun 13, 2008 at 7:56 AM, Deepal Jayasinghe
> <de...@opensource.lk> wrote:
> >
> >> Hi Deepal,
> >> I know decisions were made about various things before I was on the
> >> scene,
> >
> > ;-)
> >
> > And we did not know about OSGi when we design Axis2.
> >
> >> but nothing is unchangable, and what Saminda is suggesting
> >> sounds really cool and useful.
> >
> > I agree, but I do not like to change Axis2 fundamentals then are there
,
> > because over 50K download taking place per month due to fact that
people out
> > there happy what Axis2 does now. So why worry of changing that. Thats
the
> > only worry I have. Just because OSGi is there and it is cool , we
should not
> > change our code base to support those. As I mentioned I have no
objection
> > on implementing new AxisConfigurator based on OSGi and do what ever
we want
> > , but I do not like changing the current core code base to support
OSGi.
> > Because I do not see a value of doing that.
>
> OK, so I disagree with this position. Yes, we get lots of downloads,
> but those are of releases, and no-one is suggesting that big changes
> should go in just before a release. I don't believe we would release
> if something as fundamental as module deploy was broken - is there
> some approach we can come up with that allows further innovation in
> Axis2 without putting our release users at risk? What do you think?
>
> I personally think that OSGI is beyond just *cool* - It's the
> foundation for a number of Java web services hosting environments
> (including, but not limited to: Glassfish, SpringSource App Platform,
> WebSphere, JOnAS, and BEA) and so better integration with it will be a
> good thing.
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> OK, so I disagree with this position. Yes, we get lots of downloads,
> but those are of releases,
Yes, they download the release , because they happy what Axis2 does. If
they need any more feature they will ask about that. And I know a number
of users have asked about various things and they have created JIRA for
them.
> and no-one is suggesting that big changes
> should go in just before a release.
I agree.
> I don't believe we would release
> if something as fundamental as module deploy was broken - is there
> some approach we can come up with that allows further innovation in
> Axis2 without putting our release users at risk? What do you think?
>
Well , I have very good past experienced about Axis2 , if we change
something then we can not guarantee that all the stuff worked before
will work as it is. So if we do not see a problem with the way Axis2
works now , then let it be. Why we change that just because we think we
need to change. Our first priority should be our user community , if
they want something then we should consider doing that else , we should
not do critical changes to place like Kernel.
> I personally think that OSGI is beyond just *cool* - It's the
> foundation for a number of Java web services hosting environments
> (including, but not limited to: Glassfish, SpringSource App Platform,
> WebSphere, JOnAS, and BEA) and so better integration with it will be a
> good thing.
>
Oh no. Axis2 is not place where we copy idea from here and there. BTW
that web service stack has that cool feature how about we also doing
that is not there in Axis2, was not something we have followed. But I
know some of the Web service stack copied a number of things from us.
Which is ok , in open source software development. So if we want OSGi
since other web services stacks has that then we should think this twice.
I never ever told that it is a bad idea to have OSGi support , I even +1
for that. But only thing I am telling is lets do that out side the core.
Lets have a new module and handle OSGi support there. And do a separate
release artifact based on OSGi , what do you think about that ?
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal jayasinghe <de...@gmail.com>.
> Hi All,
>
> Writing an OSGi based AxisConfigurtor sounds reasonable. But this is
> not the only change that would require. AxisService builder has to
> change too.
> The association between modules and services are handle their. These
> builders are reside in kernel. This means, kernel has to change to
> support this integration. In essence to support OSGi integration some
> part of the kernel has to be changed indirectly.
Let's see whether we can do without doing that change. As I mentioned in
one my my previous mail also I will do my best to find a way around to
have OSGi support without doing core changes.
>
> On the other hand the created ConfigurationContext needed to be an
> OSGi service.
-1 , then Axis2 become full OSGi. Then if a person do not want OSGi then
he will be enforced to use OSGi which is not correct IMO. Please do not
do that.
As I know there are many more people who use Axis2 do not care about
OSGi , while only a few people are requiring OSGi support. So it is
community decision to take which part we are going to choose.
> In addition to this we need to use ManagedServices to integrate
> listeners and senders. This is a separate discussion which will be
> addressed later.
Oh , we are talking a *REALLY BIG* changes. Don't we have any other way
to do this I mean without doing that many changes.
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi All,
Writing an OSGi based AxisConfigurtor sounds reasonable. But this is not
the only change that would require. AxisService builder has to change too.
The association between modules and services are handle their. These
builders are reside in kernel. This means, kernel has to change to support
this integration. In essence to support OSGi integration some part of the
kernel has to be changed indirectly.
On the other hand the created ConfigurationContext needed to be an OSGi
service. In addition to this we need to use ManagedServices to integrate
listeners and senders. This is a separate discussion which will be addressed
later.
Thank you!
Saminda
On Fri, Jun 13, 2008 at 2:56 PM, Deepal jayasinghe <de...@gmail.com>
wrote:
> After reading all the mails , I still in the position that , YES we need to
> support OSGi. But , its better if we can do that without changing the core
> module. So I will help my best to write a OSGi based Axis configurator which
> does not touches the existing core code base (deployment side of it) , but
> will make sure to have what Saminda mentioned in the initial mail.
>
> Comments .... ??
>
> -Deepal
>
>>
>> Over in Apache Tuscany we're actively working on changing to have OSGi a
>> more integral part of the SCA runtime so anything Axis2 does to be more OSGi
>> friendly would be useful to Tuscany.
>>
>> ...ant
>>
>>
>> *Deepal Jayasinghe <de...@opensource.lk>*
>>
>> 13/06/2008 10:06
>> Please respond to
>> axis-dev@ws.apache.org
>>
>>
>>
>> To
>> axis-dev@ws.apache.org
>> cc
>>
>> Subject
>> Re: Extensions to Axis2/Java deployment engine
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi Venkat,
>>
>> I really appreciate your post , if there are users like who really need
>> OSGi , then we really should consider providing OSGi support out of the
>> box.
>> > I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
>> > our products which is built on equinox platform. If Axis2.0 features
>> > are available as OSGi bundles, it would help Axis2.0 adaption in
>> > future, I guess.
>> >
>> > - venkat
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> /
>> /
>>
>> /Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>> 3AU/
>>
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Yes it is. It's a separate jar and it's name is
org.apache.axis2.osgi_<version>.jar. :)
On Tue, Jun 17, 2008 at 5:47 PM, Davanum Srinivas <da...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Saminda,
>
> Can we please keep the OSGi stuff in separate maven module for now? We can
> still use maven magic to generate a
> axis2-kernel and axis2-adb jar with whatever you need inside, but as an
> artifact inside the OSGi maven module.
>
> That will avoid dragging in osgi jars in the main build and keep everyone
> happy till we convince them :)
>
> thanks,
> dims
>
>
> Saminda Abeyruwan wrote:
> | Hi Devs,
> |
> | First phase of the implementation plan is to use axis2-kernel, axis2-adb
> and
> | create the org.apache.axis2.osgi_<version>.jar bundle, which will salvage
> | some existing code from current Axis2 OSGi implementation. New
> | implementation will include the activator, builders, and most importantly
> | AxisConfigurator. I will package legacy jars as bundles and use the
> existing
> | bundles, which will be fully operational in Equinox. Will provide you
> with
> | the working sample asap.
> |
> | I wanted to write the activator and stuff to axis2-kernel and axis2-adb
> | itself. But for the first step lets provide this as an extension.
> |
> | Thank you!
> |
> | Saminda
> |
> | On Tue, Jun 17, 2008 at 12:27 AM, Tom Jordahl <tj...@adobe.com>
> wrote:
> |
> |> I haven't finished wading through the whole thread on this, but I fully
> |> support Deepal's position that Axis2 should focus on supporting its user
> |> base by not breaking things.
> |>
> |> There is functionality that users have asked for (hey, do we support
> |> consuming rpc/encoded services via ADB yet?) that would seem to me
> |> should take priority over OSGi.
> |>
> |> --
> |> Tom Jordahl
> |>
> |> -----Original Message-----
> |> From: Deepal jayasinghe [mailto:deepalk@gmail.com]
> |> Sent: Friday, June 13, 2008 5:26 AM
> |> To: axis-dev@ws.apache.org
> |> Subject: Re: Extensions to Axis2/Java deployment engine
> |>
> |> After reading all the mails , I still in the position that , YES we need
> |>
> |> to support OSGi. But , its better if we can do that without changing the
> |>
> |> core module. So I will help my best to write a OSGi based Axis
> |> configurator which does not touches the existing core code base
> |> (deployment side of it) , but will make sure to have what Saminda
> |> mentioned in the initial mail.
> |>
> |> Comments .... ??
> |>
> |> -Deepal
> |>> Over in Apache Tuscany we're actively working on changing to have OSGi
> |>> a more integral part of the SCA runtime so anything Axis2 does to be
> |>> more OSGi friendly would be useful to Tuscany.
> |>>
> |>> ...ant
> |>>
> |>>
> |>>
> |>> *Deepal Jayasinghe <de...@opensource.lk>*
> |>>
> |>> 13/06/2008 10:06
> |>> Please respond to
> |>> axis-dev@ws.apache.org
> |>>
> |>>
> |>>
> |>> To
> |>> axis-dev@ws.apache.org
> |>> cc
> |>>
> |>> Subject
> |>> Re: Extensions to Axis2/Java deployment engine
> |>>
> |>>
> |>>
> |>>
> |>>
> |>>
> |>>
> |>>
> |>>
> |>> Hi Venkat,
> |>>
> |>> I really appreciate your post , if there are users like who really
> |> need
> |>> OSGi , then we really should consider providing OSGi support out of
> |>> the box.
> |>>> I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
> |>>> our products which is built on equinox platform. If Axis2.0 features
> |>>> are available as OSGi bundles, it would help Axis2.0 adaption in
> |>>> future, I guess.
> |>>>
> |>>> - venkat
> |>>>
> |>>>
> |>>
> |>>
> |>> ---------------------------------------------------------------------
> |>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> |>> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>>
> |>>
> |>>
> |>>
> |>>
> |>>
> |> ------------------------------------------------------------------------
> |>> /
> |>> /
> |>>
> |>> /Unless stated otherwise above:
> |>> IBM United Kingdom Limited - Registered in England and Wales with
> |>> number 741598.
> |>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> |>> 3AU/
> |>>
> |>>
> |>>
> |>>
> |>>
> |> ---------------------------------------------------------------------
> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
> |> ---------------------------------------------------------------------
> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIV6tpgNg6eWEDv1kRAsdVAKChiZOjplARJPOFJnKDbd2Ya58U5wCfQ4R/
> QjZ3ykpffoPG4g22OmpU9IE=
> =TAax
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Saminda,
Can we please keep the OSGi stuff in separate maven module for now? We can still use maven magic to generate a
axis2-kernel and axis2-adb jar with whatever you need inside, but as an artifact inside the OSGi maven module.
That will avoid dragging in osgi jars in the main build and keep everyone happy till we convince them :)
thanks,
dims
Saminda Abeyruwan wrote:
| Hi Devs,
|
| First phase of the implementation plan is to use axis2-kernel, axis2-adb and
| create the org.apache.axis2.osgi_<version>.jar bundle, which will salvage
| some existing code from current Axis2 OSGi implementation. New
| implementation will include the activator, builders, and most importantly
| AxisConfigurator. I will package legacy jars as bundles and use the existing
| bundles, which will be fully operational in Equinox. Will provide you with
| the working sample asap.
|
| I wanted to write the activator and stuff to axis2-kernel and axis2-adb
| itself. But for the first step lets provide this as an extension.
|
| Thank you!
|
| Saminda
|
| On Tue, Jun 17, 2008 at 12:27 AM, Tom Jordahl <tj...@adobe.com> wrote:
|
|> I haven't finished wading through the whole thread on this, but I fully
|> support Deepal's position that Axis2 should focus on supporting its user
|> base by not breaking things.
|>
|> There is functionality that users have asked for (hey, do we support
|> consuming rpc/encoded services via ADB yet?) that would seem to me
|> should take priority over OSGi.
|>
|> --
|> Tom Jordahl
|>
|> -----Original Message-----
|> From: Deepal jayasinghe [mailto:deepalk@gmail.com]
|> Sent: Friday, June 13, 2008 5:26 AM
|> To: axis-dev@ws.apache.org
|> Subject: Re: Extensions to Axis2/Java deployment engine
|>
|> After reading all the mails , I still in the position that , YES we need
|>
|> to support OSGi. But , its better if we can do that without changing the
|>
|> core module. So I will help my best to write a OSGi based Axis
|> configurator which does not touches the existing core code base
|> (deployment side of it) , but will make sure to have what Saminda
|> mentioned in the initial mail.
|>
|> Comments .... ??
|>
|> -Deepal
|>> Over in Apache Tuscany we're actively working on changing to have OSGi
|>> a more integral part of the SCA runtime so anything Axis2 does to be
|>> more OSGi friendly would be useful to Tuscany.
|>>
|>> ...ant
|>>
|>>
|>>
|>> *Deepal Jayasinghe <de...@opensource.lk>*
|>>
|>> 13/06/2008 10:06
|>> Please respond to
|>> axis-dev@ws.apache.org
|>>
|>>
|>>
|>> To
|>> axis-dev@ws.apache.org
|>> cc
|>>
|>> Subject
|>> Re: Extensions to Axis2/Java deployment engine
|>>
|>>
|>>
|>>
|>>
|>>
|>>
|>>
|>>
|>> Hi Venkat,
|>>
|>> I really appreciate your post , if there are users like who really
|> need
|>> OSGi , then we really should consider providing OSGi support out of
|>> the box.
|>>> I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
|>>> our products which is built on equinox platform. If Axis2.0 features
|>>> are available as OSGi bundles, it would help Axis2.0 adaption in
|>>> future, I guess.
|>>>
|>>> - venkat
|>>>
|>>>
|>>
|>>
|>> ---------------------------------------------------------------------
|>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|>> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>>
|>>
|>>
|>>
|>>
|>>
|> ------------------------------------------------------------------------
|>> /
|>> /
|>>
|>> /Unless stated otherwise above:
|>> IBM United Kingdom Limited - Registered in England and Wales with
|>> number 741598.
|>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
|>> 3AU/
|>>
|>>
|>>
|>>
|>>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIV6tpgNg6eWEDv1kRAsdVAKChiZOjplARJPOFJnKDbd2Ya58U5wCfQ4R/
QjZ3ykpffoPG4g22OmpU9IE=
=TAax
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi Devs,
First phase of the implementation plan is to use axis2-kernel, axis2-adb and
create the org.apache.axis2.osgi_<version>.jar bundle, which will salvage
some existing code from current Axis2 OSGi implementation. New
implementation will include the activator, builders, and most importantly
AxisConfigurator. I will package legacy jars as bundles and use the existing
bundles, which will be fully operational in Equinox. Will provide you with
the working sample asap.
I wanted to write the activator and stuff to axis2-kernel and axis2-adb
itself. But for the first step lets provide this as an extension.
Thank you!
Saminda
On Tue, Jun 17, 2008 at 12:27 AM, Tom Jordahl <tj...@adobe.com> wrote:
> I haven't finished wading through the whole thread on this, but I fully
> support Deepal's position that Axis2 should focus on supporting its user
> base by not breaking things.
>
> There is functionality that users have asked for (hey, do we support
> consuming rpc/encoded services via ADB yet?) that would seem to me
> should take priority over OSGi.
>
> --
> Tom Jordahl
>
> -----Original Message-----
> From: Deepal jayasinghe [mailto:deepalk@gmail.com]
> Sent: Friday, June 13, 2008 5:26 AM
> To: axis-dev@ws.apache.org
> Subject: Re: Extensions to Axis2/Java deployment engine
>
> After reading all the mails , I still in the position that , YES we need
>
> to support OSGi. But , its better if we can do that without changing the
>
> core module. So I will help my best to write a OSGi based Axis
> configurator which does not touches the existing core code base
> (deployment side of it) , but will make sure to have what Saminda
> mentioned in the initial mail.
>
> Comments .... ??
>
> -Deepal
> >
> > Over in Apache Tuscany we're actively working on changing to have OSGi
>
> > a more integral part of the SCA runtime so anything Axis2 does to be
> > more OSGi friendly would be useful to Tuscany.
> >
> > ...ant
> >
> >
> >
> > *Deepal Jayasinghe <de...@opensource.lk>*
> >
> > 13/06/2008 10:06
> > Please respond to
> > axis-dev@ws.apache.org
> >
> >
> >
> > To
> > axis-dev@ws.apache.org
> > cc
> >
> > Subject
> > Re: Extensions to Axis2/Java deployment engine
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Venkat,
> >
> > I really appreciate your post , if there are users like who really
> need
> > OSGi , then we really should consider providing OSGi support out of
> > the box.
> > > I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
> > > our products which is built on equinox platform. If Axis2.0 features
> > > are available as OSGi bundles, it would help Axis2.0 adaption in
> > > future, I guess.
> > >
> > > - venkat
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>
> > 3AU/
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
RE: Extensions to Axis2/Java deployment engine
Posted by Tom Jordahl <tj...@adobe.com>.
I haven't finished wading through the whole thread on this, but I fully
support Deepal's position that Axis2 should focus on supporting its user
base by not breaking things.
There is functionality that users have asked for (hey, do we support
consuming rpc/encoded services via ADB yet?) that would seem to me
should take priority over OSGi.
--
Tom Jordahl
-----Original Message-----
From: Deepal jayasinghe [mailto:deepalk@gmail.com]
Sent: Friday, June 13, 2008 5:26 AM
To: axis-dev@ws.apache.org
Subject: Re: Extensions to Axis2/Java deployment engine
After reading all the mails , I still in the position that , YES we need
to support OSGi. But , its better if we can do that without changing the
core module. So I will help my best to write a OSGi based Axis
configurator which does not touches the existing core code base
(deployment side of it) , but will make sure to have what Saminda
mentioned in the initial mail.
Comments .... ??
-Deepal
>
> Over in Apache Tuscany we're actively working on changing to have OSGi
> a more integral part of the SCA runtime so anything Axis2 does to be
> more OSGi friendly would be useful to Tuscany.
>
> ...ant
>
>
>
> *Deepal Jayasinghe <de...@opensource.lk>*
>
> 13/06/2008 10:06
> Please respond to
> axis-dev@ws.apache.org
>
>
>
> To
> axis-dev@ws.apache.org
> cc
>
> Subject
> Re: Extensions to Axis2/Java deployment engine
>
>
>
>
>
>
>
>
>
> Hi Venkat,
>
> I really appreciate your post , if there are users like who really
need
> OSGi , then we really should consider providing OSGi support out of
> the box.
> > I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
> > our products which is built on equinox platform. If Axis2.0 features
> > are available as OSGi bundles, it would help Axis2.0 adaption in
> > future, I guess.
> >
> > - venkat
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
>
>
------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU/
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal jayasinghe <de...@gmail.com>.
After reading all the mails , I still in the position that , YES we need
to support OSGi. But , its better if we can do that without changing the
core module. So I will help my best to write a OSGi based Axis
configurator which does not touches the existing core code base
(deployment side of it) , but will make sure to have what Saminda
mentioned in the initial mail.
Comments .... ??
-Deepal
>
> Over in Apache Tuscany we're actively working on changing to have OSGi
> a more integral part of the SCA runtime so anything Axis2 does to be
> more OSGi friendly would be useful to Tuscany.
>
> ...ant
>
>
>
> *Deepal Jayasinghe <de...@opensource.lk>*
>
> 13/06/2008 10:06
> Please respond to
> axis-dev@ws.apache.org
>
>
>
> To
> axis-dev@ws.apache.org
> cc
>
> Subject
> Re: Extensions to Axis2/Java deployment engine
>
>
>
>
>
>
>
>
>
> Hi Venkat,
>
> I really appreciate your post , if there are users like who really need
> OSGi , then we really should consider providing OSGi support out of
> the box.
> > I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
> > our products which is built on equinox platform. If Axis2.0 features
> > are available as OSGi bundles, it would help Axis2.0 adaption in
> > future, I guess.
> >
> > - venkat
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU/
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Anthony Elder <an...@uk.ibm.com>.
Over in Apache Tuscany we're actively working on changing to have OSGi a
more integral part of the SCA runtime so anything Axis2 does to be more
OSGi friendly would be useful to Tuscany.
...ant
Deepal Jayasinghe <de...@opensource.lk>
13/06/2008 10:06
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: Extensions to Axis2/Java deployment engine
Hi Venkat,
I really appreciate your post , if there are users like who really need
OSGi , then we really should consider providing OSGi support out of the
box.
> I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
> our products which is built on equinox platform. If Axis2.0 features
> are available as OSGi bundles, it would help Axis2.0 adaption in
> future, I guess.
>
> - venkat
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Venkat,
I really appreciate your post , if there are users like who really need
OSGi , then we really should consider providing OSGi support out of the box.
> I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
> our products which is built on equinox platform. If Axis2.0 features
> are available as OSGi bundles, it would help Axis2.0 adaption in
> future, I guess.
>
> - venkat
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Venkat Reddy <vr...@gmail.com>.
On Fri, Jun 13, 2008 at 12:56 PM, David Illsley <da...@gmail.com> wrote:
> On Fri, Jun 13, 2008 at 7:56 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>
>>> Hi Deepal,
>>> I know decisions were made about various things before I was on the
>>> scene,
>>
>> ;-)
>>
>> And we did not know about OSGi when we design Axis2.
>>
>>> but nothing is unchangable, and what Saminda is suggesting
>>> sounds really cool and useful.
>>
>> I agree, but I do not like to change Axis2 fundamentals then are there ,
>> because over 50K download taking place per month due to fact that people out
>> there happy what Axis2 does now. So why worry of changing that. Thats the
>> only worry I have. Just because OSGi is there and it is cool , we should not
>> change our code base to support those. As I mentioned I have no objection
>> on implementing new AxisConfigurator based on OSGi and do what ever we want
>> , but I do not like changing the current core code base to support OSGi.
>> Because I do not see a value of doing that.
>
> OK, so I disagree with this position. Yes, we get lots of downloads,
> but those are of releases, and no-one is suggesting that big changes
> should go in just before a release. I don't believe we would release
> if something as fundamental as module deploy was broken - is there
> some approach we can come up with that allows further innovation in
> Axis2 without putting our release users at risk? What do you think?
>
> I personally think that OSGI is beyond just *cool* - It's the
> foundation for a number of Java web services hosting environments
> (including, but not limited to: Glassfish, SpringSource App Platform,
> WebSphere, JOnAS, and BEA) and so better integration with it will be a
> good thing.
I agree. Currently I'm evaluating Axis2.0 for embedding it in one of
our products which is built on equinox platform. If Axis2.0 features
are available as OSGi bundles, it would help Axis2.0 adaption in
future, I guess.
- venkat
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by David Illsley <da...@gmail.com>.
On Fri, Jun 13, 2008 at 7:56 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
>> Hi Deepal,
>> I know decisions were made about various things before I was on the
>> scene,
>
> ;-)
>
> And we did not know about OSGi when we design Axis2.
>
>> but nothing is unchangable, and what Saminda is suggesting
>> sounds really cool and useful.
>
> I agree, but I do not like to change Axis2 fundamentals then are there ,
> because over 50K download taking place per month due to fact that people out
> there happy what Axis2 does now. So why worry of changing that. Thats the
> only worry I have. Just because OSGi is there and it is cool , we should not
> change our code base to support those. As I mentioned I have no objection
> on implementing new AxisConfigurator based on OSGi and do what ever we want
> , but I do not like changing the current core code base to support OSGi.
> Because I do not see a value of doing that.
OK, so I disagree with this position. Yes, we get lots of downloads,
but those are of releases, and no-one is suggesting that big changes
should go in just before a release. I don't believe we would release
if something as fundamental as module deploy was broken - is there
some approach we can come up with that allows further innovation in
Axis2 without putting our release users at risk? What do you think?
I personally think that OSGI is beyond just *cool* - It's the
foundation for a number of Java web services hosting environments
(including, but not limited to: Glassfish, SpringSource App Platform,
WebSphere, JOnAS, and BEA) and so better integration with it will be a
good thing.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Hi Deepal,
> I know decisions were made about various things before I was on the
> scene,
;-)
And we did not know about OSGi when we design Axis2.
> but nothing is unchangable, and what Saminda is suggesting
> sounds really cool and useful.
I agree, but I do not like to change Axis2 fundamentals then are there ,
because over 50K download taking place per month due to fact that people
out there happy what Axis2 does now. So why worry of changing that.
Thats the only worry I have. Just because OSGi is there and it is cool ,
we should not change our code base to support those. As I mentioned I
have no objection on implementing new AxisConfigurator based on OSGi
and do what ever we want , but I do not like changing the current core
code base to support OSGi. Because I do not see a value of doing that.
> If we want to expand Axis2 useage, this
> sounds like the kind of forward looking change that would help.
>
Yes. I agree.
> I don't understand what your problem is with making a change to allow
> hot module deployment beyond the fact it's not how Axis2 works today.
> Is it your view that no new function that affects the kernel design is
> acceptable from now on, because that's what your e-mail seemed to
> suggest?
>
Nope I did not mean that. You can do changes to the kernel but not major
, critical changes like above does not need for kernel. Which may arise
a number of issues, and might break the existing users and might affect
the backward compatibility as well. Mature project like Axis2 should
not do those.
If we make our services and modules are OSGi bundle then the amount of
work that a service author has to do is very high compared to now (I got
to know that from Saminda). That is why I reluctant to change the
current kernel code base.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal jayasinghe <de...@gmail.com>.
Hi David ,
> Hi Deepal,
> I know decisions were made about various things before I was on the
> scene,
I agree with you that when Axis2 was designed you were not there. But
there were number of very experienced people (to be honest , at that
stage I did not know much about Web services so I do not count myself as
an experienced developer at the initial stage.) so they contributed a
lot to the Axis2 architecture. And all the decision we made based on
community , it was not a single person decision. I still remember when
some one agree to something there were a number of of people do not
agree to that , somehow we discussed over mailing list and IRC and come
to a conclusion. Thats how Aixs2 to evolved and matured. So just
because you were not there you can not tell we have taken a wrong
decision and we want to change that. ;-)
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by David Illsley <da...@gmail.com>.
Hi Deepal,
I know decisions were made about various things before I was on the
scene, but nothing is unchangable, and what Saminda is suggesting
sounds really cool and useful. If we want to expand Axis2 useage, this
sounds like the kind of forward looking change that would help.
I don't understand what your problem is with making a change to allow
hot module deployment beyond the fact it's not how Axis2 works today.
Is it your view that no new function that affects the kernel design is
acceptable from now on, because that's what your e-mail seemed to
suggest?
David
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal jayasinghe <de...@gmail.com>.
> Hi Devs,
>
> Dims has started the work on providing the OSGi extension to Axis2.
> This extension is a single bundle which consist of all the jars needed
> to run axis2. It uses OSGi Bundle events to update AxisConfiguration.
So does that mean Dims has written a OSGi based Axis configurator ?
> Main aspect of OSGi is version and modularity.
Well in Axis2 module has version support by default , so we do not need
to worry of getting module version support. No body ask for better
module version support than what we have, so no need to worry.
> In order to get the full power of OSGi, we need to consider the following,
Just for curiosity does any user ask for OSGi support in Axis2. Or we
just did that thinking ha!! there is something called OSGi out there ,
how about using that. The reason I am telling this is there a number of
critical issues in Axis2 then having OSGi support.
>
> 1. Modules and Service loading
> 2. Using OSGi services
>
> I would consider the first section. Second section has a broad scope
> and lets discuss that in a separate thread.
+1
>
>
> With the OSGi, one could be able to write aar & mar as OSGi bundles.
Yes , but we MUST support what we have now out of the BOX . if you want
to deploy them as OSGi bundle then do that using a separate Deployer. Do
not try to change any of the kernel code to do this.
> Thus, when Axis2 start, one can give a repository where services &
> modules available and one could use bundles to mimic this behaviour
You are talking about a new AxisConfigurator , if that is the case I
have no objection. Go ahead and do what ever you want.
> . When it's come to bundles, they could either exist or remove from
> the system any-time. This is dynamism of OSGi and this behaviour is
> currently not possible with current module & service loading mechanism.
I am sorry one of the architectural decision we took when we deploy
Axis2 was , that we are not going to have hot -deployment support for
modules. So we do not need to worry about dynamic nature of module ,right ?
>
> Current architecture requires, modules to be available first before
> services are loaded, if modules are referenced by theses services.
> Thus, services have a direct dependency to modules. Even if the
> service is not faulty,
Well if the module is not there , then thats simply mean something is
missing for service to up and running . So if the module is not there
then that simply mean the service is faulty.
> if the referenced module is not available, that service become faulty.
> This behaviour contradicts the nature of dynamic behaviour.
Nope, thats what Axis2 architecture enforce , and that is one of the
architectural decision we have taken few years back.
>
> Thus, what would really need is modules to be loaded and initialize
> orthogonal of service load and initialization.
Well in the OSGi world that may be true but not in Axis2. So if you
write your own AxisConfigurator then you can code your code to work
exactly what you have mention. But not in Axis2 default behavior ;-) .
> If loaded service reference to a module that is not available yet,
> marked that service as "unresolved" until the module is available.
> Once the module is available it would be easily go thorough the
> "unresolved" services and marked the relevant services as "resolved".
> Everything will be handle using OSGi events, which is very powerful
> and flexible. There could be other events that make the service
> "unresolved", but the major one is module.
yes all those with your custom OSGi dependent code , not in Axis2 core.
>
> Where there are 100s of bundles available in the system, its not
> practical to assume a start level to bundles. These bundles may mimic
> Axis2 services/module or other 3rd party bundle.
>
> I am totally fine with current deployment mechanism, but in order to
> obtain a tighter integration we would have to revisit the current
> deployment semantics.
No way , I am -1 for that. But I am +1 for writing a OSGi based
AxisConfigurator.
> In addition to this standardizing this on Axis2 provide unique user
> experience among the Axis2 community.
What do you mean by standardizing ? what do you want to standarde ?
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Rajith Attapattu <ra...@gmail.com>.
After reading through the thread here is my 2 cents.
I totally agree that OSGi based configurator is a good idea. So +1 for that.
However making that the default , tinkering with the kernal or changing
default architectural properties of axis2 is not a good idea in my opinion.
Whatever it is we need to think about backwards compatibility etc.
I am -1 for changing existing behaviour as it would impact exisiting users.
Can we not do this change with minimum impact on the kernal?
If I have misunderstood please let me know.
Regards,
Rajith
On Fri, Jun 13, 2008 at 8:41 AM, Asankha C. Perera <as...@wso2.com> wrote:
> Saminda
>
>> Main aspect of OSGi is version and modularity
>>
> Can you list the top 5 advantages for Axis2 end users (who develop
> services, or develop clients that consume services), and the top 5
> advantages for those who embed Axis2 (such as Apache Synapse etc). I think
> this would be very valuable information for me to consider your suggestion,
> and assess the impact on Apache Synapse
>
>> I am really appreciate if Axis2 folks comment on prior.
>>
> Looking forward to your reply to comment further
>
> asankha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On Mon, Jun 16, 2008 at 6:41 PM, Davanum Srinivas <da...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Guys,
>
> Sun is promising full interop JAM<->OSGi [1]. They are trying to pull in
> Peter [2] to help. Gory details here [3]. Sun
> folks are playing politics it seems [4].
>
> Bottom line, 277 may be farther away than you think. Since GlassFish has
> already adopted OSGi.
OSGi alliance folks stated that JSR 277 wouldn't address all the issues
related JSR 8, which is original OSGi JSR. Interesting!
http://live.eclipse.org/node/392
>
> thanks,
> dims
>
> [1]
> http://weblogs.java.net/blog/mandychung/archive/2008/04/supporting_osgi.html
> [2] http://www.osgi.org/blog/2008/05/java-modularity.html
> [3] http://www.infoq.com/news/2008/05/jsr277-osgi
> [4]
> http://www.tensegrity.hellblazer.com/2008/06/my_dinner_with_andre_1.html
>
>
> Samisa Abeysinghe wrote:
> | Ruwan Linton wrote:
> |>
> |> Also just wanted to make sure, what is the advantage of being OSGi
> |> with Java 7 which promises to provide versionning via JAM (Java
> |> Application Modules)
> |
> | How long would it be before "everyone" adopts 1.7?
> |
> | Samisa...
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> | For additional commands, e-mail: axis-dev-help@ws.apache.org
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIVmZ3gNg6eWEDv1kRAnMGAKDlSqCYulLMAXY5SFXHcr3R6HShxQCfaQCA
> 0QAnpKvqHDW0Pn09LjOlXzE=
> =R07h
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guys,
Sun is promising full interop JAM<->OSGi [1]. They are trying to pull in Peter [2] to help. Gory details here [3]. Sun
folks are playing politics it seems [4].
Bottom line, 277 may be farther away than you think. Since GlassFish has already adopted OSGi.
thanks,
dims
[1] http://weblogs.java.net/blog/mandychung/archive/2008/04/supporting_osgi.html
[2] http://www.osgi.org/blog/2008/05/java-modularity.html
[3] http://www.infoq.com/news/2008/05/jsr277-osgi
[4] http://www.tensegrity.hellblazer.com/2008/06/my_dinner_with_andre_1.html
Samisa Abeysinghe wrote:
| Ruwan Linton wrote:
|>
|> Also just wanted to make sure, what is the advantage of being OSGi
|> with Java 7 which promises to provide versionning via JAM (Java
|> Application Modules)
|
| How long would it be before "everyone" adopts 1.7?
|
| Samisa...
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| For additional commands, e-mail: axis-dev-help@ws.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIVmZ3gNg6eWEDv1kRAnMGAKDlSqCYulLMAXY5SFXHcr3R6HShxQCfaQCA
0QAnpKvqHDW0Pn09LjOlXzE=
=R07h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Paul Fremantle <pz...@gmail.com>.
Deepal
I think you completely missed the point.
Changes to the Java VM require users to migrate. That can be
difficult. Many users are still on JDK 1.4 for core systems because
they are on App Servers certified on that model. OSGi has been
designed to work *with* any JVM and therefore avoid requiring an
upgrade.
Paul
On Mon, Jun 16, 2008 at 2:06 PM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
>> Ruwan Linton wrote:
>>>
>>> Also just wanted to make sure, what is the advantage of being OSGi with
>>> Java 7 which promises to provide versionning via JAM (Java Application
>>> Modules)
>>
>> How long would it be before "everyone" adopts 1.7?
>
> I think same answer can be applied for the OSGi as well ;-)
>
> -Deepal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Ruwan Linton wrote:
>>
>> Also just wanted to make sure, what is the advantage of being OSGi
>> with Java 7 which promises to provide versionning via JAM (Java
>> Application Modules)
>
> How long would it be before "everyone" adopts 1.7?
I think same answer can be applied for the OSGi as well ;-)
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Ruwan Linton wrote:
>
> Also just wanted to make sure, what is the advantage of being OSGi
> with Java 7 which promises to provide versionning via JAM (Java
> Application Modules)
How long would it be before "everyone" adopts 1.7?
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Saminda,
>
> =================================================
>
> In Synapse point of view.
>
> 1. Mediators can be written as OSGi bundles.
What is the value addition?
> When you start the bundle, the proper factory is called and build the
> relevant object model.
Even now it does very correctly ;-)
>
>
> 2. Different version of same mediator is highly possible. i.e two mediator
> can live in two different class spaces.
Why do one need two versions? Do you expect the functionality to be
different? In which case any way those are two mediators :-)
>
>
> 3. You will be able to remove Sun service providers facility of loading
> extension to bundles, which will be support in all Java implementations.
We can do the same without OSGi
>
>
> 4. Synapse guys like embedded devices ?
I didn't get this point at all, can you please explain what you meant here?
I think axis2 should provide the flexibility to use OSGi or be with the one
that we have now. For example Synapse community does not want to be OSGi
then we should be able to get the behavior that axis2 has now with the next
versions as well.
There fore I don't think it is good to do changes to the kernel which
affects the current behavior of axis2. I really like deepal's suggestions
and we should try to support OSGi features while keeping the current
behavior and we can release a different artifact of Axis2 which supports
OSGi.
Also just wanted to make sure, what is the advantage of being OSGi with Java
7 which promises to provide versionning via JAM (Java Application Modules)
Thanks,
Ruwan
>
>
> Thank you!
>
> Saminda
>
>
> On Fri, Jun 13, 2008 at 6:11 PM, Asankha C. Perera <as...@wso2.com>
> wrote:
>
>> Saminda
>>
>>> Main aspect of OSGi is version and modularity
>>>
>> Can you list the top 5 advantages for Axis2 end users (who develop
>> services, or develop clients that consume services), and the top 5
>> advantages for those who embed Axis2 (such as Apache Synapse etc). I think
>> this would be very valuable information for me to consider your suggestion,
>> and assess the impact on Apache Synapse
>>
>>> I am really appreciate if Axis2 folks comment on prior.
>>>
>> Looking forward to your reply to comment further
>>
>> asankha
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
> --
> Saminda Abeyruwan
>
> Senior Software Engineer
> WSO2 Inc. - www.wso2.org
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On Mon, Jun 16, 2008 at 5:26 PM, Paul Fremantle <pz...@gmail.com> wrote:
> I think the ideal outcome would be this:
>
> * Firstly we allow Axis2 to work cleanly in a OSGi environment.
Axis2 need to lax the tight dependency between modules and services. This
should be done only in OSGi environment, hence preserve the backward
compatibility. This change is essential to Axis2 to work properly in OSGi
environment.
>
> * We also allow Axis2 to work in a non-OSGi environment (full
> backwards compatibility).
Yes. Backward compatibility will be preserved all time.
>
> * We define an extension to Axis2 that is available as a separate JAR
> that enables OSGi
Current axis2 OSGi extension contains all 3rd party jars, which prevents
from being proper OSGi. Axis2 will need a "bundle repository" which will
download 3rd party bundles on demand. Most of the 3rd party jars that Axis2
uses are bundles (manifest.mf contains required headers). Thus, the bundle
repository just need to hold the jars which are not bundles yet and has been
converted to bundles.
>
> * If the OSGi extension is available, then that enables OSGi
> deployment of services and modules
Need service & modules lax from kernel to work this properly.
>
> * In other words, there is a well-defined way of creating a bundle
> that is a service and a bundle that is a module, and once the OSGi
> extension is enabled, the OSGi discovery mechanisms pick up the
> extensions.
OSGi events, and trivial.
>
> * Axis2 transports could also have OSGi metadata in the JAR so that
> these could use OSGi to be enabled if OSGi is enabled.
This is the place were we need to vote between
1. OSGi extender model
2. OSGi service registry model.
My money goes to "OSGi service registry model". Where
transports(senders/receivers)/builders/mr/deployers/etc can simply be mapped
to OSGi service and add to AxisConfiguration as and when needed. I haven't
put a not on this yet. At the moment we assume the extender model and these
elements are available from bundles.
>
> I don't know if this is possible :)
>
Yes it is. We just need the lax between services & modules, and make sure
Axis2 API is strong enough to plug the elements we needed.
Thank you!
Saminda
>
> Paul
>
>
> On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe <de...@gmail.com>
> wrote:
> > Saminda Abeyruwan wrote:
> >>
> >> =================================================
> >>
> >> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
> >> able to live in different class spaces.
> >> ex: If the bundles needed different hibernate versions they can be
> >> easily plug into different class spaces.
> >
> > With the existing Axis2 class loaders you can easily do that , so no new
> > thing is going to add :)
> >>
> >> 2. We will be able to have multiple version of Axis2 instancres running
> >> inside same JVM.
> >> This require the need of minimizing System properties.
> >
> > This is YAGNI.
> >>
> >> 3. Axis2 will be able to initiate same transport with different
> versions.
> >> This will require proper integration of OSGi services. I haven't
> touched
> >> this area yet, otherwise whole situation will be overwhelming.
> >
> > What is the value of this , aren't we trying to build castles in the sky
> > ;-)
> >>
> >> 4. OSGi life-cycle support. This will give the ability to
> >> start/stop/install/update/uninstall bundles.
> >> ex: I have myModule.jar which would mimic myModule.mar. We will be
> able
> >> use the above actions to to manipulate the AxisModule as we need.
> >
> > Yes , this a valid point that we can consider.
> >>
> >> 5. Once a user has written a bundle (which mimic
> aar/mar/transport/etc),
> >> they just need to upload them into a "Axis2 bundle repository", where
> the
> >> community can search them and install them into there system, without
> >> shutting down the running system.
> >>
> > So isnt this same as service hot deployment ?
> >>
> >> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
> >> install/started/updated/uninstall, using OSGi events other bundles can
> >> change there behaviour.
> >
> > We already have this in Axis2. I know places like WSO2 WSAS they use this
> > feature a lot.
> >>
> >> 7. When bundle are properly designed, one will be able to deploy these
> >> bundles in any OSGi environment. Most of the app servers are in the path
> of
> >> supporting OSGi. All we have to do is to drop our bundles in their
> >> repositories and start them
> >
> > I do not see a big value of this with respect to Web services containers.
> >>
> >> 8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles.
> >
> > You can already do with Axis2 services aar file , by adding "WWW"
> directory
> > in the services aar file you can achieve almost all the power you have
> > mentioned.
> >>
> >>
> >> 8. Once the ConfigurationContext become an OSGi service, any bundle can
> >> access it and use it.
> >
> > Yes :)
> >>
> >> 9. People will be able to use OSGi registry to register POJOs as OSGi
> >> services and make them as web services
> >> (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
> >
> > But with Axis2 you can expose POJO as Web services in very
> straightforward
> > manner.
> >>
> >> 10. People would need minimum effort to integrate into OSGi powered
> >> Spring etc.
> >
> > Agreed.
> >
> > Thank you!
> > Deepal
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
+1
Saminda
On Mon, Jun 16, 2008 at 7:17 PM, Guillaume Sauthier <
Guillaume.Sauthier@objectweb.org> wrote:
> Hi Dims & all
>
> This discussion about OSGi is very interesting.
> I agree that OSGi benefits are maybe not directly visible for the end-user
> but maybe more for the deployer/assembler.
>
> We did exactly what you want to do with Axis with our EJB3 container
> (EasyBeans) a year ago:
> * Having OSGi as an option: no dependencies on OSGi on the core so that
> easybeans can still be used out of the box without OSGi, but when easybeans
> is started in its OSGi mode, we take advantages of all the OSGi features
> (versionned packages dependencies, some IoC, dynamism, ...).
> http://wiki.easybeans.org/xwiki/bin/view/Main/OSGi
>
> OSGi enforce some strong rules about packages visibility (the class space)
> and moreover "force" us to use interfaces a lot (to limit dependencies on
> implementations details). So using system properties is discouraged (sys
> prop are JVM scoped, so maybe that's not the configuration you want to share
> if you have multiple Axis instances).
> We had to change things in the core to make this possible (like providing
> extension interfaces), but without affecting the backward compatibility.
>
> What I want to say here is that some changes are probably necessary in the
> core of Axis to ease that OSGi extension:
> * All the places were there are some classloadings are probably to be
> checked, OSGi prefers that the bundle that brings some new code creates the
> instance, or at least load the class itself. A general idea is that it's not
> safe, in OSGi, to rely on the TCCL to load class: who knows if the TCCL
> contains the classloader you want ?
> * Try to avoid sys properties, and prefer a configuration API
> * Concerning the extensions, rely heavily on interfaces, not on
> implementations, with clean packages separation
>
> And last thing: that's better (almost mandatory) to have continuous
> integration testing for OSGi, at least when there are developers that don't
> know OSGi at all...
> Oh, and that's better if the developers know a little about OSGi, so that
> they can code something that will be easier to execute under OSGi
>
> Cheers
> --Guillaume
>
> BTW, we will be very happy to see Axis2/OSGi running into JOnAS :)
>
>
> Davanum Srinivas wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Paul,
>>
>> That's exactly that's being done so far on the osgi module in various
>> stages of completion :) [Except for the last item]
>>
>> thansk,
>> dims
>>
>> Paul Fremantle wrote:
>> | I think the ideal outcome would be this:
>> |
>> | * Firstly we allow Axis2 to work cleanly in a OSGi environment.
>> | * We also allow Axis2 to work in a non-OSGi environment (full
>> | backwards compatibility).
>> | * We define an extension to Axis2 that is available as a separate JAR
>> | that enables OSGi
>> | * If the OSGi extension is available, then that enables OSGi
>> | deployment of services and modules
>> | * In other words, there is a well-defined way of creating a bundle
>> | that is a service and a bundle that is a module, and once the OSGi
>> | extension is enabled, the OSGi discovery mechanisms pick up the
>> | extensions.
>> | * Axis2 transports could also have OSGi metadata in the JAR so that
>> | these could use OSGi to be enabled if OSGi is enabled.
>> |
>> | I don't know if this is possible :)
>> |
>> | Paul
>> |
>> |
>> | On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe <de...@gmail.com>
>> wrote:
>> |> Saminda Abeyruwan wrote:
>> |>> =================================================
>> |>>
>> |>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles
>> be
>> |>> able to live in different class spaces.
>> |>> ex: If the bundles needed different hibernate versions they can be
>> |>> easily plug into different class spaces.
>> |> With the existing Axis2 class loaders you can easily do that , so no
>> new
>> |> thing is going to add :)
>> |>> 2. We will be able to have multiple version of Axis2 instancres
>> running
>> |>> inside same JVM.
>> |>> This require the need of minimizing System properties.
>> |> This is YAGNI.
>> |>> 3. Axis2 will be able to initiate same transport with different
>> versions.
>> |>> This will require proper integration of OSGi services. I haven't
>> touched
>> |>> this area yet, otherwise whole situation will be overwhelming.
>> |> What is the value of this , aren't we trying to build castles in the
>> sky
>> |> ;-)
>> |>> 4. OSGi life-cycle support. This will give the ability to
>> |>> start/stop/install/update/uninstall bundles.
>> |>> ex: I have myModule.jar which would mimic myModule.mar. We will be
>> able
>> |>> use the above actions to to manipulate the AxisModule as we need.
>> |> Yes , this a valid point that we can consider.
>> |>> 5. Once a user has written a bundle (which mimic
>> aar/mar/transport/etc),
>> |>> they just need to upload them into a "Axis2 bundle repository", where
>> the
>> |>> community can search them and install them into there system, without
>> |>> shutting down the running system.
>> |>>
>> |> So isnt this same as service hot deployment ?
>> |>> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
>> |>> install/started/updated/uninstall, using OSGi events other bundles can
>> |>> change there behaviour.
>> |> We already have this in Axis2. I know places like WSO2 WSAS they use
>> this
>> |> feature a lot.
>> |>> 7. When bundle are properly designed, one will be able to deploy these
>> |>> bundles in any OSGi environment. Most of the app servers are in the
>> path of
>> |>> supporting OSGi. All we have to do is to drop our bundles in their
>> |>> repositories and start them
>> |> I do not see a big value of this with respect to Web services
>> containers.
>> |>> 8. User can use resources (html/jsp/ etc) needed for aar/mar in
>> bundles.
>> |> You can already do with Axis2 services aar file , by adding "WWW"
>> directory
>> |> in the services aar file you can achieve almost all the power you have
>> |> mentioned.
>> |>>
>> |>> 8. Once the ConfigurationContext become an OSGi service, any bundle
>> can
>> |>> access it and use it.
>> |> Yes :)
>> |>> 9. People will be able to use OSGi registry to register POJOs as OSGi
>> |>> services and make them as web services
>> |>> (
>> http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
>> |> But with Axis2 you can expose POJO as Web services in very
>> straightforward
>> |> manner.
>> |>> 10. People would need minimum effort to integrate into OSGi powered
>> |>> Spring etc.
>> |> Agreed.
>> |>
>> |> Thank you!
>> |> Deepal
>> |>
>> |> ---------------------------------------------------------------------
>> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
>> |>
>> |>
>> |
>> |
>> |
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (Cygwin)
>>
>> iD8DBQFIVloagNg6eWEDv1kRAk4LAJ9L46jJOZb/53Fp1Y6ZVpxL3CXdJQCgpPJE
>> gkMLLkWQRzPvjKtRM+KbE+4=
>> =z4aB
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Hi Dims & all
This discussion about OSGi is very interesting.
I agree that OSGi benefits are maybe not directly visible for the
end-user but maybe more for the deployer/assembler.
We did exactly what you want to do with Axis with our EJB3 container
(EasyBeans) a year ago:
* Having OSGi as an option: no dependencies on OSGi on the core so that
easybeans can still be used out of the box without OSGi, but when
easybeans is started in its OSGi mode, we take advantages of all the
OSGi features (versionned packages dependencies, some IoC, dynamism, ...).
http://wiki.easybeans.org/xwiki/bin/view/Main/OSGi
OSGi enforce some strong rules about packages visibility (the class
space) and moreover "force" us to use interfaces a lot (to limit
dependencies on implementations details). So using system properties is
discouraged (sys prop are JVM scoped, so maybe that's not the
configuration you want to share if you have multiple Axis instances).
We had to change things in the core to make this possible (like
providing extension interfaces), but without affecting the backward
compatibility.
What I want to say here is that some changes are probably necessary in
the core of Axis to ease that OSGi extension:
* All the places were there are some classloadings are probably to be
checked, OSGi prefers that the bundle that brings some new code creates
the instance, or at least load the class itself. A general idea is that
it's not safe, in OSGi, to rely on the TCCL to load class: who knows if
the TCCL contains the classloader you want ?
* Try to avoid sys properties, and prefer a configuration API
* Concerning the extensions, rely heavily on interfaces, not on
implementations, with clean packages separation
And last thing: that's better (almost mandatory) to have continuous
integration testing for OSGi, at least when there are developers that
don't know OSGi at all...
Oh, and that's better if the developers know a little about OSGi, so
that they can code something that will be easier to execute under OSGi
Cheers
--Guillaume
BTW, we will be very happy to see Axis2/OSGi running into JOnAS :)
Davanum Srinivas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paul,
>
> That's exactly that's being done so far on the osgi module in various
> stages of completion :) [Except for the last item]
>
> thansk,
> dims
>
> Paul Fremantle wrote:
> | I think the ideal outcome would be this:
> |
> | * Firstly we allow Axis2 to work cleanly in a OSGi environment.
> | * We also allow Axis2 to work in a non-OSGi environment (full
> | backwards compatibility).
> | * We define an extension to Axis2 that is available as a separate JAR
> | that enables OSGi
> | * If the OSGi extension is available, then that enables OSGi
> | deployment of services and modules
> | * In other words, there is a well-defined way of creating a bundle
> | that is a service and a bundle that is a module, and once the OSGi
> | extension is enabled, the OSGi discovery mechanisms pick up the
> | extensions.
> | * Axis2 transports could also have OSGi metadata in the JAR so that
> | these could use OSGi to be enabled if OSGi is enabled.
> |
> | I don't know if this is possible :)
> |
> | Paul
> |
> |
> | On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe
> <de...@gmail.com> wrote:
> |> Saminda Abeyruwan wrote:
> |>> =================================================
> |>>
> |>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these
> bundles be
> |>> able to live in different class spaces.
> |>> ex: If the bundles needed different hibernate versions they can be
> |>> easily plug into different class spaces.
> |> With the existing Axis2 class loaders you can easily do that , so
> no new
> |> thing is going to add :)
> |>> 2. We will be able to have multiple version of Axis2 instancres
> running
> |>> inside same JVM.
> |>> This require the need of minimizing System properties.
> |> This is YAGNI.
> |>> 3. Axis2 will be able to initiate same transport with different
> versions.
> |>> This will require proper integration of OSGi services. I haven't
> touched
> |>> this area yet, otherwise whole situation will be overwhelming.
> |> What is the value of this , aren't we trying to build castles in
> the sky
> |> ;-)
> |>> 4. OSGi life-cycle support. This will give the ability to
> |>> start/stop/install/update/uninstall bundles.
> |>> ex: I have myModule.jar which would mimic myModule.mar. We will
> be able
> |>> use the above actions to to manipulate the AxisModule as we need.
> |> Yes , this a valid point that we can consider.
> |>> 5. Once a user has written a bundle (which mimic
> aar/mar/transport/etc),
> |>> they just need to upload them into a "Axis2 bundle repository",
> where the
> |>> community can search them and install them into there system, without
> |>> shutting down the running system.
> |>>
> |> So isnt this same as service hot deployment ?
> |>> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
> |>> install/started/updated/uninstall, using OSGi events other bundles
> can
> |>> change there behaviour.
> |> We already have this in Axis2. I know places like WSO2 WSAS they
> use this
> |> feature a lot.
> |>> 7. When bundle are properly designed, one will be able to deploy
> these
> |>> bundles in any OSGi environment. Most of the app servers are in
> the path of
> |>> supporting OSGi. All we have to do is to drop our bundles in their
> |>> repositories and start them
> |> I do not see a big value of this with respect to Web services
> containers.
> |>> 8. User can use resources (html/jsp/ etc) needed for aar/mar in
> bundles.
> |> You can already do with Axis2 services aar file , by adding "WWW"
> directory
> |> in the services aar file you can achieve almost all the power you have
> |> mentioned.
> |>>
> |>> 8. Once the ConfigurationContext become an OSGi service, any
> bundle can
> |>> access it and use it.
> |> Yes :)
> |>> 9. People will be able to use OSGi registry to register POJOs as OSGi
> |>> services and make them as web services
> |>>
> (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
> |> But with Axis2 you can expose POJO as Web services in very
> straightforward
> |> manner.
> |>> 10. People would need minimum effort to integrate into OSGi powered
> |>> Spring etc.
> |> Agreed.
> |>
> |> Thank you!
> |> Deepal
> |>
> |> ---------------------------------------------------------------------
> |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIVloagNg6eWEDv1kRAk4LAJ9L46jJOZb/53Fp1Y6ZVpxL3CXdJQCgpPJE
> gkMLLkWQRzPvjKtRM+KbE+4=
> =z4aB
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
Re: Extensions to Axis2/Java deployment engine
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul,
That's exactly that's being done so far on the osgi module in various stages of completion :) [Except for the last item]
thansk,
dims
Paul Fremantle wrote:
| I think the ideal outcome would be this:
|
| * Firstly we allow Axis2 to work cleanly in a OSGi environment.
| * We also allow Axis2 to work in a non-OSGi environment (full
| backwards compatibility).
| * We define an extension to Axis2 that is available as a separate JAR
| that enables OSGi
| * If the OSGi extension is available, then that enables OSGi
| deployment of services and modules
| * In other words, there is a well-defined way of creating a bundle
| that is a service and a bundle that is a module, and once the OSGi
| extension is enabled, the OSGi discovery mechanisms pick up the
| extensions.
| * Axis2 transports could also have OSGi metadata in the JAR so that
| these could use OSGi to be enabled if OSGi is enabled.
|
| I don't know if this is possible :)
|
| Paul
|
|
| On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe <de...@gmail.com> wrote:
|> Saminda Abeyruwan wrote:
|>> =================================================
|>>
|>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
|>> able to live in different class spaces.
|>> ex: If the bundles needed different hibernate versions they can be
|>> easily plug into different class spaces.
|> With the existing Axis2 class loaders you can easily do that , so no new
|> thing is going to add :)
|>> 2. We will be able to have multiple version of Axis2 instancres running
|>> inside same JVM.
|>> This require the need of minimizing System properties.
|> This is YAGNI.
|>> 3. Axis2 will be able to initiate same transport with different versions.
|>> This will require proper integration of OSGi services. I haven't touched
|>> this area yet, otherwise whole situation will be overwhelming.
|> What is the value of this , aren't we trying to build castles in the sky
|> ;-)
|>> 4. OSGi life-cycle support. This will give the ability to
|>> start/stop/install/update/uninstall bundles.
|>> ex: I have myModule.jar which would mimic myModule.mar. We will be able
|>> use the above actions to to manipulate the AxisModule as we need.
|> Yes , this a valid point that we can consider.
|>> 5. Once a user has written a bundle (which mimic aar/mar/transport/etc),
|>> they just need to upload them into a "Axis2 bundle repository", where the
|>> community can search them and install them into there system, without
|>> shutting down the running system.
|>>
|> So isnt this same as service hot deployment ?
|>> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
|>> install/started/updated/uninstall, using OSGi events other bundles can
|>> change there behaviour.
|> We already have this in Axis2. I know places like WSO2 WSAS they use this
|> feature a lot.
|>> 7. When bundle are properly designed, one will be able to deploy these
|>> bundles in any OSGi environment. Most of the app servers are in the path of
|>> supporting OSGi. All we have to do is to drop our bundles in their
|>> repositories and start them
|> I do not see a big value of this with respect to Web services containers.
|>> 8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles.
|> You can already do with Axis2 services aar file , by adding "WWW" directory
|> in the services aar file you can achieve almost all the power you have
|> mentioned.
|>>
|>> 8. Once the ConfigurationContext become an OSGi service, any bundle can
|>> access it and use it.
|> Yes :)
|>> 9. People will be able to use OSGi registry to register POJOs as OSGi
|>> services and make them as web services
|>> (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
|> But with Axis2 you can expose POJO as Web services in very straightforward
|> manner.
|>> 10. People would need minimum effort to integrate into OSGi powered
|>> Spring etc.
|> Agreed.
|>
|> Thank you!
|> Deepal
|>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIVloagNg6eWEDv1kRAk4LAJ9L46jJOZb/53Fp1Y6ZVpxL3CXdJQCgpPJE
gkMLLkWQRzPvjKtRM+KbE+4=
=z4aB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Paul Fremantle <pz...@gmail.com>.
I think the ideal outcome would be this:
* Firstly we allow Axis2 to work cleanly in a OSGi environment.
* We also allow Axis2 to work in a non-OSGi environment (full
backwards compatibility).
* We define an extension to Axis2 that is available as a separate JAR
that enables OSGi
* If the OSGi extension is available, then that enables OSGi
deployment of services and modules
* In other words, there is a well-defined way of creating a bundle
that is a service and a bundle that is a module, and once the OSGi
extension is enabled, the OSGi discovery mechanisms pick up the
extensions.
* Axis2 transports could also have OSGi metadata in the JAR so that
these could use OSGi to be enabled if OSGi is enabled.
I don't know if this is possible :)
Paul
On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe <de...@gmail.com> wrote:
> Saminda Abeyruwan wrote:
>>
>> =================================================
>>
>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
>> able to live in different class spaces.
>> ex: If the bundles needed different hibernate versions they can be
>> easily plug into different class spaces.
>
> With the existing Axis2 class loaders you can easily do that , so no new
> thing is going to add :)
>>
>> 2. We will be able to have multiple version of Axis2 instancres running
>> inside same JVM.
>> This require the need of minimizing System properties.
>
> This is YAGNI.
>>
>> 3. Axis2 will be able to initiate same transport with different versions.
>> This will require proper integration of OSGi services. I haven't touched
>> this area yet, otherwise whole situation will be overwhelming.
>
> What is the value of this , aren't we trying to build castles in the sky
> ;-)
>>
>> 4. OSGi life-cycle support. This will give the ability to
>> start/stop/install/update/uninstall bundles.
>> ex: I have myModule.jar which would mimic myModule.mar. We will be able
>> use the above actions to to manipulate the AxisModule as we need.
>
> Yes , this a valid point that we can consider.
>>
>> 5. Once a user has written a bundle (which mimic aar/mar/transport/etc),
>> they just need to upload them into a "Axis2 bundle repository", where the
>> community can search them and install them into there system, without
>> shutting down the running system.
>>
> So isnt this same as service hot deployment ?
>>
>> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
>> install/started/updated/uninstall, using OSGi events other bundles can
>> change there behaviour.
>
> We already have this in Axis2. I know places like WSO2 WSAS they use this
> feature a lot.
>>
>> 7. When bundle are properly designed, one will be able to deploy these
>> bundles in any OSGi environment. Most of the app servers are in the path of
>> supporting OSGi. All we have to do is to drop our bundles in their
>> repositories and start them
>
> I do not see a big value of this with respect to Web services containers.
>>
>> 8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles.
>
> You can already do with Axis2 services aar file , by adding "WWW" directory
> in the services aar file you can achieve almost all the power you have
> mentioned.
>>
>>
>> 8. Once the ConfigurationContext become an OSGi service, any bundle can
>> access it and use it.
>
> Yes :)
>>
>> 9. People will be able to use OSGi registry to register POJOs as OSGi
>> services and make them as web services
>> (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
>
> But with Axis2 you can expose POJO as Web services in very straightforward
> manner.
>>
>> 10. People would need minimum effort to integrate into OSGi powered
>> Spring etc.
>
> Agreed.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Deepal jayasinghe <de...@gmail.com>.
Saminda Abeyruwan wrote:
> =================================================
>
> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles
> be able to live in different class spaces.
> ex: If the bundles needed different hibernate versions they can be
> easily plug into different class spaces.
With the existing Axis2 class loaders you can easily do that , so no new
thing is going to add :)
>
> 2. We will be able to have multiple version of Axis2 instancres
> running inside same JVM.
> This require the need of minimizing System properties.
This is YAGNI.
>
> 3. Axis2 will be able to initiate same transport with different versions.
> This will require proper integration of OSGi services. I haven't
> touched this area yet, otherwise whole situation will be overwhelming.
What is the value of this , aren't we trying to build castles in the
sky ;-)
>
> 4. OSGi life-cycle support. This will give the ability to
> start/stop/install/update/uninstall bundles.
> ex: I have myModule.jar which would mimic myModule.mar. We will be
> able use the above actions to to manipulate the AxisModule as we need.
Yes , this a valid point that we can consider.
>
> 5. Once a user has written a bundle (which mimic
> aar/mar/transport/etc), they just need to upload them into a "Axis2
> bundle repository", where the community can search them and install
> them into there system, without shutting down the running system.
>
So isnt this same as service hot deployment ?
> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
> install/started/updated/uninstall, using OSGi events other bundles can
> change there behaviour.
We already have this in Axis2. I know places like WSO2 WSAS they use
this feature a lot.
>
> 7. When bundle are properly designed, one will be able to deploy these
> bundles in any OSGi environment. Most of the app servers are in the
> path of supporting OSGi. All we have to do is to drop our bundles in
> their repositories and start them
I do not see a big value of this with respect to Web services containers.
> 8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles.
You can already do with Axis2 services aar file , by adding "WWW"
directory in the services aar file you can achieve almost all the power
you have mentioned.
>
>
> 8. Once the ConfigurationContext become an OSGi service, any bundle
> can access it and use it.
Yes :)
>
> 9. People will be able to use OSGi registry to register POJOs as OSGi
> services and make them as web services
> (http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
But with Axis2 you can expose POJO as Web services in very
straightforward manner.
>
> 10. People would need minimum effort to integrate into OSGi powered
> Spring etc.
Agreed.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On Mon, Jun 16, 2008 at 5:29 AM, Ruwan Linton <ru...@gmail.com>
wrote:
> Saminda,
>
> Can you please answer to these question directly (yes/no)?
>
> Will this change preserve backward compatibility?
> Will we be able to use axis2 as it is, without OSGi?
> Will the current behavior be preserved?
Yes to all.
In order to get the proper OSGi integration the tight dependency between
services and modules need to lax when loaded from OSGi environment.
Saminda
>
>
> Thanks,
> Ruwan
>
>
> On Mon, Jun 16, 2008 at 4:11 AM, Davanum Srinivas <da...@gmail.com>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Asankha,
>>
>> Would you object even if changes are incremental and don't affect existing
>> use cases / scenarios? Specifically, in a
>> non-osgi environment existing functionality is kept as-is?
>>
>> As saminda mentions, the idea is to add a few OSGi Activators, make
>> changes to META-INF, make some changes to existing
>> code to make things fit better...At least that's my view point on which we
>> can make progress. After all we have a huge
>> existing deliverables to ship :)
>>
>> thanks,
>> dims
>>
>>
>> Asankha C. Perera wrote:
>> | Saminda
>> |
>> | In general I feel most of the points you suggest would not be really
>> | used by actual end users most of the time (if not all the time) -
>> | especially those who use Axis2 in production. Shall we take this
>> | discussion to the user list as well and see if these use cases you
>> | describe would be really "useful" to the end users? If they agree with a
>> | majority vote, we can then go ahead with the OSGi changes. As for the
>> | points you mentioned about Synapse, I guess you see that it really
>> | doesn't add much value as things are right now..
>> |
>> | asankha
>> |
>> | ---------------------------------------------------------------------
>> | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> | For additional commands, e-mail: axis-dev-help@ws.apache.org
>> |
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (Cygwin)
>>
>> iD8DBQFIVZqEgNg6eWEDv1kRAtmoAKC501czGR/nOmuSifwLEfFZ+n1llgCfR9wN
>> VoIiNgjHgf9XZ71+IbvDBbg=
>> =BBeM
>> -----END PGP SIGNATURE-----
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
> --
> Ruwan Linton
> http://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Ruwan Linton <ru...@gmail.com>.
Dims,
Yes exactly. If we can give Yes as the answers for these three, I don't have
any objection at all.
Thanks,
Ruwan
On Mon, Jun 16, 2008 at 6:04 AM, Davanum Srinivas <da...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ruwan,
>
> Personally if the answers are no, then we should *NOT* go ahead.
>
> thanks,
> dims
>
> Ruwan Linton wrote:
> | Saminda,
> |
> | Can you please answer to these question directly (yes/no)?
> |
> | Will this change preserve backward compatibility?
> | Will we be able to use axis2 as it is, without OSGi?
> | Will the current behavior be preserved?
> |
> | Thanks,
> | Ruwan
> |
> | On Mon, Jun 16, 2008 at 4:11 AM, Davanum Srinivas <da...@gmail.com>
> wrote:
> |
> | Asankha,
> |
> | Would you object even if changes are incremental and don't affect
> existing
> | use cases / scenarios? Specifically, in a
> | non-osgi environment existing functionality is kept as-is?
> |
> | As saminda mentions, the idea is to add a few OSGi Activators, make
> changes
> | to META-INF, make some changes to existing
> | code to make things fit better...At least that's my view point on which
> we
> | can make progress. After all we have a huge
> | existing deliverables to ship :)
> |
> | thanks,
> | dims
> |
> |
> | Asankha C. Perera wrote:
> | | Saminda
> | |
> | | In general I feel most of the points you suggest would not be really
> | | used by actual end users most of the time (if not all the time) -
> | | especially those who use Axis2 in production. Shall we take this
> | | discussion to the user list as well and see if these use cases you
> | | describe would be really "useful" to the end users? If they agree with
> a
> | | majority vote, we can then go ahead with the OSGi changes. As for the
> | | points you mentioned about Synapse, I guess you see that it really
> | | doesn't add much value as things are right now..
> | |
> | | asankha
> | |
> | | ---------------------------------------------------------------------
> | | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> | | For additional commands, e-mail: axis-dev-help@ws.apache.org
> | |
> |>
> |>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIVbUxgNg6eWEDv1kRAmUjAJ0bhC2UI9hbpRrZZYiCXs1PiQtlLgCeIzdj
> BQfiRMpbaEyycUR/L7puxG0=
> =YVK8
>
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Extensions to Axis2/Java deployment engine
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ruwan,
Personally if the answers are no, then we should *NOT* go ahead.
thanks,
dims
Ruwan Linton wrote:
| Saminda,
|
| Can you please answer to these question directly (yes/no)?
|
| Will this change preserve backward compatibility?
| Will we be able to use axis2 as it is, without OSGi?
| Will the current behavior be preserved?
|
| Thanks,
| Ruwan
|
| On Mon, Jun 16, 2008 at 4:11 AM, Davanum Srinivas <da...@gmail.com> wrote:
|
| Asankha,
|
| Would you object even if changes are incremental and don't affect existing
| use cases / scenarios? Specifically, in a
| non-osgi environment existing functionality is kept as-is?
|
| As saminda mentions, the idea is to add a few OSGi Activators, make changes
| to META-INF, make some changes to existing
| code to make things fit better...At least that's my view point on which we
| can make progress. After all we have a huge
| existing deliverables to ship :)
|
| thanks,
| dims
|
|
| Asankha C. Perera wrote:
| | Saminda
| |
| | In general I feel most of the points you suggest would not be really
| | used by actual end users most of the time (if not all the time) -
| | especially those who use Axis2 in production. Shall we take this
| | discussion to the user list as well and see if these use cases you
| | describe would be really "useful" to the end users? If they agree with a
| | majority vote, we can then go ahead with the OSGi changes. As for the
| | points you mentioned about Synapse, I guess you see that it really
| | doesn't add much value as things are right now..
| |
| | asankha
| |
| | ---------------------------------------------------------------------
| | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| | For additional commands, e-mail: axis-dev-help@ws.apache.org
| |
|>
|>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIVbUxgNg6eWEDv1kRAmUjAJ0bhC2UI9hbpRrZZYiCXs1PiQtlLgCeIzdj
BQfiRMpbaEyycUR/L7puxG0=
=YVK8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Ruwan Linton <ru...@gmail.com>.
Saminda,
Can you please answer to these question directly (yes/no)?
Will this change preserve backward compatibility?
Will we be able to use axis2 as it is, without OSGi?
Will the current behavior be preserved?
Thanks,
Ruwan
On Mon, Jun 16, 2008 at 4:11 AM, Davanum Srinivas <da...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Asankha,
>
> Would you object even if changes are incremental and don't affect existing
> use cases / scenarios? Specifically, in a
> non-osgi environment existing functionality is kept as-is?
>
> As saminda mentions, the idea is to add a few OSGi Activators, make changes
> to META-INF, make some changes to existing
> code to make things fit better...At least that's my view point on which we
> can make progress. After all we have a huge
> existing deliverables to ship :)
>
> thanks,
> dims
>
>
> Asankha C. Perera wrote:
> | Saminda
> |
> | In general I feel most of the points you suggest would not be really
> | used by actual end users most of the time (if not all the time) -
> | especially those who use Axis2 in production. Shall we take this
> | discussion to the user list as well and see if these use cases you
> | describe would be really "useful" to the end users? If they agree with a
> | majority vote, we can then go ahead with the OSGi changes. As for the
> | points you mentioned about Synapse, I guess you see that it really
> | doesn't add much value as things are right now..
> |
> | asankha
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> | For additional commands, e-mail: axis-dev-help@ws.apache.org
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIVZqEgNg6eWEDv1kRAtmoAKC501czGR/nOmuSifwLEfFZ+n1llgCfR9wN
> VoIiNgjHgf9XZ71+IbvDBbg=
> =BBeM
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Extensions to Axis2/Java deployment engine
Posted by Michele Mazzucco <Mi...@ncl.ac.uk>.
Agreed.
Michele
On 16 Jun 2008, at 03:19, Asankha C. Perera wrote:
> Dims
>> Would you object even if changes are incremental and don't affect
>> existing use cases / scenarios? Specifically, in a
>> non-osgi environment existing functionality is kept as-is?
> No I will not object.. as long as the core code is not dependent on
> OSGi libraries/API's etc as well (i.e. Synapse should be able to
> ship without a bunch of OSGi dependency libraries or dependencies),
> and backwards compatibility with what we have as Axis2 1.4 is
> maintained at the code level.
>
> Hopefully this will also mean than an OSGi dummy like me can
> continue to update, maintain and debug the code without worrying
> about OSGi
>
> thanks
> asankha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by "Asankha C. Perera" <as...@wso2.com>.
Dims
> Would you object even if changes are incremental and don't affect
> existing use cases / scenarios? Specifically, in a
> non-osgi environment existing functionality is kept as-is?
No I will not object.. as long as the core code is not dependent on OSGi
libraries/API's etc as well (i.e. Synapse should be able to ship without
a bunch of OSGi dependency libraries or dependencies), and backwards
compatibility with what we have as Axis2 1.4 is maintained at the code
level.
Hopefully this will also mean than an OSGi dummy like me can continue to
update, maintain and debug the code without worrying about OSGi
thanks
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Asankha,
Would you object even if changes are incremental and don't affect existing use cases / scenarios? Specifically, in a
non-osgi environment existing functionality is kept as-is?
As saminda mentions, the idea is to add a few OSGi Activators, make changes to META-INF, make some changes to existing
code to make things fit better...At least that's my view point on which we can make progress. After all we have a huge
existing deliverables to ship :)
thanks,
dims
Asankha C. Perera wrote:
| Saminda
|
| In general I feel most of the points you suggest would not be really
| used by actual end users most of the time (if not all the time) -
| especially those who use Axis2 in production. Shall we take this
| discussion to the user list as well and see if these use cases you
| describe would be really "useful" to the end users? If they agree with a
| majority vote, we can then go ahead with the OSGi changes. As for the
| points you mentioned about Synapse, I guess you see that it really
| doesn't add much value as things are right now..
|
| asankha
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| For additional commands, e-mail: axis-dev-help@ws.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIVZqEgNg6eWEDv1kRAtmoAKC501czGR/nOmuSifwLEfFZ+n1llgCfR9wN
VoIiNgjHgf9XZ71+IbvDBbg=
=BBeM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by "Asankha C. Perera" <as...@wso2.com>.
Saminda
In general I feel most of the points you suggest would not be really
used by actual end users most of the time (if not all the time) -
especially those who use Axis2 in production. Shall we take this
discussion to the user list as well and see if these use cases you
describe would be really "useful" to the end users? If they agree with a
majority vote, we can then go ahead with the OSGi changes. As for the
points you mentioned about Synapse, I guess you see that it really
doesn't add much value as things are right now..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
On Mon, Jun 16, 2008 at 1:03 AM, Saminda Abeyruwan <sa...@gmail.com>
wrote:
>
> The reason Rampart jars need to go in to Axis2 lib is the Sun Service
>> Provider Interface problem. rampart-core.jar and rampart-policy.jar
>> registers some assertion builders using Sun SPI and those builders to be
>> used by neethi factory classes they should be in the classpath of those
>> neethi classes. So the only solution we have right now is to put those two
>> jars in the Axis2 lib. Actually we only need those two jars (not the third
>> party jars) to be in the Axis2 lib and rampart-trust.jar and other third
>> party jars can be bundled in the module itself. Can this be solved by OSGi ?
>> ( With the very little knowledge OGSi bundle classpath resolution and bundle
>> wiring , I couldn't figure out how to do this :( )
>>
>> Yes it is.
>
> Thank you!
>
> Saminda
>
> ps: wouldn't wss4j needed to be in root lib as well.
>
Nope, in the password callback case, WSS4J explicitly load the password
callback from the class loader of the service. So what WSS4J does is it asks
from the service class loader to provide the password callback (not from the
module class loader or class loader of WSS4J class ) . So wss4j jar can be
bundled with the Rampart mar. Password callback class only need to be
available on the service class loader. And WSS4J has nothing to do with
policies and it doesn't register any builders using Sun SPI.
thanks,
nandana
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
> The reason Rampart jars need to go in to Axis2 lib is the Sun Service
> Provider Interface problem. rampart-core.jar and rampart-policy.jar
> registers some assertion builders using Sun SPI and those builders to be
> used by neethi factory classes they should be in the classpath of those
> neethi classes. So the only solution we have right now is to put those two
> jars in the Axis2 lib. Actually we only need those two jars (not the third
> party jars) to be in the Axis2 lib and rampart-trust.jar and other third
> party jars can be bundled in the module itself. Can this be solved by OSGi ?
> ( With the very little knowledge OGSi bundle classpath resolution and bundle
> wiring , I couldn't figure out how to do this :( )
>
> Yes it is.
Thank you!
Saminda
ps: wouldn't wss4j needed to be in root lib as well.
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Saminda,
You have mentioned "rampart" as a famous example. "rampart.mar" contains
> only the module.xml. All other 3rd party jars has to be put into root lib.
> Rampart folks has done this, in order to prevent class delegation problems.
> With OSGi, one would need only to copy the relevant bundles into bundle
> repository and start them. Thus, this will eliminate of copying jars and
> mars all over the place. In order to include rampart into the system, one
> has to shut down the entire instance and start again. No offence rampart
> folks. This is true for most of the modules. So this is the problem we are
> trying to address and sort out with proper modularizing and version.
>
The reason Rampart jars need to go in to Axis2 lib is the Sun Service
Provider Interface problem. rampart-core.jar and rampart-policy.jar
registers some assertion builders using Sun SPI and those builders to be
used by neethi factory classes they should be in the classpath of those
neethi classes. So the only solution we have right now is to put those two
jars in the Axis2 lib. Actually we only need those two jars (not the third
party jars) to be in the Axis2 lib and rampart-trust.jar and other third
party jars can be bundled in the module itself. Can this be solved by OSGi ?
( With the very little knowledge OGSi bundle classpath resolution and bundle
wiring , I couldn't figure out how to do this :( )
thanks,
nandana
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi All,
w.r.t OSGi, at the end of the day prior points will boil down to version,
modularity and life-cycle support. OSGi has established its ways to be a
good modular system for Java.
This extension wouldn't break any backward compatibility. But in order to
embed this extension properly, few aspects of deployment semantics has to be
changed (ex: tight dependency between services and modules to lazy
dependency). One could always use this jars in its environment, if they
don't need OSGi. Being OSGi, this jar contains additional headers in
manifest.mf.
JSR 291 is the dynamic module for Java (R4.1), which we wanted to use. JSR
294 is the proposed language extension for modules in Java (native). All I
know is, JSR 294 is very far from being a reality, not even in Java 1.7.
2. We will be able to have multiple version of Axis2 instancres running
>> inside same JVM.
>> This require the need of minimizing System properties.
>>
> But you really will need to change ports/queues etc to really run two axis2
> versions. (i.e. there is no way two instances can share the same http/s
> port, or the JMS queue or check for email on the same account etc..). So the
> probability of this use and the value would be less. So this is not a good
> candidate for position # 2.
Axis2 kernel doesn't have to be depend on any transport. One usecase will
be one version of kernel be listen by (http/https) only and other version
only be listen by (jms), and both reside in the same JVM. There are other
usecase to have multiple instances of Axis2 running inside same JVM.
>
> 3. Axis2 will be able to initiate same transport with different versions.
>> This will require proper integration of OSGi services. I haven't touched
>> this area yet, otherwise whole situation will be overwhelming.
>>
> See comment above.. again this is not something and "end user" will see
> much value in.. its like being able to deploy the same transport twice - at
> the same time. Also transports would be tied to axis2 versions, and if you
> have a newer version, its probably much better than a previous one anyway..
> so again I don't see this as a good candidate for position # 3
Reason is same as step 2.
>
> 4. OSGi life-cycle support. This will give the ability to
>> start/stop/install/update/uninstall bundles.
>> ex: I have myModule.jar which would mimic myModule.mar. We will be able
>> use the above actions to to manipulate the AxisModule as we need.
>>
> What most end users would do is write services.. and I believe they already
> can do some amount of life cycle management.. can you tell me what "new"
> improvements this will give?
This phase will eliminate what we call "jar hell". This life-cycle support
is not the same this that axis service support. This is the phase where one
could physically alter the bundle and include the changes without shutting
down the system. This phase has a association with #1.
>
> 5. Once a user has written a bundle (which mimic aar/mar/transport/etc),
>> they just need to upload them into a "Axis2 bundle repository", where the
>> community can search them and install them into there system, without
>> shutting down the running system.
>>
> Typically a "user" written aar file is not really shared AFAIK.. but this
> is possible even as they are already.. as for the mar's - the most famous
> ones are rampart, sandesha/mercury etc.. which are "released".
Axis2 service doesn't have to an "aar". "aar" is one extension that is being
used to create the axis service with "ServiceDeployer". One could write n
number of deployers, with different formats. What bundle provide is a unique
way to share resources, packages, version etc. One ex: will be the POJO
deployer. pojos are lookup by ".jar" extension and 3rd party libraries are
located in either the "pojo/lib" folder or root lib. Do you think this is
scalable.
1. What if two pojo need two different hibernated versions.
2. What if these pojo need to be hosted and downloaded.
w.r.t OSGi, now POJO can have two different hibernate versions, and they can
be downloaded from a bundle repository and dependency is resolved at
runtime.
You have mentioned "rampart" as a famous example. "rampart.mar" contains
only the module.xml. All other 3rd party jars has to be put into root lib.
Rampart folks has done this, in order to prevent class delegation problems.
With OSGi, one would need only to copy the relevant bundles into bundle
repository and start them. Thus, this will eliminate of copying jars and
mars all over the place. In order to include rampart into the system, one
has to shut down the entire instance and start again. No offence rampart
folks. This is true for most of the modules. So this is the problem we are
trying to address and sort out with proper modularizing and version.
The other 5 cases as strong as the prior 5 cases.
Thank you!
Saminda
>
>
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Axis2 itself being an OSGi bundle wouldn't provide any added advantage.
Axis2 needs its deployment units to be OSGi enabled as well to get the
proper usage of OSGi. These deployment units are bundles and it will be seen
by end users. There are many tools available from Eclipse/Maven2 to create
bundles. Writing a bundle is now much more easier with these tools and a lot
of folks use them.
There are many products/projects uses OSGi. Thus, anyone who uses these
products/projects can easily use Axis2, as it's OSGi and its deployment
units are OSGi, which will expand the usage of Axis2.
Thank you!
Saminda
On Sun, Jun 15, 2008 at 9:18 PM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> wrote:
> Would OSGi would be more useful to "end users" or to those who want to
> "embed" and "bundle" Axis2?
>
> Samisa...
>
>
> Asankha C. Perera wrote:
>
>> Saminda
>>
>> Thanks for the detailed reply.. Please see my comments below, I will only
>> take the top 5 points for each list I asked for to keep this discussion
>> short, as I believe these are in the order of importance/use
>>
>>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
>>> able to live in different class spaces.
>>> ex: If the bundles needed different hibernate versions they can be
>>> easily plug into different class spaces.
>>>
>> I see this as a good use for the "end users"!
>>
>>>
>>> 2. We will be able to have multiple version of Axis2 instancres running
>>> inside same JVM.
>>> This require the need of minimizing System properties.
>>>
>> But you really will need to change ports/queues etc to really run two
>> axis2 versions. (i.e. there is no way two instances can share the same
>> http/s port, or the JMS queue or check for email on the same account etc..).
>> So the probability of this use and the value would be less. So this is not a
>> good candidate for position # 2.
>>
>>> 3. Axis2 will be able to initiate same transport with different versions.
>>> This will require proper integration of OSGi services. I haven't
>>> touched this area yet, otherwise whole situation will be overwhelming.
>>>
>> See comment above.. again this is not something and "end user" will see
>> much value in.. its like being able to deploy the same transport twice - at
>> the same time. Also transports would be tied to axis2 versions, and if you
>> have a newer version, its probably much better than a previous one anyway..
>> so again I don't see this as a good candidate for position # 3
>>
>>> 4. OSGi life-cycle support. This will give the ability to
>>> start/stop/install/update/uninstall bundles.
>>> ex: I have myModule.jar which would mimic myModule.mar. We will be
>>> able use the above actions to to manipulate the AxisModule as we need.
>>>
>> What most end users would do is write services.. and I believe they
>> already can do some amount of life cycle management.. can you tell me what
>> "new" improvements this will give?
>>
>>> 5. Once a user has written a bundle (which mimic aar/mar/transport/etc),
>>> they just need to upload them into a "Axis2 bundle repository", where the
>>> community can search them and install them into there system, without
>>> shutting down the running system.
>>>
>> Typically a "user" written aar file is not really shared AFAIK.. but this
>> is possible even as they are already.. as for the mar's - the most famous
>> ones are rampart, sandesha/mercury etc.. which are "released".
>>
>> =================================================
>>> In Synapse point of view.
>>>
>>> 1. Mediators can be written as OSGi bundles. When you start the bundle,
>>> the proper factory is called and build the relevant object model.
>>>
>> This is irrelevant, you will not just "add a mediator" at runtime.. but
>> you can configure or update your sequence etc at runtime, and you can do it
>> now itself (e.g. WSO2 ESB)
>>
>>> 2. Different version of same mediator is highly possible. i.e two
>>> mediator can live in two different class spaces.
>>>
>> Again, this is highly unlikely, since a newer version is better improved
>> or fixes a bug of an older version, also you will not be able to configure
>> two mediators as they register a unique QName in the configuration.
>>
>>> 3. You will be able to remove Sun service providers facility of loading
>>> extension to bundles, which will be support in all Java implementations.
>>>
>> This maybe good, but does not itself show much advantage, as we can do the
>> Sun service provider with a bit of custom code in any JDK anyway..
>>
>>> 4. Synapse guys like embedded devices ?
>>>
>> Not me.. but Synapse is being embedded.. but I don't see how this has
>> relevance
>>
>> thanks
>> asankha
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>
> --
> Samisa Abeysinghe
>
> http://people.apache.org/~samisa/ <http://people.apache.org/%7Esamisa/>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Would OSGi would be more useful to "end users" or to those who want to
"embed" and "bundle" Axis2?
Samisa...
Asankha C. Perera wrote:
> Saminda
>
> Thanks for the detailed reply.. Please see my comments below, I will
> only take the top 5 points for each list I asked for to keep this
> discussion short, as I believe these are in the order of importance/use
>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles
>> be able to live in different class spaces.
>> ex: If the bundles needed different hibernate versions they can be
>> easily plug into different class spaces.
> I see this as a good use for the "end users"!
>>
>> 2. We will be able to have multiple version of Axis2 instancres
>> running inside same JVM.
>> This require the need of minimizing System properties.
> But you really will need to change ports/queues etc to really run two
> axis2 versions. (i.e. there is no way two instances can share the same
> http/s port, or the JMS queue or check for email on the same account
> etc..). So the probability of this use and the value would be less. So
> this is not a good candidate for position # 2.
>> 3. Axis2 will be able to initiate same transport with different
>> versions.
>> This will require proper integration of OSGi services. I haven't
>> touched this area yet, otherwise whole situation will be overwhelming.
> See comment above.. again this is not something and "end user" will
> see much value in.. its like being able to deploy the same transport
> twice - at the same time. Also transports would be tied to axis2
> versions, and if you have a newer version, its probably much better
> than a previous one anyway.. so again I don't see this as a good
> candidate for position # 3
>> 4. OSGi life-cycle support. This will give the ability to
>> start/stop/install/update/uninstall bundles.
>> ex: I have myModule.jar which would mimic myModule.mar. We will
>> be able use the above actions to to manipulate the AxisModule as we
>> need.
> What most end users would do is write services.. and I believe they
> already can do some amount of life cycle management.. can you tell me
> what "new" improvements this will give?
>> 5. Once a user has written a bundle (which mimic
>> aar/mar/transport/etc), they just need to upload them into a "Axis2
>> bundle repository", where the community can search them and install
>> them into there system, without shutting down the running system.
> Typically a "user" written aar file is not really shared AFAIK.. but
> this is possible even as they are already.. as for the mar's - the
> most famous ones are rampart, sandesha/mercury etc.. which are
> "released".
>
>> =================================================
>> In Synapse point of view.
>>
>> 1. Mediators can be written as OSGi bundles. When you start the
>> bundle, the proper factory is called and build the relevant object
>> model.
> This is irrelevant, you will not just "add a mediator" at runtime..
> but you can configure or update your sequence etc at runtime, and you
> can do it now itself (e.g. WSO2 ESB)
>> 2. Different version of same mediator is highly possible. i.e two
>> mediator can live in two different class spaces.
> Again, this is highly unlikely, since a newer version is better
> improved or fixes a bug of an older version, also you will not be able
> to configure two mediators as they register a unique QName in the
> configuration.
>> 3. You will be able to remove Sun service providers facility of
>> loading extension to bundles, which will be support in all Java
>> implementations.
> This maybe good, but does not itself show much advantage, as we can do
> the Sun service provider with a bit of custom code in any JDK anyway..
>> 4. Synapse guys like embedded devices ?
> Not me.. but Synapse is being embedded.. but I don't see how this has
> relevance
>
> thanks
> asankha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Samisa Abeysinghe
http://people.apache.org/~samisa/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by "Asankha C. Perera" <as...@wso2.com>.
Saminda
Thanks for the detailed reply.. Please see my comments below, I will
only take the top 5 points for each list I asked for to keep this
discussion short, as I believe these are in the order of importance/use
> 1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles
> be able to live in different class spaces.
> ex: If the bundles needed different hibernate versions they can be
> easily plug into different class spaces.
I see this as a good use for the "end users"!
>
> 2. We will be able to have multiple version of Axis2 instancres
> running inside same JVM.
> This require the need of minimizing System properties.
But you really will need to change ports/queues etc to really run two
axis2 versions. (i.e. there is no way two instances can share the same
http/s port, or the JMS queue or check for email on the same account
etc..). So the probability of this use and the value would be less. So
this is not a good candidate for position # 2.
> 3. Axis2 will be able to initiate same transport with different versions.
> This will require proper integration of OSGi services. I haven't
> touched this area yet, otherwise whole situation will be overwhelming.
See comment above.. again this is not something and "end user" will see
much value in.. its like being able to deploy the same transport twice -
at the same time. Also transports would be tied to axis2 versions, and
if you have a newer version, its probably much better than a previous
one anyway.. so again I don't see this as a good candidate for position # 3
> 4. OSGi life-cycle support. This will give the ability to
> start/stop/install/update/uninstall bundles.
> ex: I have myModule.jar which would mimic myModule.mar. We will be
> able use the above actions to to manipulate the AxisModule as we need.
What most end users would do is write services.. and I believe they
already can do some amount of life cycle management.. can you tell me
what "new" improvements this will give?
> 5. Once a user has written a bundle (which mimic
> aar/mar/transport/etc), they just need to upload them into a "Axis2
> bundle repository", where the community can search them and install
> them into there system, without shutting down the running system.
Typically a "user" written aar file is not really shared AFAIK.. but
this is possible even as they are already.. as for the mar's - the most
famous ones are rampart, sandesha/mercury etc.. which are "released".
> =================================================
> In Synapse point of view.
>
> 1. Mediators can be written as OSGi bundles. When you start the
> bundle, the proper factory is called and build the relevant object model.
This is irrelevant, you will not just "add a mediator" at runtime.. but
you can configure or update your sequence etc at runtime, and you can do
it now itself (e.g. WSO2 ESB)
> 2. Different version of same mediator is highly possible. i.e two
> mediator can live in two different class spaces.
Again, this is highly unlikely, since a newer version is better improved
or fixes a bug of an older version, also you will not be able to
configure two mediators as they register a unique QName in the
configuration.
> 3. You will be able to remove Sun service providers facility of
> loading extension to bundles, which will be support in all Java
> implementations.
This maybe good, but does not itself show much advantage, as we can do
the Sun service provider with a bit of custom code in any JDK anyway..
> 4. Synapse guys like embedded devices ?
Not me.. but Synapse is being embedded.. but I don't see how this has
relevance
thanks
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
RE: Extensions to Axis2/Java deployment engine
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
My opinion:
The Axis2 kernel should not be dependent on where the app will be
deployed (i.e. servlet, OSGI, etc). The primary purpose of Axis2 is its
SOAP stack functionality. Even the additional data binding
functionality (i.e. ADB, XmlBeans, etc) is secondary.
My guess is that the majority of users aren't using Axis2 in an OSGI
container. So having OSGI logic in Axis2 kernel unnecessarily adds
dependencies that most users will not need. OSGI is already complex
enough and has its own limitations, and we probably don't want to change
Axis2 to adapt too much to OSGI, especially if OSGI itself may change
later.
But, to make it easier for OSGI users, it might be best to design the
Axis2 kernel to be flexible enough so that developers can
configure/customize it at runtime and run in their container of choice.
This would allow developers to do things like "inject" a custom
adapter/handler class via a Spring-like mechanism to override the
default Axis2 adapter/handler for a given process. The design might be
similar to how Eclipse enables "extension points", although I might not
go as far as making it that complicated.
My two cents...
-Vinh
________________________________
From: Saminda Abeyruwan [mailto:samindaa@gmail.com]
Sent: Friday, June 13, 2008 8:30 AM
To: axis-dev@ws.apache.org
Subject: Re: Extensions to Axis2/Java deployment engine
=================================================
1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
able to live in different class spaces.
ex: If the bundles needed different hibernate versions they can be
easily plug into different class spaces.
2. We will be able to have multiple version of Axis2 instancres running
inside same JVM.
This require the need of minimizing System properties.
3. Axis2 will be able to initiate same transport with different
versions.
This will require proper integration of OSGi services. I haven't
touched this area yet, otherwise whole situation will be overwhelming.
4. OSGi life-cycle support. This will give the ability to
start/stop/install/update/uninstall bundles.
ex: I have myModule.jar which would mimic myModule.mar. We will be
able use the above actions to to manipulate the AxisModule as we need.
5. Once a user has written a bundle (which mimic
aar/mar/transport/etc), they just need to upload them into a "Axis2
bundle repository", where the community can search them and install them
into there system, without shutting down the running system.
6. OSGi event framework. When bundle is (aar/mar/transport/etc)
install/started/updated/uninstall, using OSGi events other bundles can
change there behaviour.
7. When bundle are properly designed, one will be able to deploy these
bundles in any OSGi environment. Most of the app servers are in the path
of supporting OSGi. All we have to do is to drop our bundles in their
repositories and start them
8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles.
Using HttpService (impl may be native or provided) we will be able to
expose them. Equinox has provided some cool bundles, which can be used
all OSGi impls such as "servlet-bridge".
8. Once the ConfigurationContext become an OSGi service, any bundle can
access it and use it.
9. People will be able to use OSGi registry to register POJOs as OSGi
services and make them as web services
(http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
10. People would need minimum effort to integrate into OSGi powered
Spring etc.
=================================================
In Synapse point of view.
1. Mediators can be written as OSGi bundles. When you start the bundle,
the proper factory is called and build the relevant object model.
2. Different version of same mediator is highly possible. i.e two
mediator can live in two different class spaces.
3. You will be able to remove Sun service providers facility of loading
extension to bundles, which will be support in all Java implementations.
4. Synapse guys like embedded devices ?
Thank you!
Saminda
On Fri, Jun 13, 2008 at 6:11 PM, Asankha C. Perera <as...@wso2.com>
wrote:
Saminda
Main aspect of OSGi is version and modularity
Can you list the top 5 advantages for Axis2 end users (who
develop services, or develop clients that consume services), and the top
5 advantages for those who embed Axis2 (such as Apache Synapse etc). I
think this would be very valuable information for me to consider your
suggestion, and assess the impact on Apache Synapse
I am really appreciate if Axis2 folks comment on prior.
Looking forward to your reply to comment further
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by Saminda Abeyruwan <sa...@gmail.com>.
=================================================
1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles be
able to live in different class spaces.
ex: If the bundles needed different hibernate versions they can be easily
plug into different class spaces.
2. We will be able to have multiple version of Axis2 instancres running
inside same JVM.
This require the need of minimizing System properties.
3. Axis2 will be able to initiate same transport with different versions.
This will require proper integration of OSGi services. I haven't touched
this area yet, otherwise whole situation will be overwhelming.
4. OSGi life-cycle support. This will give the ability to
start/stop/install/update/uninstall bundles.
ex: I have myModule.jar which would mimic myModule.mar. We will be able
use the above actions to to manipulate the AxisModule as we need.
5. Once a user has written a bundle (which mimic aar/mar/transport/etc),
they just need to upload them into a "Axis2 bundle repository", where the
community can search them and install them into there system, without
shutting down the running system.
6. OSGi event framework. When bundle is (aar/mar/transport/etc)
install/started/updated/uninstall, using OSGi events other bundles can
change there behaviour.
7. When bundle are properly designed, one will be able to deploy these
bundles in any OSGi environment. Most of the app servers are in the path of
supporting OSGi. All we have to do is to drop our bundles in their
repositories and start them
8. User can use resources (html/jsp/ etc) needed for aar/mar in bundles.
Using HttpService (impl may be native or provided) we will be able to expose
them. Equinox has provided some cool bundles, which can be used all OSGi
impls such as "servlet-bridge".
8. Once the ConfigurationContext become an OSGi service, any bundle can
access it and use it.
9. People will be able to use OSGi registry to register POJOs as OSGi
services and make them as web services (
http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
10. People would need minimum effort to integrate into OSGi powered Spring
etc.
=================================================
In Synapse point of view.
1. Mediators can be written as OSGi bundles. When you start the bundle, the
proper factory is called and build the relevant object model.
2. Different version of same mediator is highly possible. i.e two mediator
can live in two different class spaces.
3. You will be able to remove Sun service providers facility of loading
extension to bundles, which will be support in all Java implementations.
4. Synapse guys like embedded devices ?
Thank you!
Saminda
On Fri, Jun 13, 2008 at 6:11 PM, Asankha C. Perera <as...@wso2.com> wrote:
> Saminda
>
>> Main aspect of OSGi is version and modularity
>>
> Can you list the top 5 advantages for Axis2 end users (who develop
> services, or develop clients that consume services), and the top 5
> advantages for those who embed Axis2 (such as Apache Synapse etc). I think
> this would be very valuable information for me to consider your suggestion,
> and assess the impact on Apache Synapse
>
>> I am really appreciate if Axis2 folks comment on prior.
>>
> Looking forward to your reply to comment further
>
> asankha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
Re: Extensions to Axis2/Java deployment engine
Posted by "Asankha C. Perera" <as...@wso2.com>.
Saminda
> Main aspect of OSGi is version and modularity
Can you list the top 5 advantages for Axis2 end users (who develop
services, or develop clients that consume services), and the top 5
advantages for those who embed Axis2 (such as Apache Synapse etc). I
think this would be very valuable information for me to consider your
suggestion, and assess the impact on Apache Synapse
> I am really appreciate if Axis2 folks comment on prior.
Looking forward to your reply to comment further
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 Go for it!
- -- dims
David Illsley wrote:
| Sounds good. +1
| David
|
| On Thu, Jun 12, 2008 at 5:27 PM, Saminda Abeyruwan <sa...@gmail.com> wrote:
|> Hi Devs,
|>
|> Dims has started the work on providing the OSGi extension to Axis2. This
|> extension is a single bundle which consist of all the jars needed to run
|> axis2. It uses OSGi Bundle events to update AxisConfiguration. Main aspect
|> of OSGi is version and modularity. In order to get the full power of OSGi,
|> we need to consider the following,
|>
|> 1. Modules and Service loading
|> 2. Using OSGi services
|>
|> I would consider the first section. Second section has a broad scope and
|> lets discuss that in a separate thread.
|>
|> With the OSGi, one could be able to write aar & mar as OSGi bundles. Thus,
|> when Axis2 start, one can give a repository where services & modules
|> available and one could use bundles to mimic this behaviour. When it's
|> come to bundles, they could either exist or remove from the system any-time.
|> This is dynamism of OSGi and this behaviour is currently not possible with
|> current module & service loading mechanism.
|>
|> Current architecture requires, modules to be available first before services
|> are loaded, if modules are referenced by theses services. Thus, services
|> have a direct dependency to modules. Even if the service is not faulty, if
|> the referenced module is not available, that service become faulty. This
|> behaviour contradicts the nature of dynamic behaviour.
|>
|> Thus, what would really need is modules to be loaded and initialize
|> orthogonal of service load and initialization. If loaded service reference
|> to a module that is not available yet, marked that service as "unresolved"
|> until the module is available. Once the module is available it would be
|> easily go thorough the "unresolved" services and marked the relevant
|> services as "resolved". Everything will be handle using OSGi events, which
|> is very powerful and flexible. There could be other events that make the
|> service "unresolved", but the major one is module.
|>
|> Where there are 100s of bundles available in the system, its not practical
|> to assume a start level to bundles. These bundles may mimic Axis2
|> services/module or other 3rd party bundle.
|>
|> I am totally fine with current deployment mechanism, but in order to obtain
|> a tighter integration we would have to revisit the current deployment
|> semantics. In addition to this standardizing this on Axis2 provide unique
|> user experience among the Axis2 community.
|>
|> I am really appreciate if Axis2 folks comment on prior.
|>
|> Thank you!
|>
|> Saminda
|>
|>
|>
|>
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| For additional commands, e-mail: axis-dev-help@ws.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIUciJgNg6eWEDv1kRAscLAKCZ+UUnx2ItP3phrJ4by6+pLR+SUwCg6jQC
8nF6JcA72LZRhAyk5gpQ7NM=
=fEJ4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Extensions to Axis2/Java deployment engine
Posted by David Illsley <da...@gmail.com>.
Sounds good. +1
David
On Thu, Jun 12, 2008 at 5:27 PM, Saminda Abeyruwan <sa...@gmail.com> wrote:
> Hi Devs,
>
> Dims has started the work on providing the OSGi extension to Axis2. This
> extension is a single bundle which consist of all the jars needed to run
> axis2. It uses OSGi Bundle events to update AxisConfiguration. Main aspect
> of OSGi is version and modularity. In order to get the full power of OSGi,
> we need to consider the following,
>
> 1. Modules and Service loading
> 2. Using OSGi services
>
> I would consider the first section. Second section has a broad scope and
> lets discuss that in a separate thread.
>
> With the OSGi, one could be able to write aar & mar as OSGi bundles. Thus,
> when Axis2 start, one can give a repository where services & modules
> available and one could use bundles to mimic this behaviour. When it's
> come to bundles, they could either exist or remove from the system any-time.
> This is dynamism of OSGi and this behaviour is currently not possible with
> current module & service loading mechanism.
>
> Current architecture requires, modules to be available first before services
> are loaded, if modules are referenced by theses services. Thus, services
> have a direct dependency to modules. Even if the service is not faulty, if
> the referenced module is not available, that service become faulty. This
> behaviour contradicts the nature of dynamic behaviour.
>
> Thus, what would really need is modules to be loaded and initialize
> orthogonal of service load and initialization. If loaded service reference
> to a module that is not available yet, marked that service as "unresolved"
> until the module is available. Once the module is available it would be
> easily go thorough the "unresolved" services and marked the relevant
> services as "resolved". Everything will be handle using OSGi events, which
> is very powerful and flexible. There could be other events that make the
> service "unresolved", but the major one is module.
>
> Where there are 100s of bundles available in the system, its not practical
> to assume a start level to bundles. These bundles may mimic Axis2
> services/module or other 3rd party bundle.
>
> I am totally fine with current deployment mechanism, but in order to obtain
> a tighter integration we would have to revisit the current deployment
> semantics. In addition to this standardizing this on Axis2 provide unique
> user experience among the Axis2 community.
>
> I am really appreciate if Axis2 folks comment on prior.
>
> Thank you!
>
> Saminda
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org