Jim,
EJB/OSGi services are singletons as far as OSGi service model goes, but
since OSGi allows concurrent access to the singleton service, an
EJB/OSGi service also benefits from pooling done by the ejb container.
Does this answer your question?
You can't deploy ear files containing OSGi bundles, but you can deploy
OSGi bundles either using admin console (there should be a check box to
select osgi type archive) or using asadmin command like this:
asadmin deploy --type osgi <your bundle>
If you are embedding GlassFish in an OSGi runtime and have access to
OSGi runtime, you could also deploy your bundle directly to the OSGi
runtime using BundleContext.install() followed by Bundle.start() to get
the same effect.
If you deploy your ejb+jpa as vanilla ejb-jar, then the ejbs contained
in such app are never published as services. For them to be published as
services, you have to add Export-EJB header in you ejb-jar in addition
to adding necessary OSGi metadata and deploy the ejb-jar as an OSGi bundle.
Thanks,
Sahoo
On Tuesday 14 February 2012 04:03 AM, jlgreene2_at_aep.com wrote:
> I've been doing some testing using Glassfish embedded in an
> alternative OSGi container/runtime (in my case, Apache Karaf running
> Felix). I've been successful in writing OSGi services/components that
> make use of Java EE resources in Glassfish such as JDBC Connection
> pools and JMS Connection factories, as per the examples that have been
> posted on the web.
>
> I'm at a place in my testing where I am trying to evaluate the merits
> of exposing an EJB as an OSGi service. All of the examples I have
> seen depict writing EJB's and deploying them as an OSGi bundle. I am
> assuming when you do this, the EJB/OSGi service is a singleton. Is
> this a correct assessment? Is this the only way to expose an EJB as
> an OSGi service?
>
> I am curious about whether it is possible to deploy an EJB JAR (or an
> EAR containing the EJB JAR) directly into Glassfish (via the server
> console, or asadmin), and have the EJB's contained therein register
> themselves as OSGi services? What I'm thinking about is taking code
> that I would not normally deploy in an app server because it would
> violate the EJB specification (like reading data from a file), and
> deploy it as an OSGI service, and then take advantage of EJB/JPA code
> I've already written (for example, a persistence layer for an
> application implemented using Stateless Session Beans and JPA
> Entities) to perform transactional updates to an underlying datastore.
> Thus, all I would need to install into the OSGi container would be a
> bundle containing the interfaces for the Session Beans, instead of the
> Session Beans themselves.
>
> Am I barking up the wrong tree here?
>
> Regards,
> Jim