You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jacek Laskowski <ja...@laskowski.net.pl> on 2009/10/21 15:32:22 UTC
openejb as a osgi service?
Hi,
I've lately been wondering about the other pieces for openejb
osgi'fication and am stuck. I'll need your help or I won't do any
further step as thinking has grabbed my free cycles completely.
OSGi may seem as quite a different technology, but what it does with
our development perspective is to think about classloaders and
services. Everything in OSGi is just about classloaders/services and
its implication to the app.
There're the openejb bundles, but they're nothing more than just a
collection of classes. If you run a osgi provider and staff it with
these bundles, they're started, but it doesn't mean openejb is started
itself. When a bundle is started, it just means that the
imports/exports are resolved and available. OpenEJB could not be
started yet. It's an activator (an instance of
org.osgi.framework.BundleActivator) that's responsible for doing
what's required to fully start the bundlized application (in our case
- openejb). A bundle gives its classes/interfaces via exports or
services. The exports are to let others compose their classloaders
with necessary classes provided by other bundles. So, once the bundles
are started, the activator kicks in and do the job of starting the
app. That's where I'm stack. I need to create necessary openejb
services (in OSGi terms). Can you point me to the simplest way to boot
openejb? The about-to-be-created OSGi service for OpenEJB is just like
LocalInitialContextFactory that boots openejb when a lookup is fired
and holds a reference to it - exactly what the future osgi service
will do.
...after a while...
After a couple of minutes reading the email of mine over and over
again, I think I'll figure out what I was after. I just need to copy
what's in LocalInitialContextFactory! :) So, here goes another
question - how do I deploy an ejb? A test case would be of much help.
I need a way to get a reference to the just-deployed ejb, so I'll be
able to expose it as a osgi service. It should work, doesn't it?
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: openejb as a osgi service?
Posted by "Jay D. McHugh" <ja...@jnwd.net>.
Jacek,
Have you seen the JNDI bundles provided by Aries?
I have avoided the implementation OpenEJB up until now and for the most
part, I have used injection to get bean instances (rather than looking
them up). But, it seems like we should be able to use what they
developed there rather than having to develop it here.
But like I said - this is the (hopeful) opinion who does not have any of
the facts.
Jay
Jacek Laskowski wrote:
> On Wed, Oct 21, 2009 at 4:26 PM, Quintin Beukes <qu...@skywalk.co.za> wrote:
>
>> Hope it helps.
>
> Yes, it did, but I had a vague idea of what I should have been doing
> and didn't pay much attention to these classes.
>
> I've just committed a working activator to boot up openejb to
> https://svn.apache.org/repos/asf/openejb/trunk/sandbox/openejb-osgi.
>
> The necessary bundles are as follows:
>
> -> ps
> START LEVEL 1
> ID State Level Name
> [ 0] [Active ] [ 0] System Bundle (2.0.0)
> [ 1] [Active ] [ 1] Apache Felix Bundle Repository (1.4.1)
> [ 2] [Active ] [ 1] Apache Felix Shell Service (1.4.0)
> [ 3] [Active ] [ 1] Apache Felix Shell TUI (1.4.0)
> [ 7] [Active ] [ 1] Apache OpenEJB :: Container :: Java EE
> (3.1.2.SNAPSHOT)
> [ 8] [Active ] [ 1] file:/C:/.m2/wsdl4j/wsdl4j/1.6.1/wsdl4j-1.6.1.jar
> [ 9] [Active ] [ 1] Apache XBean :: Naming (3.6.0.SNAPSHOT)
> [ 14] [Active ] [ 1] Apache XBean :: ASM shaded (repackaged)
> (3.7.0.SNAPSHOT)
> [ 15] [Active ] [ 1] Apache XBean :: Reflect (3.6.0.SNAPSHOT)
> [ 23] [Active ] [ 1] Apache OpenEJB :: Container :: Loader
> (3.1.2.SNAPSHOT)
> [ 25] [Active ] [ 1] OPS4J Pax Url - wrap: (0.3.2)
> [ 26] [Active ] [ 1] Apache Felix Configuration Admin Service (1.2.4)
> [ 27] [Active ] [ 1]
> wrap_http___repo1.maven.org_maven2_wsdl4j_wsdl4j_1.6.2_wsdl4j-1.6.2.jar
> (0)
> [ 30] [Active ] [ 1]
> wrap_file__C__.m2_commons-cli_commons-cli_1.1_commons-cli-1.1.jar (0)
> [ 33] [Active ] [ 1]
> wrap_file__C__.m2_log4j_log4j_1.2.12_log4j-1.2.12.jar (0)
> [ 34] [Active ] [ 1] openejb-api (3.1.2.SNAPSHOT)
> [ 35] [Active ] [ 1] Apache OpenEJB :: Container :: Java Agent
> (3.1.2.SNAPSHOT)
> [ 36] [Active ] [ 1] Apache XBean :: Finder shaded
> (repackaged) (3.7.0.SNAPSHOT)
> [ 37] [Active ] [ 1] Apache OpenEJB :: Container :: Core
> (3.1.2.SNAPSHOT)
> [ 57] [Active ] [ 1] Ejb_stateless (1.0.0)
> [ 58] [Active ] [ 1] Ejb_deployer (1.0.0)
> [ 62] [Active ] [ 1] Apache OpenEJB :: Container :: Core ::
> OSGi (3.1.2.SNAPSHOT)
> [ 64] [Active ] [ 1] Apache ServiceMix Features :: Transaction
> (4.0.0.m1)
> [ 65] [Active ] [ 1] Jencks (2.2)
> [ 66] [Active ] [ 1] geronimo-jms_1.1_spec (1.1.1)
> [ 67] [Active ] [ 1] geronimo-j2ee-connector_1.5_spec (2.0.0)
> [ 68] [Active ] [ 1] geronimo-servlet_2.5_spec (1.2)
> [ 69] [Active ] [ 1]
> wrap_http___repo2.maven.org_maven2_commons-logging_commons-logging_1.1.1_commons-logging-1.1.1.jar
> (0)
> [ 71] [Active ] [ 1] OPS4J Pax Logging - API (1.4)
> [ 73] [Active ] [ 1] Geronimo TxManager :: Connector (2.1.3)
> [ 74] [Active ] [ 1] Geronimo TxManager :: Transaction (2.1.3)
> [ 75] [Active ] [ 1] Spring AOP (2.5.6.SEC01)
> [ 76] [Active ] [ 1] Spring Beans (2.5.6.SEC01)
> [ 77] [Active ] [ 1] Spring Context (2.5.6.SEC01)
> [ 78] [Active ] [ 1] Spring Transaction (2.5.6.SEC01)
> [ 79] [Active ] [ 1] geronimo-annotation_1.0_spec (1.1.1)
> [ 80] [Active ] [ 1] geronimo-ejb_3.0_spec (1.0.1)
> [ 81] [Active ] [ 1] geronimo-interceptor_3.0_spec (1.0.1)
> [ 82] [Active ] [ 1] geronimo-javamail_1.4_spec (1.6)
> [ 83] [Active ] [ 1] geronimo-j2ee-management_1.1_spec (1.0.1)
> [ 84] [Active ] [ 1] geronimo-jpa_3.0_spec (1.1.1)
> [ 85] [Active ] [ 1] J2EE JACC 1.1 (1.0.2)
> [ 86] [Active ] [ 1] geronimo-jta_1.1_spec (1.1.1)
> [ 87] [Active ] [ 1] OPS4J Pax Logging - Service (1.4)
> [ 90] [Active ] [ 1] Apache Commons Pool (1.4.0)
> [ 95] [Active ] [ 1] Commons DBCP (1.3.0.r699049)
> [ 99] [Active ] [ 1]
> wrap_http___repo2.maven.org_maven2_org_apache_activemq_activemq-ra_4.1.1_activemq-ra-4.1.1.jar
> (0)
> [ 100] [Active ] [ 1]
> wrap_http___repo2.maven.org_maven2_org_apache_activemq_activemq-core_4.1.1_activemq-core-4.1.1.jar
> (0)
> [ 101] [Active ] [ 1]
> wrap_http___repo1.maven.org_maven2_backport-util-concurrent_backport-util-concurrent_3.1_backport-util-concurrent-3.1.jar
> (0)
>
> I'll need to give it a try again and filter out what's unnecessary
> (perhaps 1-2 bundles only).
>
> The output upon openejb startup is as follows:
>
> Activator started
> DEBUG: org/apache/openejb/util/resources/Messages_pl.properties
> DEBUG: org/apache/openejb/util/resources/Messages_pl_PL.properties
> Apache OpenEJB ${pom.version} build:
> @DATE-REPLACED-BY-MAVEN@-@TIME-REPLACED-BY-MAVEN@
> http://openejb.apache.org/
> DEBUG: org/apache/openejb/util/Messages.properties
> DEBUG: org/apache/openejb/util/Messages_pl.properties
> DEBUG: org/apache/openejb/util/Messages_pl_PL.properties
> DEBUG: org/apache/openejb/Messages.properties
> DEBUG: org/apache/openejb/Messages_pl.properties
> DEBUG: org/apache/openejb/Messages_pl_PL.properties
> DEBUG: org/apache/openejb/assembler/classic/Messages_pl.properties
> DEBUG: org/apache/openejb/assembler/classic/Messages_pl_PL.properties
> DEBUG: org/apache/openejb/config/Messages_pl.properties
> DEBUG: org/apache/openejb/config/Messages_pl_PL.properties
> DEBUG: META-INF/services/javax.xml.parsers.SAXParserFactory
> DEBUG: org/apache/openejb/config/sys/jaxb.properties
> DEBUG: META-INF/services/javax.xml.bind.JAXBContext
> DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
> DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
> DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
> DEBUG: META-INF/services/javax.xml.parsers.SAXParserFactory
> DEBUG: META-INF/services/org/apache/activemq/broker/broker
> [org.apache.activemq.broker.BrokerService] : ActiveMQ 4.1.1 JMS
> Message Broker (localhost) is starting
> [org.apache.activemq.broker.BrokerService] : For help or more
> information please see: http://incubator.apache.org/activemq/
> DEBUG: META-INF/services/org/apache/activemq/transport/tcp
> DEBUG: META-INF/services/org/apache/activemq/wireformat/default
> [org.apache.activemq.transport.TransportServerThreadSupport] :
> Listening for connections at: tcp://work:61616
> [org.apache.activemq.broker.TransportConnector] : Connector
> tcp://work:61616 Started
> [org.apache.activemq.broker.BrokerService] : ActiveMQ JMS Message
> Broker (localhost, ID:work-3337-1256173063703-0:0) started
> ...A bundle has been started: org.apache.openejb.core-osgi
>
> I'm going to work on a osgi'fied client JNDI lookup now that will
> require a openejb service. Then deployment and it should be ready for
> polishing.
>
> Jacek
>
Re: openejb as a osgi service?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Wed, Oct 21, 2009 at 4:26 PM, Quintin Beukes <qu...@skywalk.co.za> wrote:
> Hope it helps.
Yes, it did, but I had a vague idea of what I should have been doing
and didn't pay much attention to these classes.
I've just committed a working activator to boot up openejb to
https://svn.apache.org/repos/asf/openejb/trunk/sandbox/openejb-osgi.
The necessary bundles are as follows:
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (2.0.0)
[ 1] [Active ] [ 1] Apache Felix Bundle Repository (1.4.1)
[ 2] [Active ] [ 1] Apache Felix Shell Service (1.4.0)
[ 3] [Active ] [ 1] Apache Felix Shell TUI (1.4.0)
[ 7] [Active ] [ 1] Apache OpenEJB :: Container :: Java EE
(3.1.2.SNAPSHOT)
[ 8] [Active ] [ 1] file:/C:/.m2/wsdl4j/wsdl4j/1.6.1/wsdl4j-1.6.1.jar
[ 9] [Active ] [ 1] Apache XBean :: Naming (3.6.0.SNAPSHOT)
[ 14] [Active ] [ 1] Apache XBean :: ASM shaded (repackaged)
(3.7.0.SNAPSHOT)
[ 15] [Active ] [ 1] Apache XBean :: Reflect (3.6.0.SNAPSHOT)
[ 23] [Active ] [ 1] Apache OpenEJB :: Container :: Loader
(3.1.2.SNAPSHOT)
[ 25] [Active ] [ 1] OPS4J Pax Url - wrap: (0.3.2)
[ 26] [Active ] [ 1] Apache Felix Configuration Admin Service (1.2.4)
[ 27] [Active ] [ 1]
wrap_http___repo1.maven.org_maven2_wsdl4j_wsdl4j_1.6.2_wsdl4j-1.6.2.jar
(0)
[ 30] [Active ] [ 1]
wrap_file__C__.m2_commons-cli_commons-cli_1.1_commons-cli-1.1.jar (0)
[ 33] [Active ] [ 1]
wrap_file__C__.m2_log4j_log4j_1.2.12_log4j-1.2.12.jar (0)
[ 34] [Active ] [ 1] openejb-api (3.1.2.SNAPSHOT)
[ 35] [Active ] [ 1] Apache OpenEJB :: Container :: Java Agent
(3.1.2.SNAPSHOT)
[ 36] [Active ] [ 1] Apache XBean :: Finder shaded
(repackaged) (3.7.0.SNAPSHOT)
[ 37] [Active ] [ 1] Apache OpenEJB :: Container :: Core
(3.1.2.SNAPSHOT)
[ 57] [Active ] [ 1] Ejb_stateless (1.0.0)
[ 58] [Active ] [ 1] Ejb_deployer (1.0.0)
[ 62] [Active ] [ 1] Apache OpenEJB :: Container :: Core ::
OSGi (3.1.2.SNAPSHOT)
[ 64] [Active ] [ 1] Apache ServiceMix Features :: Transaction
(4.0.0.m1)
[ 65] [Active ] [ 1] Jencks (2.2)
[ 66] [Active ] [ 1] geronimo-jms_1.1_spec (1.1.1)
[ 67] [Active ] [ 1] geronimo-j2ee-connector_1.5_spec (2.0.0)
[ 68] [Active ] [ 1] geronimo-servlet_2.5_spec (1.2)
[ 69] [Active ] [ 1]
wrap_http___repo2.maven.org_maven2_commons-logging_commons-logging_1.1.1_commons-logging-1.1.1.jar
(0)
[ 71] [Active ] [ 1] OPS4J Pax Logging - API (1.4)
[ 73] [Active ] [ 1] Geronimo TxManager :: Connector (2.1.3)
[ 74] [Active ] [ 1] Geronimo TxManager :: Transaction (2.1.3)
[ 75] [Active ] [ 1] Spring AOP (2.5.6.SEC01)
[ 76] [Active ] [ 1] Spring Beans (2.5.6.SEC01)
[ 77] [Active ] [ 1] Spring Context (2.5.6.SEC01)
[ 78] [Active ] [ 1] Spring Transaction (2.5.6.SEC01)
[ 79] [Active ] [ 1] geronimo-annotation_1.0_spec (1.1.1)
[ 80] [Active ] [ 1] geronimo-ejb_3.0_spec (1.0.1)
[ 81] [Active ] [ 1] geronimo-interceptor_3.0_spec (1.0.1)
[ 82] [Active ] [ 1] geronimo-javamail_1.4_spec (1.6)
[ 83] [Active ] [ 1] geronimo-j2ee-management_1.1_spec (1.0.1)
[ 84] [Active ] [ 1] geronimo-jpa_3.0_spec (1.1.1)
[ 85] [Active ] [ 1] J2EE JACC 1.1 (1.0.2)
[ 86] [Active ] [ 1] geronimo-jta_1.1_spec (1.1.1)
[ 87] [Active ] [ 1] OPS4J Pax Logging - Service (1.4)
[ 90] [Active ] [ 1] Apache Commons Pool (1.4.0)
[ 95] [Active ] [ 1] Commons DBCP (1.3.0.r699049)
[ 99] [Active ] [ 1]
wrap_http___repo2.maven.org_maven2_org_apache_activemq_activemq-ra_4.1.1_activemq-ra-4.1.1.jar
(0)
[ 100] [Active ] [ 1]
wrap_http___repo2.maven.org_maven2_org_apache_activemq_activemq-core_4.1.1_activemq-core-4.1.1.jar
(0)
[ 101] [Active ] [ 1]
wrap_http___repo1.maven.org_maven2_backport-util-concurrent_backport-util-concurrent_3.1_backport-util-concurrent-3.1.jar
(0)
I'll need to give it a try again and filter out what's unnecessary
(perhaps 1-2 bundles only).
The output upon openejb startup is as follows:
Activator started
DEBUG: org/apache/openejb/util/resources/Messages_pl.properties
DEBUG: org/apache/openejb/util/resources/Messages_pl_PL.properties
Apache OpenEJB ${pom.version} build:
@DATE-REPLACED-BY-MAVEN@-@TIME-REPLACED-BY-MAVEN@
http://openejb.apache.org/
DEBUG: org/apache/openejb/util/Messages.properties
DEBUG: org/apache/openejb/util/Messages_pl.properties
DEBUG: org/apache/openejb/util/Messages_pl_PL.properties
DEBUG: org/apache/openejb/Messages.properties
DEBUG: org/apache/openejb/Messages_pl.properties
DEBUG: org/apache/openejb/Messages_pl_PL.properties
DEBUG: org/apache/openejb/assembler/classic/Messages_pl.properties
DEBUG: org/apache/openejb/assembler/classic/Messages_pl_PL.properties
DEBUG: org/apache/openejb/config/Messages_pl.properties
DEBUG: org/apache/openejb/config/Messages_pl_PL.properties
DEBUG: META-INF/services/javax.xml.parsers.SAXParserFactory
DEBUG: org/apache/openejb/config/sys/jaxb.properties
DEBUG: META-INF/services/javax.xml.bind.JAXBContext
DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
DEBUG: META-INF/services/javax.xml.datatype.DatatypeFactory
DEBUG: META-INF/services/javax.xml.parsers.SAXParserFactory
DEBUG: META-INF/services/org/apache/activemq/broker/broker
[org.apache.activemq.broker.BrokerService] : ActiveMQ 4.1.1 JMS
Message Broker (localhost) is starting
[org.apache.activemq.broker.BrokerService] : For help or more
information please see: http://incubator.apache.org/activemq/
DEBUG: META-INF/services/org/apache/activemq/transport/tcp
DEBUG: META-INF/services/org/apache/activemq/wireformat/default
[org.apache.activemq.transport.TransportServerThreadSupport] :
Listening for connections at: tcp://work:61616
[org.apache.activemq.broker.TransportConnector] : Connector
tcp://work:61616 Started
[org.apache.activemq.broker.BrokerService] : ActiveMQ JMS Message
Broker (localhost, ID:work-3337-1256173063703-0:0) started
...A bundle has been started: org.apache.openejb.core-osgi
I'm going to work on a osgi'fied client JNDI lookup now that will
require a openejb service. Then deployment and it should be ready for
polishing.
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: openejb as a osgi service?
Posted by Quintin Beukes <qu...@skywalk.co.za>.
My mind is flooding with so much new information I can't make sense of
it yet. So this might not help you at all, in which case I apologize.
Either way, what you are trying to do seems very much like what
Geronimo does regarding GBeans. When the EJB is deployed, it's done
through the EjbDeploymentGBean, which creates a GBean data for the
EJB, for it to be exposed as/through a GBean. The last part I'm not
too sure off, but you could maybe take a look at the code in
geronimo's 2.2/branch. A stack trace of this is available through the
following {geronimo}/plugins/openejb/geronimo-openejb-builders/->org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.initContext().
At this point you can see the full strack trace of where things came
from deploying an EJB via a GBean.
Also have a look at plugins/openejb/geronimo-openejb ->
org.apache.geronimo.openejb.EjbDeploymentGBean and {x}DeploymentGBean,
and so on. I assume when doing it via OSGi you would need different
service implementations for the different beans, like it is currently
with the GBeans. In general these 2 geronimo-openejb projects have a
lot of what sounds like your requirements.
Hope it helps.
Quintin Beukes
On Wed, Oct 21, 2009 at 3:32 PM, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> Hi,
>
> I've lately been wondering about the other pieces for openejb
> osgi'fication and am stuck. I'll need your help or I won't do any
> further step as thinking has grabbed my free cycles completely.
>
> OSGi may seem as quite a different technology, but what it does with
> our development perspective is to think about classloaders and
> services. Everything in OSGi is just about classloaders/services and
> its implication to the app.
>
> There're the openejb bundles, but they're nothing more than just a
> collection of classes. If you run a osgi provider and staff it with
> these bundles, they're started, but it doesn't mean openejb is started
> itself. When a bundle is started, it just means that the
> imports/exports are resolved and available. OpenEJB could not be
> started yet. It's an activator (an instance of
> org.osgi.framework.BundleActivator) that's responsible for doing
> what's required to fully start the bundlized application (in our case
> - openejb). A bundle gives its classes/interfaces via exports or
> services. The exports are to let others compose their classloaders
> with necessary classes provided by other bundles. So, once the bundles
> are started, the activator kicks in and do the job of starting the
> app. That's where I'm stack. I need to create necessary openejb
> services (in OSGi terms). Can you point me to the simplest way to boot
> openejb? The about-to-be-created OSGi service for OpenEJB is just like
> LocalInitialContextFactory that boots openejb when a lookup is fired
> and holds a reference to it - exactly what the future osgi service
> will do.
>
> ...after a while...
>
> After a couple of minutes reading the email of mine over and over
> again, I think I'll figure out what I was after. I just need to copy
> what's in LocalInitialContextFactory! :) So, here goes another
> question - how do I deploy an ejb? A test case would be of much help.
> I need a way to get a reference to the just-deployed ejb, so I'll be
> able to expose it as a osgi service. It should work, doesn't it?
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>
Re: openejb as a osgi service?
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Fully agree.
We definitely have to make some changes in OpenEJB to make it a fully
OSGi-based solution.
Some days ago, Guillaume pointed me some interesting code.
I have been very busy, but will try to help you as much as possible.
Jean-Louis
Jacek Laskowski wrote:
>
> On Sat, Nov 14, 2009 at 1:30 AM, Jay D. McHugh <ja...@jnwd.net> wrote:
>
>> So, I was thinking of the JEE container as being a black box that would
>> allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
>> without knowing or caring that the server was internally implemented as
>> a collection of OSGi bundles.
>>
>> In this scenario, the server would need to have an EJB container that
>> would receive a non-OSGi artifact and would then need to make all of the
>> EJBs contained in it injectable (or findable through JNDI).
>>
>> To accomplish this, OpenEJB would then (need to?) be deployed as a
>> bundle that provided the EJB supporting services and a second bundle
>> that created a container utilizing those services. Is that what you
>> (and others) were thinking?
>
> Hi Jay et al,
>
> I was busy with Clojure lately which turned out have made me busy for
> longer than I expected. On to OSGi...
>
> The approach above is just one way to claim a EJB container is based
> upon OSGi and most application servers (WAS, GlassFish, perhaps JOnAS)
> does exactly this. OSGi serves as a componentization layer and is used
> internally. There's no change from a user's perspective.
>
> What I thought of to implement in OpenEJB was a different approach. Do
> the above, but let OpenEJB's services be exposed as OSGi services and
> therefore become a truly OSGi-based solution. If a developer wants to
> play according to Java EE rules - appropriate packaging and placing
> libraries in *the* directories - let him/her be with it. What makes me
> more appealing to OSGi is the way OpenEJB should handle hot
> redeployment of dependent libraries without stopping the server
> itself. If OpenEJB let enterprise applications be built with their
> libraries deployed as bundles, it would greatly minimize memory
> requirements and allow end users redeploy them without touching the
> apps themselves. If these enterprise applications were able to
> leverage OpenEJB services *and* OSGi componentization that'd be way
> better. That's my goal for OSGi integration.
>
> Running an app atop OSGi is simple, just create a single bundle with
> all that's needed and that's it. I'd prefer OpenEJB be built
> dynamically at runtime. You want a SLSB container just install
> appropriate bundle and have fun. If the container is no longer needed
> just uninstall it. No more expensive (=time consuming) restarts or
> redeployments. The same I'd like to see for EJBs deployed onto
> OpenEJB. Their interfaces wouldn't have to be redeployed (provided
> they haven't changed) so they could become a separate bundle (with
> imports) and their implementation become another bundle (set). If it
> needed a change refresh would do the job. Of course, under the covers
> the redeployment would take place, but encouraging our users to
> leverage the OSGi standard and build EJBs in a modular fashion would
> made a huge difference.
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>
>
--
View this message in context: http://old.nabble.com/openejb-as-a-osgi-service--tp25992634p26386948.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: openejb as a osgi service?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Sat, Nov 14, 2009 at 1:30 AM, Jay D. McHugh <ja...@jnwd.net> wrote:
> So, I was thinking of the JEE container as being a black box that would
> allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
> without knowing or caring that the server was internally implemented as
> a collection of OSGi bundles.
>
> In this scenario, the server would need to have an EJB container that
> would receive a non-OSGi artifact and would then need to make all of the
> EJBs contained in it injectable (or findable through JNDI).
>
> To accomplish this, OpenEJB would then (need to?) be deployed as a
> bundle that provided the EJB supporting services and a second bundle
> that created a container utilizing those services. Is that what you
> (and others) were thinking?
Hi Jay et al,
I was busy with Clojure lately which turned out have made me busy for
longer than I expected. On to OSGi...
The approach above is just one way to claim a EJB container is based
upon OSGi and most application servers (WAS, GlassFish, perhaps JOnAS)
does exactly this. OSGi serves as a componentization layer and is used
internally. There's no change from a user's perspective.
What I thought of to implement in OpenEJB was a different approach. Do
the above, but let OpenEJB's services be exposed as OSGi services and
therefore become a truly OSGi-based solution. If a developer wants to
play according to Java EE rules - appropriate packaging and placing
libraries in *the* directories - let him/her be with it. What makes me
more appealing to OSGi is the way OpenEJB should handle hot
redeployment of dependent libraries without stopping the server
itself. If OpenEJB let enterprise applications be built with their
libraries deployed as bundles, it would greatly minimize memory
requirements and allow end users redeploy them without touching the
apps themselves. If these enterprise applications were able to
leverage OpenEJB services *and* OSGi componentization that'd be way
better. That's my goal for OSGi integration.
Running an app atop OSGi is simple, just create a single bundle with
all that's needed and that's it. I'd prefer OpenEJB be built
dynamically at runtime. You want a SLSB container just install
appropriate bundle and have fun. If the container is no longer needed
just uninstall it. No more expensive (=time consuming) restarts or
redeployments. The same I'd like to see for EJBs deployed onto
OpenEJB. Their interfaces wouldn't have to be redeployed (provided
they haven't changed) so they could become a separate bundle (with
imports) and their implementation become another bundle (set). If it
needed a change refresh would do the job. Of course, under the covers
the redeployment would take place, but encouraging our users to
leverage the OSGi standard and build EJBs in a modular fashion would
made a huge difference.
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: openejb as a osgi service?
Posted by "Jay D. McHugh" <ja...@jnwd.net>.
I have been trying to think of this in terms of how a JEE application
server that is implemented completely as OSGi bundles would need its EJB
support to be implemented.
So, I was thinking of the JEE container as being a black box that would
allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
without knowing or caring that the server was internally implemented as
a collection of OSGi bundles.
In this scenario, the server would need to have an EJB container that
would receive a non-OSGi artifact and would then need to make all of the
EJBs contained in it injectable (or findable through JNDI).
To accomplish this, OpenEJB would then (need to?) be deployed as a
bundle that provided the EJB supporting services and a second bundle
that created a container utilizing those services. Is that what you
(and others) were thinking?
Jay
Guillaume Nodet wrote:
> I guess the first question is the goal of this OSGi integration. Is
> the aim to be JEE compatible while the JEE container is deployed in
> OSGi or is the goal to be OSGi friendly in the standalone mode (no JEE
> container, so no full compatibility) ?
> In the first case, we know what need to be done and just need to find
> the best way to do it, while in the second case, we need to find the
> best integration. Those might lead to different paths.
>
> 2009/11/12 Jay D. McHugh <ja...@jnwd.net>:
>> Hello all,
>>
>> I have been thinking about what an EJB provider and container should
>> look like in OSGi too. And here is what I have come up with (please
>> respond with corrections, alternate opinions, and agreement where
>> applicable).
>>
>> Provider issues:
>> First, OpenEJB would need to provide a set of services that would allow
>> for the scanning of a bundle to determine if there are EJBs in it. I
>> believe Jacek has this or something like it done already.
>>
>> Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
>> references to each of the interfaces provided by those EJBs -or- the
>> provider would build and maintain a list of EJBs that are available for
>> inclusion in a container.
>>
>> Container issues:
>> From the container side we would need to figure out how an EJB container
>> is deployed. Is a container a bundle in itself or could a container be
>> created within a larger bundle (or both)?
>>
>> And then, how are those EJBs injected/looked up once they are available
>> in a container. If the JNDI is build up when EJB bundles are started in
>> the OSGi container - then how are the beans that are actually in the
>> container differentiated from the 'prototype' JNDI entries? Or, are the
>> JNDI entries only created when EJBs are included in a container?
>>
>> Lastly, what happens when an EJB is injected or looked up? Does a proxy
>> get returned so that stopped bundles can be handled somewhat gracefully?
>> It seems to me that this is what we would need to do. This would
>> probably overlap with what they have done over in the Tuscany project
>> though.
>>
>> I just remembered that there is an OSGi RFC (142 - which I have not
>> finished reading yet) that deals with the JNDI and probably gives some
>> direction on all of this.
>>
>> So, I've got to get reading - but if anyone has already read the spec,
>> do you have any comments?
>>
>> I have not heard of any spec on how EJB containers should behave in an
>> OSGi environment. Does anyone else have any thoughts (or access to a
>> spec) on how they should?
>>
>>
>> Jay
>>
>> Jacek Laskowski wrote:
>>> Hi,
>>>
>>> I've lately been wondering about the other pieces for openejb
>>> osgi'fication and am stuck. I'll need your help or I won't do any
>>> further step as thinking has grabbed my free cycles completely.
>>>
>>> OSGi may seem as quite a different technology, but what it does with
>>> our development perspective is to think about classloaders and
>>> services. Everything in OSGi is just about classloaders/services and
>>> its implication to the app.
>>>
>>> There're the openejb bundles, but they're nothing more than just a
>>> collection of classes. If you run a osgi provider and staff it with
>>> these bundles, they're started, but it doesn't mean openejb is started
>>> itself. When a bundle is started, it just means that the
>>> imports/exports are resolved and available. OpenEJB could not be
>>> started yet. It's an activator (an instance of
>>> org.osgi.framework.BundleActivator) that's responsible for doing
>>> what's required to fully start the bundlized application (in our case
>>> - openejb). A bundle gives its classes/interfaces via exports or
>>> services. The exports are to let others compose their classloaders
>>> with necessary classes provided by other bundles. So, once the bundles
>>> are started, the activator kicks in and do the job of starting the
>>> app. That's where I'm stack. I need to create necessary openejb
>>> services (in OSGi terms). Can you point me to the simplest way to boot
>>> openejb? The about-to-be-created OSGi service for OpenEJB is just like
>>> LocalInitialContextFactory that boots openejb when a lookup is fired
>>> and holds a reference to it - exactly what the future osgi service
>>> will do.
>>>
>>> ...after a while...
>>>
>>> After a couple of minutes reading the email of mine over and over
>>> again, I think I'll figure out what I was after. I just need to copy
>>> what's in LocalInitialContextFactory! :) So, here goes another
>>> question - how do I deploy an ejb? A test case would be of much help.
>>> I need a way to get a reference to the just-deployed ejb, so I'll be
>>> able to expose it as a osgi service. It should work, doesn't it?
>>>
>>> Jacek
>>>
>
>
>
Re: openejb as a osgi service?
Posted by Guillaume Nodet <gn...@gmail.com>.
I guess the first question is the goal of this OSGi integration. Is
the aim to be JEE compatible while the JEE container is deployed in
OSGi or is the goal to be OSGi friendly in the standalone mode (no JEE
container, so no full compatibility) ?
In the first case, we know what need to be done and just need to find
the best way to do it, while in the second case, we need to find the
best integration. Those might lead to different paths.
2009/11/12 Jay D. McHugh <ja...@jnwd.net>:
> Hello all,
>
> I have been thinking about what an EJB provider and container should
> look like in OSGi too. And here is what I have come up with (please
> respond with corrections, alternate opinions, and agreement where
> applicable).
>
> Provider issues:
> First, OpenEJB would need to provide a set of services that would allow
> for the scanning of a bundle to determine if there are EJBs in it. I
> believe Jacek has this or something like it done already.
>
> Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
> references to each of the interfaces provided by those EJBs -or- the
> provider would build and maintain a list of EJBs that are available for
> inclusion in a container.
>
> Container issues:
> From the container side we would need to figure out how an EJB container
> is deployed. Is a container a bundle in itself or could a container be
> created within a larger bundle (or both)?
>
> And then, how are those EJBs injected/looked up once they are available
> in a container. If the JNDI is build up when EJB bundles are started in
> the OSGi container - then how are the beans that are actually in the
> container differentiated from the 'prototype' JNDI entries? Or, are the
> JNDI entries only created when EJBs are included in a container?
>
> Lastly, what happens when an EJB is injected or looked up? Does a proxy
> get returned so that stopped bundles can be handled somewhat gracefully?
> It seems to me that this is what we would need to do. This would
> probably overlap with what they have done over in the Tuscany project
> though.
>
> I just remembered that there is an OSGi RFC (142 - which I have not
> finished reading yet) that deals with the JNDI and probably gives some
> direction on all of this.
>
> So, I've got to get reading - but if anyone has already read the spec,
> do you have any comments?
>
> I have not heard of any spec on how EJB containers should behave in an
> OSGi environment. Does anyone else have any thoughts (or access to a
> spec) on how they should?
>
>
> Jay
>
> Jacek Laskowski wrote:
>> Hi,
>>
>> I've lately been wondering about the other pieces for openejb
>> osgi'fication and am stuck. I'll need your help or I won't do any
>> further step as thinking has grabbed my free cycles completely.
>>
>> OSGi may seem as quite a different technology, but what it does with
>> our development perspective is to think about classloaders and
>> services. Everything in OSGi is just about classloaders/services and
>> its implication to the app.
>>
>> There're the openejb bundles, but they're nothing more than just a
>> collection of classes. If you run a osgi provider and staff it with
>> these bundles, they're started, but it doesn't mean openejb is started
>> itself. When a bundle is started, it just means that the
>> imports/exports are resolved and available. OpenEJB could not be
>> started yet. It's an activator (an instance of
>> org.osgi.framework.BundleActivator) that's responsible for doing
>> what's required to fully start the bundlized application (in our case
>> - openejb). A bundle gives its classes/interfaces via exports or
>> services. The exports are to let others compose their classloaders
>> with necessary classes provided by other bundles. So, once the bundles
>> are started, the activator kicks in and do the job of starting the
>> app. That's where I'm stack. I need to create necessary openejb
>> services (in OSGi terms). Can you point me to the simplest way to boot
>> openejb? The about-to-be-created OSGi service for OpenEJB is just like
>> LocalInitialContextFactory that boots openejb when a lookup is fired
>> and holds a reference to it - exactly what the future osgi service
>> will do.
>>
>> ...after a while...
>>
>> After a couple of minutes reading the email of mine over and over
>> again, I think I'll figure out what I was after. I just need to copy
>> what's in LocalInitialContextFactory! :) So, here goes another
>> question - how do I deploy an ejb? A test case would be of much help.
>> I need a way to get a reference to the just-deployed ejb, so I'll be
>> able to expose it as a osgi service. It should work, doesn't it?
>>
>> Jacek
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: openejb as a osgi service?
Posted by "Jay D. McHugh" <ja...@jnwd.net>.
Hello all,
I have been thinking about what an EJB provider and container should
look like in OSGi too. And here is what I have come up with (please
respond with corrections, alternate opinions, and agreement where
applicable).
Provider issues:
First, OpenEJB would need to provide a set of services that would allow
for the scanning of a bundle to determine if there are EJBs in it. I
believe Jacek has this or something like it done already.
Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
references to each of the interfaces provided by those EJBs -or- the
provider would build and maintain a list of EJBs that are available for
inclusion in a container.
Container issues:
>From the container side we would need to figure out how an EJB container
is deployed. Is a container a bundle in itself or could a container be
created within a larger bundle (or both)?
And then, how are those EJBs injected/looked up once they are available
in a container. If the JNDI is build up when EJB bundles are started in
the OSGi container - then how are the beans that are actually in the
container differentiated from the 'prototype' JNDI entries? Or, are the
JNDI entries only created when EJBs are included in a container?
Lastly, what happens when an EJB is injected or looked up? Does a proxy
get returned so that stopped bundles can be handled somewhat gracefully?
It seems to me that this is what we would need to do. This would
probably overlap with what they have done over in the Tuscany project
though.
I just remembered that there is an OSGi RFC (142 - which I have not
finished reading yet) that deals with the JNDI and probably gives some
direction on all of this.
So, I've got to get reading - but if anyone has already read the spec,
do you have any comments?
I have not heard of any spec on how EJB containers should behave in an
OSGi environment. Does anyone else have any thoughts (or access to a
spec) on how they should?
Jay
Jacek Laskowski wrote:
> Hi,
>
> I've lately been wondering about the other pieces for openejb
> osgi'fication and am stuck. I'll need your help or I won't do any
> further step as thinking has grabbed my free cycles completely.
>
> OSGi may seem as quite a different technology, but what it does with
> our development perspective is to think about classloaders and
> services. Everything in OSGi is just about classloaders/services and
> its implication to the app.
>
> There're the openejb bundles, but they're nothing more than just a
> collection of classes. If you run a osgi provider and staff it with
> these bundles, they're started, but it doesn't mean openejb is started
> itself. When a bundle is started, it just means that the
> imports/exports are resolved and available. OpenEJB could not be
> started yet. It's an activator (an instance of
> org.osgi.framework.BundleActivator) that's responsible for doing
> what's required to fully start the bundlized application (in our case
> - openejb). A bundle gives its classes/interfaces via exports or
> services. The exports are to let others compose their classloaders
> with necessary classes provided by other bundles. So, once the bundles
> are started, the activator kicks in and do the job of starting the
> app. That's where I'm stack. I need to create necessary openejb
> services (in OSGi terms). Can you point me to the simplest way to boot
> openejb? The about-to-be-created OSGi service for OpenEJB is just like
> LocalInitialContextFactory that boots openejb when a lookup is fired
> and holds a reference to it - exactly what the future osgi service
> will do.
>
> ...after a while...
>
> After a couple of minutes reading the email of mine over and over
> again, I think I'll figure out what I was after. I just need to copy
> what's in LocalInitialContextFactory! :) So, here goes another
> question - how do I deploy an ejb? A test case would be of much help.
> I need a way to get a reference to the just-deployed ejb, so I'll be
> able to expose it as a osgi service. It should work, doesn't it?
>
> Jacek
>