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 < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > Samisa Abeysinghe > > http://people.apache.org/~samisa/ <http://people.apache.org/%7Esamisa/> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org
