Eclipse Community Forums: Equinox » equinox for the J2EE server details

Home » Eclipse Projects » Equinox » equinox for the J2EE server details

equinox for the J2EE server details [message #108543]

Wed, 23 April 2008 11:23

Eclipse User

Originally posted by: shawndgarner.hotmail.com

I think I understand how OSGI works for like RCP apps but I'm not sure how
to incorporate it into a J2EE server environment.
I've looked at the equinox server page (haven't looked too much at the
examples yet).
I just wanted to know if it can be used to solve our JAR/Classloader hell
problems in our J2EE environment.
We have shared library jars and different libraries in the ear/war levels.
1) We run into classloader issues on versions of jars and which
classloader is loading them.
2) We also run into problems where we want to use something already
created but it has the same dependency jar files that are already being
used but a different version of the jar that is incompatible. (Tends to be
commons lang or commons logging or spring)
3) Certain services have jars (axis) that are incompatible with our
environment. I would like to insulate our environment away from the jar
but still use the service (by moving to a component black box).
4) Our shared library jars (or any in the war/ear levels to that matter)
can not be swapped runtime without a server cycle.

An overview as to the fit of equinox would be appreciated.

Re: equinox for the J2EE server details [message #108641 is a reply to message #108543]

Wed, 23 April 2008 13:53

Eclipse User

firehose --
http://www.scs.carleton.ca/~deugo/thesis/simon-kaegi/thesis- sk-final.pdf

"Shawn" <shawndgarner@hotmail.com> wrote in message
news:d94fd7d6725c059dd9838842a6e4e411$1@www.eclipse.org...
>I think I understand how OSGI works for like RCP apps but I'm not sure how
>to incorporate it into a J2EE server environment.
> I've looked at the equinox server page (haven't looked too much at the
> examples yet).
> I just wanted to know if it can be used to solve our JAR/Classloader hell
> problems in our J2EE environment.
> We have shared library jars and different libraries in the ear/war levels.
> 1) We run into classloader issues on versions of jars and which
> classloader is loading them. 2) We also run into problems where we want
> to use something already created but it has the same dependency jar files
> that are already being used but a different version of the jar that is
> incompatible. (Tends to be commons lang or commons logging or spring)
> 3) Certain services have jars (axis) that are incompatible with our
> environment. I would like to insulate our environment away from the jar
> but still use the service (by moving to a component black box).
> 4) Our shared library jars (or any in the war/ear levels to that matter)
> can not be swapped runtime without a server cycle.
>
> An overview as to the fit of equinox would be appreciated.
>
>
>

Re: equinox for the J2EE server details [message #108750 is a reply to message #108641]

Thu, 24 April 2008 02:18

Eclipse User

Originally posted by: shawndgarner.hotmail.com

I read this paper and thought it was really interesting and well prepared
but I'm still not sure equinox will do what I want.

I'm using JSF/Tiles/Spring for the UI.
I don't want to change any of this.

It looks like the Http Bridge acts as a proxy and delegates requests to
registered servlets/jsp pages which are in bundles.

This is not what I want to do.

What I want to do is have my JSF managed backing bean be able to call a
service interface implementation in an OSGI plugin.

1) This is what I want to do:
JSF Page->JSF Servlet->JSF Framework->managed backing bean->osgi service
interface (osgi would dynamically get the service implementation)

2) What the Http Bridge looks like it does is:
JSF Page->OSGI Servlet->Delegate to JSF Servlet->JSF Framework->managed
backing bean->service call

One problem with 2 above is I don't think it will handle the filters/etc
on the servlets for JSF.
Another problem with 2 is I don't see the need to bundle UI Layer objects
in OSGI. If they are designed right they only depend on service layer
interfaces anyway.

Did I misunderstand the paper?

Is there a way to implement OSGi to be used like number 1 above?

Re: equinox for the J2EE server details [message #108764 is a reply to message #108750]

Thu, 24 April 2008 08:46

Eclipse User

Hi,

Let's look at an ASCII illustration to get a common understanding of
OSGi classloading.

-----------------------------
| JVM |
| ------------------------- |
| | Application Server | |
| | (shared/common jars) | |
| | --------------------- | |
| | | WAR | | |
| | | WEB-INF/lib | | |
| | | WEB-INF/classes | | |
| | | ----------------- | | |
| | | | OSGi Bundle 1 | | | |
| | | ----------------| | | |
| | | | OSGi Bundle 2 | | | |
| | | ----------------| | | |
| | | | OSGi Bundle N | | | |
| | | ----------------- | | |
| | --------------------- | |
| ------------------------- |
-----------------------------

The easy way is from the inner to the outer, i.e. classes in the inner
container always have access to classes in the outer container.

One exception to this rule is OSGi. If you don't export additional
packages in the servletbridge bundles only see the JVM packages. This
behavior is configurable.

The problematic access path is if the outer container wants to access
classes loaded in an inner container. This requires reflection and/or
additionally serialization/deserialization.

Thus, accessing the OSGi service registry from code in WEB-INF/lib (or
WEB-INF/classes) is challenging.

An easier way would be to define the service interface in the WAR file
together with a factory/provider. The interface can then be implemented
in an OSGi bundle. Upon bundle start the OSGi bundle calls the factory
and injects its service implementation provider. On bundle stop it would
remove the injected provider from the factory.

-Gunnnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: equinox for the J2EE server details [message #108807 is a reply to message #108764]

Thu, 24 April 2008 13:45

Eclipse User

Originally posted by: shawndgarner.hotmail.com

> -----------------------------
> | JVM |
> | ------------------------- |
> | | Application Server | |
> | | (shared/common jars) | |
> | | --------------------- | |
> | | | WAR | | |
> | | | WEB-INF/lib | | |
> | | | WEB-INF/classes | | |
> | | | ----------------- | | |
> | | | | OSGi Bundle 1 | | | |
> | | | ----------------| | | |
> | | | | OSGi Bundle 2 | | | |
> | | | ----------------| | | |
> | | | | OSGi Bundle N | | | |
> | | | ----------------- | | |
> | | --------------------- | |
> | ------------------------- |
> -----------------------------

This sounds like what I want to do.

> An easier way would be to define the service interface in the WAR file
> together with a factory/provider. The interface can then be implemented
> in an OSGi bundle. Upon bundle start the OSGi bundle calls the factory
> and injects its service implementation provider. On bundle stop it would
> remove the injected provider from the factory.

What I still don't understand is how to load OSGi in a J2EE environment so
it knows to load the bundles and how to tell it where bundles are.

Also in addition to loading OSGi bundles inside the war like the examples
I've seen I would like a shared library type of OSGi bundle external to
the ear. For example we have shared libraries that are on the ear level
classloader that the war can see. I'd like to tell OSGi to load a bundle
from that classpath location. This way all the dependent jars can be in
the shared library OSGi bundle and not affect any dependencies other EAR
level shared libraries have or bubble up to fill an unanticipated missing
JAR at the warlevel.

Re: equinox for the J2EE server details [message #108833 is a reply to message #108807]

Thu, 24 April 2008 16:06

Eclipse User

Shawn schrieb:
> What I still don't understand is how to load OSGi in a J2EE environment so
> it knows to load the bundles and how to tell it where bundles are.

The servlet bridge does it. You simply register the servlet bridge
servlet in the web.xml and set it to load on startup. Then the servlet
bridge will "launch" the Equinox framework.

> Also in addition to loading OSGi bundles inside the war like the examples
> I've seen I would like a shared library type of OSGi bundle external to
> the ear.

This is not possible. You can place any JAR in an outer scope and make
it's classes available to the OSGi world. But this is not loaded as or
treated like an OSGi bundle. It's loaded by the outer scope's
classloader which is out of scope to be managed by an OSGi runtime.

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: equinox for the J2EE server details [message #108846 is a reply to message #108833]

Fri, 25 April 2008 09:43

Eclipse User

Originally posted by: shawndgarner.hotmail.com

> This is not possible. You can place any JAR in an outer scope and make
> it's classes available to the OSGi world. But this is not loaded as or
> treated like an OSGi bundle. It's loaded by the outer scope's
> classloader which is out of scope to be managed by an OSGi runtime.

What if you treated the classpath as a resource reference that the
container could give an actual physical location for?

So for instance you defined a resource reference of type java.lang.String
in the web.xml.
Then in the container configuration of the war you pointed it to a
physical plugin directory. EG: d:/commonfiles/myawesomecommonfiles/plugin

Then could you tell OSGi to load all plugins from the location external to
the war but it would be the same classloader that the war uses so it would
have vision I would think.

Would this work?

Re: equinox for the J2EE server details [message #108859 is a reply to message #108846]

Fri, 25 April 2008 15:45

Eclipse User

Shawn schrieb:
> Then could you tell OSGi to load all plugins from the location external to
> the war but it would be the same classloader that the war uses so it would
> have vision I would think.

This wouldn't work. OSGi always creates a new classloader for every bundle.

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: equinox for the J2EE server details [message #108869 is a reply to message #108859]

Fri, 25 April 2008 23:26

Eclipse User

Originally posted by: shawndgarner.hotmail.com

Gunnar Wagenknecht wrote:

> Shawn schrieb:
>> Then could you tell OSGi to load all plugins from the location external to
>> the war but it would be the same classloader that the war uses so it would
>> have vision I would think.

> This wouldn't work. OSGi always creates a new classloader for every bundle.

> -Gunnar

I realize it creates a new classloder for stuff inside the bundle.
You should be able to still export and use the service though.

Re: equinox for the J2EE server details [message #108882 is a reply to message #108859]

Sat, 26 April 2008 12:16

Eclipse User

Originally posted by: shawndgarner.hotmail.com

I looked at the code and it seems that you should be able to load plugins
defined by a resource reference at the same time FrameworkLauncher loads
the rest of the plugins. It copies the plugins directory from the war to
the temp directory anyway. It should be able to copy plugins from
external locations defined by a resource reference too.
You would need to build your own custom bridge.war

After looking at the code It occurs to me that it seems you're trying to
do everything starting at the servlet through OSGI.

Seems overly complex to me.

I just want some black-box bundles that expose only the interface so you
don't have conflicting jars.

I don't want the entire app to be osgi. There should be a way to access
the framework and look up an exposed service from outside OSGi.

Re: equinox for the J2EE server details [message #108894 is a reply to message #108882]

Sun, 27 April 2008 17:28

Eclipse User

Originally posted by: shawndgarner.hotmail.com

Seems like the EclipseStarter returns a BundleContext which I could use to
create a ServiceTracker and use to call the services from OSGi in my web
application.
Would have to add a BundleContext to FrameworkLauncher as a protected
member variable. Then you could write a wrapper to get whatever service
you wanted from OSGi with it.

Re: equinox for the J2EE server details [message #109005 is a reply to message #108543]

Wed, 30 April 2008 09:50

Eclipse User

Originally posted by: joerg.von.frantzius.artnology.com

There's a new "application server" based entirely on OSGi also for
application packaging, if I got it right:
http://feeds.feedburner.com/~r/IanSkerrett/~3/280775031/

It's not J2EE compatible, but I guess they'll at least support some
parts of it (otherwise I'd wonder why they call it an application server).

Does anybody know whether it has a JTA, for example?

Shawn schrieb:
> I think I understand how OSGI works for like RCP apps but I'm not sure
> how to incorporate it into a J2EE server environment.
> I've looked at the equinox server page (haven't looked too much at the
> examples yet).
> I just wanted to know if it can be used to solve our JAR/Classloader
> hell problems in our J2EE environment.
> We have shared library jars and different libraries in the ear/war
> levels.
> 1) We run into classloader issues on versions of jars and which
> classloader is loading them. 2) We also run into problems where we
> want to use something already created but it has the same dependency
> jar files that are already being used but a different version of the
> jar that is incompatible. (Tends to be commons lang or commons logging
> or spring)
> 3) Certain services have jars (axis) that are incompatible with our
> environment. I would like to insulate our environment away from the
> jar but still use the service (by moving to a component black box).
> 4) Our shared library jars (or any in the war/ear levels to that
> matter) can not be swapped runtime without a server cycle.
>
> An overview as to the fit of equinox would be appreciated.
>
>
>

Previous Topic:	Tomcat based implementation of OSGI HTTP Service
Next Topic:	p2 provisioning non-Eclipse applications

Goto Forum:

-=] Back to Top [=-

Current Time: Fri May 23 19:19:40 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter