You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Larry Touve <lt...@potomacfusion.com> on 2010/03/04 15:39:46 UTC

Glassfish OSGI and Felix

Hello,

  I've been rapidly learning the ins & outs of OSGi and was wondering if any others were in similar situations as we are.  We are re-architecting an existing web based system using an OSGI based framework.  We currently create an ear file that is deployed to a JBoss server.  We are moving an architecture where we deploy bundles to an OSGi framework.

I have an existing Felix 2.0.1 installation and have tried (unsuccessfully) to deploy Glassfish V3 using Sahoo's embeddedgf activator<http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime>.  It installs all of the bundles and seems to start some of them, but there seems to be some unresolved dependencies, and the domain doesn't start up.  Has anyone tried this with any success?

My next approach was to simply start up Glassfish, then use the Felix framework that Glassfish starts up.  I have dropped the Felix Web Console bundles in the autodeploy directory and everything starts up fine - I can access the domain root page, the GF Admin console, and the Felix Web Console.  I was curious to see what other's opinions were as to this scenario in a production environment (starting up GF and using its Felix, as opposed to starting up Felix, then deploying GF to it).

We are looking at Glassfish vs. something lightweight like Jetty or Tomcat for a couple of reasons: we will be using JMS and JDBC datasources, and more importantly Glassfish V3 has been approved and accredited for the system we will be deploying to.

Thanks,
 Larry


RE: Glassfish OSGI and Felix

Posted by Larry Touve <lt...@potomacfusion.com>.
> -----Original Message-----
> From: Sanjeeb.Sahoo@Sun.COM [mailto:Sanjeeb.Sahoo@Sun.COM] On Behalf Of
>
> I am also confused as to see the bundle version. It is 3.0.0.b74b, which
> matches with that of GlassFish 3.0 FCS release. You should be trying out
> latest trunk builds (those 3.1-SNAPSHOT builds) to get the embeddedgf to
> work. 

I'm downloading the latest (glassfish-v3_1-b01-02_27_2010.zip) and will compare the behavior.

> I have one question for you. Do you have a need to embed glassfish in an
> OSGi runtime at this point of time?

I'm not quite sure.  Our current requirement is to go to an OSGi architecture.  At this early stage
in our design, I'm just trying to investigate all options to weigh the benefits.  Having Glassfish
start everything up certainly makes things easy, as long as we can manage our bundles either through
Glassfish, or independently (using Felix Web Console, for example).

Unfortunately, my only OSGi exposure has been reading Craig Walls' book (Modular Java) and messing
around with some examples, so I'm a little behind the curve.

> Thanks,
> Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Sahoo <Sa...@Sun.COM>.
Larry Touve wrote:
> On 3/4/10 12:33 PM, Sahoo wrote:
>   
>>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>>       
>>>> Good point. I will try on Felix trunk and see what happens...
>>>>         
>>> On trunk, I see a bunch of bundles get deployed, some get resolved, 
>>> but the only active bundle is:
>>>
>>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping Classes 
>>> (3.0)
>>>
>>> There were no errors and the framework appears to be running fine as 
>>> far as I can tell.
>>>
>>>       
>
> After installing Felix 2.0.4, copying the config.properties file from the Glassfish's Felix directory to my 2.0.4 install directory, and editing it slightly (comment out the autostart line for Glassfish) it looks like things are OK.  I'm not sure if Felix 2.0.4 made a difference, or if I just mucked something up before.
>
> I also modified the embeddedgf code to point to my GF install, then built and installed it.  Of all the installed bundles, only the following are Active:
>
> Appserver Core Bootstraping Classes (org.glassfish.core.glassfish)
> OSGi GlassFish Embedder             (sahoo.embeddedgf)
>   
This list does not look complete to me. I expected to see bundles like 
com.sun.enterprise.osgi-adapter in ACTIVE state given that you have 
mentioned you could access default welcome page and all. You might have 
looked at the bundle state while glassfish was still starting.
> I am able to hit the default welcome page, and log in to the GF admin console.  When I start up glassfish using asadmin I noticed that there are 40+ active bundles, and some of the bundles that have missing dependencies when I start up using embeddedgf (see below) are active when started up via glassfish.  I'm not quite sure what this means yet, as I haven't deployed anything to glassfish yet, nor have I deployed any other bundles.
>   
This probably has to do with system package export list.
>  I saw the following exceptions in the log, although they don't seem to be critical:
>   
> -> org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.felix.configadmin:1.2.4
>   
You are right. All those exceptions of type 
"org.osgi.framework.BundleException: Bundle symbolic name and version 
are not unique" are not critical, as they are appearing because 
GlassFish distributes Felix shell, configadmin bundles and in your case, 
they were already installed from bundle/ directory of Felix.
> As for the missing dependencies, this is an example of what I see when I click on a bundle that is not Active in the Felix Web Console (not all have unresolved issues, just some):
>   
Don't worry about all bundles not being ACTIVE or RESOLVED. GlassFish 
lazily activates bundles. Unresolved constraints need attention. I am 
not sure why this bundle is not able to get all its imports wired. All 
those required packages are exported by glassfish modules. Try starting 
the following bundle and see if there are unresolved constraints.

I am also confused as to see the bundle version. It is 3.0.0.b74b, which 
matches with that of GlassFish 3.0 FCS release. You should be trying out 
latest trunk builds (those 3.1-SNAPSHOT builds) to get the embeddedgf to 
work.

I have one question for you. Do you have a need to embed glassfish in an 
OSGi runtime at this point of time?

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


RE: Glassfish OSGI and Felix

Posted by Larry Touve <lt...@potomacfusion.com>.
On 3/4/10 12:33 PM, Sahoo wrote:
>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>> Good point. I will try on Felix trunk and see what happens...
>>
>> On trunk, I see a bunch of bundles get deployed, some get resolved, 
>> but the only active bundle is:
>>
>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping Classes 
>> (3.0)
>>
>> There were no errors and the framework appears to be running fine as 
>> far as I can tell.
>>

After installing Felix 2.0.4, copying the config.properties file from the Glassfish's Felix directory to my 2.0.4 install directory, and editing it slightly (comment out the autostart line for Glassfish) it looks like things are OK.  I'm not sure if Felix 2.0.4 made a difference, or if I just mucked something up before.

I also modified the embeddedgf code to point to my GF install, then built and installed it.  Of all the installed bundles, only the following are Active:

Appserver Core Bootstraping Classes (org.glassfish.core.glassfish)
OSGi GlassFish Embedder             (sahoo.embeddedgf)

I am able to hit the default welcome page, and log in to the GF admin console.  When I start up glassfish using asadmin I noticed that there are 40+ active bundles, and some of the bundles that have missing dependencies when I start up using embeddedgf (see below) are active when started up via glassfish.  I'm not quite sure what this means yet, as I haven't deployed anything to glassfish yet, nor have I deployed any other bundles.

 I saw the following exceptions in the log, although they don't seem to be critical:

-> org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.felix.configadmin:1.2.4
        at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1151)
        at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:79)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2425)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2330)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:108)
        at sahoo.embeddedgf.GFActivator.installBundles(GFActivator.java:102)
        at sahoo.embeddedgf.GFActivator.start(GFActivator.java:84)
        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661)
        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1756)
        at org.apache.felix.framework.Felix.startBundle(Felix.java:1678)
        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
        at org.apache.felix.webconsole.internal.core.InstallHelper.doRun(InstallHelper.java:65)
        at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:79)
        at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:112)
org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.felix.org.apache.felix.shell.remote:1.0.4
        at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1151)
        at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:79)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2425)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2330)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:108)
        at sahoo.embeddedgf.GFActivator.installBundles(GFActivator.java:102)
        at sahoo.embeddedgf.GFActivator.start(GFActivator.java:84)
        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661)
        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1756)
        at org.apache.felix.framework.Felix.startBundle(Felix.java:1678)
        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
        at org.apache.felix.webconsole.internal.core.InstallHelper.doRun(InstallHelper.java:65)
        at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:79)
        at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:112)
org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.felix.shell.tui:1.4.1
        at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1151)
        at org.apache.felix.framework.BundleImpl.<init>(BundleImpl.java:79)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2425)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2330)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:108)
        at sahoo.embeddedgf.GFActivator.installBundles(GFActivator.java:102)
        at sahoo.embeddedgf.GFActivator.start(GFActivator.java:84)
        at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661)
        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1756)
        at org.apache.felix.framework.Felix.startBundle(Felix.java:1678)
        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)
        at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)
        at org.apache.felix.webconsole.internal.core.InstallHelper.doRun(InstallHelper.java:65)
        at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.doRun(BaseUpdateInstallHelper.java:79)
        at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.run(BaseUpdateInstallHelper.java:112)

As for the missing dependencies, this is an example of what I see when I click on a bundle that is not Active in the Felix Web Console (not all have unresolved issues, just some):

Security Core Classes:
Symbolic Name		org.glassfish.security
Version	      	3.0.0.b74b
Bundle Location		file:/C:/DevTools/glassfishv3/glassfish/modules/security.jar
Last Modification		Thu Mar 04 14:01:20 EST 2010
Bundle Documentation	https://glassfish.dev.java.net
Vendor			GlassFish Community
Start Level			1
Exported Packages		com.iplanet.ias.security.auth.login,version=3.0.0
  :
Imported Packages	!! com.sun.appserv.connectors.internal.api,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.config.serverbeans,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.deployment,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.deployment.interfaces,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.deployment.runtime.common,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.deployment.runtime.web,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.deployment.util,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.deployment.web,version=3.0.0 -- Cannot be resolved
com.sun.enterprise.module,version=1.0.0 from com.sun.enterprise.hk2-core (137)
!! com.sun.enterprise.security.integration,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.security.store,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.universal,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.util,version=3.0.0 -- Cannot be resolved
!! com.sun.enterprise.util.i18n,version=3.0.0 -- Cannot be resolved
!! com.sun.jndi.ldap.obj,version=0.0.0 -- Cannot be resolved
com.sun.security.auth,version=0.0.0 from org.apache.felix.framework (0)
javax.crypto,version=0.0.0 from org.apache.felix.framework (0)
!! javax.ejb,version=3.1.0 -- Cannot be resolved
javax.management,version=0.0.0 from org.apache.felix.framework (0)
!! javax.naming,version=0.0.0 from org.apache.felix.framework (0) -- Overwritten by Boot Delegation
!! javax.naming.directory,version=0.0.0 from org.apache.felix.framework (0) -- Overwritten by Boot Delegation
javax.net,version=0.0.0 from org.apache.felix.framework (0)
javax.net.ssl,version=0.0.0 from org.apache.felix.framework (0)
javax.rmi,version=0.0.0 from org.apache.felix.framework (0)
javax.rmi.CORBA,version=0.0.0 from org.apache.felix.framework (0)
javax.security.auth,version=0.0.0 from org.apache.felix.framework (0)
javax.security.auth.callback,version=0.0.0 from org.apache.felix.framework (0)
javax.security.auth.kerberos,version=0.0.0 from org.apache.felix.framework (0)
javax.security.auth.login,version=0.0.0 from org.apache.felix.framework (0)
!! javax.security.auth.message,version=1.0.0 -- Cannot be resolved
!! javax.security.auth.message.callback,version=1.0.0 -- Cannot be resolved
!! javax.security.auth.message.config,version=1.0.0 -- Cannot be resolved
!! javax.security.auth.message.module,version=1.0.0 -- Cannot be resolved
javax.security.auth.spi,version=0.0.0 from org.apache.felix.framework (0)
javax.security.auth.x500,version=0.0.0 from org.apache.felix.framework (0)
!! javax.security.jacc,version=1.4.0 -- Cannot be resolved
!! javax.servlet,version=3.0.0 -- Cannot be resolved
!! javax.servlet.http,version=3.0.0 -- Cannot be resolved
!! javax.sql,version=0.0.0 from org.apache.felix.framework (0) -- Overwritten by Boot Delegation
javax.swing,version=0.0.0 from org.apache.felix.framework (0)
org.glassfish.api,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.admin,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.container,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.deployment,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.deployment.archive,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.embedded,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.event,version=3.0.0 from org.glassfish.common.glassfish-api (109)
org.glassfish.api.invocation,version=3.0.0 from org.glassfish.common.glassfish-api (109)
!! org.glassfish.deployment.common,version=3.0.0 -- Cannot be resolved
!! org.glassfish.ejb.api,version=3.0.0 -- Cannot be resolved
org.glassfish.external.probe.provider,version=0.0.0 from management-api (182)
org.glassfish.external.probe.provider.annotations,version=0.0.0 from management-api (182)
org.glassfish.external.statistics,version=0.0.0 from management-api (182)
org.glassfish.external.statistics.impl,version=0.0.0 from management-api (182)
!! org.glassfish.gmbal,version=0.0.0 -- Cannot be resolved
!! org.glassfish.internal.api,version=3.0.0 -- Cannot be resolved
!! org.glassfish.internal.data,version=3.0.0 -- Cannot be resolved
!! org.glassfish.internal.deployment,version=3.0.0 -- Cannot be resolved
!! org.glassfish.security.common,version=3.0.0 -- Cannot be resolved
org.jvnet.hk2.annotations,version=1.0.0 from com.sun.enterprise.auto-depends (34)
org.jvnet.hk2.component,version=1.0.0 from com.sun.enterprise.auto-depends (34)
org.jvnet.hk2.config,version=1.0.0 from com.sun.enterprise.config (53)
!! org.jvnet.hk2.config.types,version=1.0.0 -- Cannot be resolved
!! org.omg.CORBA,version=0.0.0 from glassfish-corba-omgapi (114) -- Overwritten by Boot Delegation
sun.net.www,version=0.0.0 from org.apache.felix.framework (0)
sun.security.provider,version=0.0.0 from org.apache.felix.framework (0)
sun.security.tools,version=0.0.0 from org.apache.felix.framework (0)
sun.security.util,version=0.0.0 from org.apache.felix.framework (0)
sun.security.x509,version=0.0.0 from org.apache.felix.framework (0)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Sahoo <Sa...@Sun.COM>.
Richard S. Hall wrote:
> On 3/4/10 1:47 PM, Richard S. Hall wrote:
>> On 3/4/10 1:24 PM, Sahoo wrote:
>>> Richard S. Hall wrote:
>>>> On 3/4/10 12:33 PM, Sahoo wrote:
>>>>> Richard S. Hall wrote:
>>>>>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>>>>>> Good point. I will try on Felix trunk and see what happens...
>>>>>>
>>>>>> On trunk, I see a bunch of bundles get deployed, some get 
>>>>>> resolved, but the only active bundle is:
>>>>>>
>>>>>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping 
>>>>>> Classes (3.0)
>>>>>>
>>>>>> There were no errors and the framework appears to be running fine 
>>>>>> as far as I can tell.
>>>>>>
>>>>> What did you try to do?
>>>>
>>>> I modified the embeddedgf bundle to point to my GF installation, 
>>>> built it, deployed it, and started it. I was under the impression 
>>>> that this would start the GF server.
>>>>
>>> That should have worked. Do you see any error related to activation 
>>> of configadmin bundle? "Appserver Core Bootstraping Classes" bundle 
>>> would have tried to start org.apache.felix.configadmin bundle. Are 
>>> you not on recent trunk build gf? If not, please use a recent build 
>>> of glassfish.
>>
>> I was using the v3 release, I believe. Must I use a trunk build?
>
Yes, for embeddedgf to work as outlined in that blog, one needs to use a 
more recent build from trunk.
> Ok, I built GF trunk and tried it on both Felix framework 2.0.4 and 
> trunk. It didn't quite work in either case, but the behavior looks the 
> same in either case:
>
> The server does start to some degreee since I am able to see the admin 
> console "loading" page, but the admin console never finishes loading. 
> I am seeing CNFEs for javax.transactions.TransactionManager.
>
> My guess is that we need to configure some framework properties to get 
> it to work, but I am not sure.
GlassFish configures a few things in config.properties:
1. The system packages needs to be correctly set. Felix by default 
exports javax.transaction package by system bundle with 
version=${jre.version}, but jre has only a couple of exception classes 
from that package. Sometimes jre.version is actually higher than the 
actual versions of those packages - I know OSGi version of Java SE and 
EE packages is hot topic right now. So, GlassFish configures that 
package the following way:
 javax.transaction; javax.transaction.xa;partial=true; mandatory:=partial, \

It also adds javax.transaction, javax.transaction.* to bootdelegation 
list to avoid loader constraint violation, as javax.sql package, part of 
JRE, references classes from javax.transaction package.

 From the description of your problem, it may be related to the above 
configuration.

2. We also set
org.osgi.framework.bundle.parent=framework so that JDK's tools.jar and 
jars from jre.ext.dirs are available to bundles.

If you look at config.properties that's distributed by GlassFish, it 
contains comments explaining these changes.

Thanks,
Sahoo
>
> -> richard
>
>>
>> -> richard
>>
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/4/10 1:47 PM, Richard S. Hall wrote:
> On 3/4/10 1:24 PM, Sahoo wrote:
>> Richard S. Hall wrote:
>>> On 3/4/10 12:33 PM, Sahoo wrote:
>>>> Richard S. Hall wrote:
>>>>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>>>>> Good point. I will try on Felix trunk and see what happens...
>>>>>
>>>>> On trunk, I see a bunch of bundles get deployed, some get 
>>>>> resolved, but the only active bundle is:
>>>>>
>>>>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping 
>>>>> Classes (3.0)
>>>>>
>>>>> There were no errors and the framework appears to be running fine 
>>>>> as far as I can tell.
>>>>>
>>>> What did you try to do?
>>>
>>> I modified the embeddedgf bundle to point to my GF installation, 
>>> built it, deployed it, and started it. I was under the impression 
>>> that this would start the GF server.
>>>
>> That should have worked. Do you see any error related to activation 
>> of configadmin bundle? "Appserver Core Bootstraping Classes" bundle 
>> would have tried to start org.apache.felix.configadmin bundle. Are 
>> you not on recent trunk build gf? If not, please use a recent build 
>> of glassfish.
>
> I was using the v3 release, I believe. Must I use a trunk build?

Ok, I built GF trunk and tried it on both Felix framework 2.0.4 and 
trunk. It didn't quite work in either case, but the behavior looks the 
same in either case:

The server does start to some degreee since I am able to see the admin 
console "loading" page, but the admin console never finishes loading. I 
am seeing CNFEs for javax.transactions.TransactionManager.

My guess is that we need to configure some framework properties to get 
it to work, but I am not sure.

-> richard

>
> -> richard
>
>>
>> Thanks,
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/4/10 1:24 PM, Sahoo wrote:
> Richard S. Hall wrote:
>> On 3/4/10 12:33 PM, Sahoo wrote:
>>> Richard S. Hall wrote:
>>>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>>>> Good point. I will try on Felix trunk and see what happens...
>>>>
>>>> On trunk, I see a bunch of bundles get deployed, some get resolved, 
>>>> but the only active bundle is:
>>>>
>>>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping 
>>>> Classes (3.0)
>>>>
>>>> There were no errors and the framework appears to be running fine 
>>>> as far as I can tell.
>>>>
>>> What did you try to do?
>>
>> I modified the embeddedgf bundle to point to my GF installation, 
>> built it, deployed it, and started it. I was under the impression 
>> that this would start the GF server.
>>
> That should have worked. Do you see any error related to activation of 
> configadmin bundle? "Appserver Core Bootstraping Classes" bundle would 
> have tried to start org.apache.felix.configadmin bundle. Are you not 
> on recent trunk build gf? If not, please use a recent build of glassfish.

I was using the v3 release, I believe. Must I use a trunk build?

-> richard

>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Sahoo <Sa...@Sun.COM>.
Richard S. Hall wrote:
> On 3/4/10 12:33 PM, Sahoo wrote:
>> Richard S. Hall wrote:
>>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>>> Good point. I will try on Felix trunk and see what happens...
>>>
>>> On trunk, I see a bunch of bundles get deployed, some get resolved, 
>>> but the only active bundle is:
>>>
>>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping Classes 
>>> (3.0)
>>>
>>> There were no errors and the framework appears to be running fine as 
>>> far as I can tell.
>>>
>> What did you try to do?
>
> I modified the embeddedgf bundle to point to my GF installation, built 
> it, deployed it, and started it. I was under the impression that this 
> would start the GF server.
>
That should have worked. Do you see any error related to activation of 
configadmin bundle? "Appserver Core Bootstraping Classes" bundle would 
have tried to start org.apache.felix.configadmin bundle. Are you not on 
recent trunk build gf? If not, please use a recent build of glassfish.

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/4/10 12:33 PM, Sahoo wrote:
> Richard S. Hall wrote:
>> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>>> Good point. I will try on Felix trunk and see what happens...
>>
>> On trunk, I see a bunch of bundles get deployed, some get resolved, 
>> but the only active bundle is:
>>
>>     [ 113] [Active     ] [    1] Appserver Core Bootstraping Classes 
>> (3.0)
>>
>> There were no errors and the framework appears to be running fine as 
>> far as I can tell.
>>
> What did you try to do?

I modified the embeddedgf bundle to point to my GF installation, built 
it, deployed it, and started it. I was under the impression that this 
would start the GF server.

-> richard

>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Sahoo <Sa...@Sun.COM>.

Richard S. Hall wrote:
> On 3/4/10 11:09 AM, Richard S. Hall wrote:
>> Good point. I will try on Felix trunk and see what happens...
>
> On trunk, I see a bunch of bundles get deployed, some get resolved, 
> but the only active bundle is:
>
>     [ 113] [Active     ] [    1] Appserver Core Bootstraping Classes 
> (3.0)
>
> There were no errors and the framework appears to be running fine as 
> far as I can tell.
>
What did you try to do?

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/4/10 11:09 AM, Richard S. Hall wrote:
> Good point. I will try on Felix trunk and see what happens...

On trunk, I see a bunch of bundles get deployed, some get resolved, but 
the only active bundle is:

     [ 113] [Active     ] [    1] Appserver Core Bootstraping Classes (3.0)

There were no errors and the framework appears to be running fine as far 
as I can tell.

-> richard
>
> -> richard
>
> On 3/4/10 10:55 AM, Sahoo wrote:
>> Hi Larry,
>>
>> embeddedgf approach should be followed if you have a need to embed 
>> glassfish in an existing OSGi runtime so that you don't end up with 
>> two OSGi runtimes. As already answered, if you don't have such a 
>> requirement, then better to stick to the standard glassfish start up 
>> sequence, i.e., start glassfish launcher and let it start Felix for 
>> you. That's what has been tested by GlassFish team more than any 
>> other startup sequence.
>>
>> Having said that, embeddedgf approach should also work. I don't know 
>> what is making you to conclude about missing dependencies when you 
>> follow the instructions in that blog to embed glassfish in felix. I 
>> have a feeling Felix is probably taking longer to ensure a consistent 
>> class space because of some resolver limitations in Felix. To work 
>> around this resolver limitation, GlassFish uses a slightly different 
>> system package export list (e.g., JAXB and JAX-WS packages are not 
>> exported by system bundle). You can try out by using 
>> config.properties distributed by glassfish (found in 
>> glassfish/osgi/felix/conf/config.properties). I have tried this 
>> successfully. I know Felix dev team, Richard in particular, are 
>> working very hard to improve this aspect of Felix resolver and they 
>> have already made significant progress. If you used latest trunk, you 
>> might not even face this problem.
>>
>> Thanks,
>> Sahoo
>>
>> Larry Touve wrote:
>>> Hello,
>>>
>>>   I've been rapidly learning the ins & outs of OSGi and was 
>>> wondering if any others were in similar situations as we are.  We 
>>> are re-architecting an existing web based system using an OSGI based 
>>> framework.  We currently create an ear file that is deployed to a 
>>> JBoss server.  We are moving an architecture where we deploy bundles 
>>> to an OSGi framework.
>>>
>>> I have an existing Felix 2.0.1 installation and have tried 
>>> (unsuccessfully) to deploy Glassfish V3 using Sahoo's embeddedgf 
>>> activator<http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime>.  
>>> It installs all of the bundles and seems to start some of them, but 
>>> there seems to be some unresolved dependencies, and the domain 
>>> doesn't start up.  Has anyone tried this with any success?
>>>
>>> My next approach was to simply start up Glassfish, then use the 
>>> Felix framework that Glassfish starts up.  I have dropped the Felix 
>>> Web Console bundles in the autodeploy directory and everything 
>>> starts up fine - I can access the domain root page, the GF Admin 
>>> console, and the Felix Web Console.  I was curious to see what 
>>> other's opinions were as to this scenario in a production 
>>> environment (starting up GF and using its Felix, as opposed to 
>>> starting up Felix, then deploying GF to it).
>>>
>>> We are looking at Glassfish vs. something lightweight like Jetty or 
>>> Tomcat for a couple of reasons: we will be using JMS and JDBC 
>>> datasources, and more importantly Glassfish V3 has been approved and 
>>> accredited for the system we will be deploying to.
>>>
>>> Thanks,
>>>  Larry
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Good point. I will try on Felix trunk and see what happens...

-> richard

On 3/4/10 10:55 AM, Sahoo wrote:
> Hi Larry,
>
> embeddedgf approach should be followed if you have a need to embed 
> glassfish in an existing OSGi runtime so that you don't end up with 
> two OSGi runtimes. As already answered, if you don't have such a 
> requirement, then better to stick to the standard glassfish start up 
> sequence, i.e., start glassfish launcher and let it start Felix for 
> you. That's what has been tested by GlassFish team more than any other 
> startup sequence.
>
> Having said that, embeddedgf approach should also work. I don't know 
> what is making you to conclude about missing dependencies when you 
> follow the instructions in that blog to embed glassfish in felix. I 
> have a feeling Felix is probably taking longer to ensure a consistent 
> class space because of some resolver limitations in Felix. To work 
> around this resolver limitation, GlassFish uses a slightly different 
> system package export list (e.g., JAXB and JAX-WS packages are not 
> exported by system bundle). You can try out by using config.properties 
> distributed by glassfish (found in 
> glassfish/osgi/felix/conf/config.properties). I have tried this 
> successfully. I know Felix dev team, Richard in particular, are 
> working very hard to improve this aspect of Felix resolver and they 
> have already made significant progress. If you used latest trunk, you 
> might not even face this problem.
>
> Thanks,
> Sahoo
>
> Larry Touve wrote:
>> Hello,
>>
>>   I've been rapidly learning the ins & outs of OSGi and was wondering 
>> if any others were in similar situations as we are.  We are 
>> re-architecting an existing web based system using an OSGI based 
>> framework.  We currently create an ear file that is deployed to a 
>> JBoss server.  We are moving an architecture where we deploy bundles 
>> to an OSGi framework.
>>
>> I have an existing Felix 2.0.1 installation and have tried 
>> (unsuccessfully) to deploy Glassfish V3 using Sahoo's embeddedgf 
>> activator<http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime>.  
>> It installs all of the bundles and seems to start some of them, but 
>> there seems to be some unresolved dependencies, and the domain 
>> doesn't start up.  Has anyone tried this with any success?
>>
>> My next approach was to simply start up Glassfish, then use the Felix 
>> framework that Glassfish starts up.  I have dropped the Felix Web 
>> Console bundles in the autodeploy directory and everything starts up 
>> fine - I can access the domain root page, the GF Admin console, and 
>> the Felix Web Console.  I was curious to see what other's opinions 
>> were as to this scenario in a production environment (starting up GF 
>> and using its Felix, as opposed to starting up Felix, then deploying 
>> GF to it).
>>
>> We are looking at Glassfish vs. something lightweight like Jetty or 
>> Tomcat for a couple of reasons: we will be using JMS and JDBC 
>> datasources, and more importantly Glassfish V3 has been approved and 
>> accredited for the system we will be deploying to.
>>
>> Thanks,
>>  Larry
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Sahoo <Sa...@Sun.COM>.
Hi Larry,

Larry Touve wrote:
> Thanks to all who have been responding.
>
>   
>> Having said that, embeddedgf approach should also work. I don't know 
>> what is making you to conclude about missing dependencies when you 
>> follow the instructions in that blog to embed glassfish in felix. 
>>     
>
> When I 'start' the bundle, it installs the 218 (or so) Glassfish bundles.  They are all in various
> States - some active, some resolved, and some installed.  At this point I was unable 
> to access either the root welcome page (localhost:8080) or the admin console 
> (localhost:4848), as well as 'asadmin list-domains' showed that domain1 was not 
> running.  When I looked at some of the bundles that were either in the resolved 
> or installed state some listed errors in resolving dependencies.  I was using 
> the Felix Web Console to examine the bundles.  At this point, I wasn't sure which
> bundles should have been active/resolved/installed, so I focused on getting the
> Felix Web Console running in the Glassfish-launched Felix (which turned out to be
> Pretty easy).  Running this way showed that the bundles are all in various states 
> (not all are active), so I stopped Investigating the embeddedgf path.
>
>   
GlassFish does not activate all bundles. To start with, most bundles 
remain in INSTALLED state. They move to RESOLVED state as and when they 
participate in class loading - this is taken care by OSGi framework. 
GlassFish has a notion of lazy loading of services. As and when services 
are needed from bundles, glassfish activates necessary bundles.

In future, when you encounter such problem, run jstack to find more 
about the state of the process.

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


RE: Glassfish OSGI and Felix

Posted by Larry Touve <lt...@potomacfusion.com>.
Thanks to all who have been responding.

>Having said that, embeddedgf approach should also work. I don't know 
>what is making you to conclude about missing dependencies when you 
>follow the instructions in that blog to embed glassfish in felix. 

When I 'start' the bundle, it installs the 218 (or so) Glassfish bundles.  They are all in various
States - some active, some resolved, and some installed.  At this point I was unable 
to access either the root welcome page (localhost:8080) or the admin console 
(localhost:4848), as well as 'asadmin list-domains' showed that domain1 was not 
running.  When I looked at some of the bundles that were either in the resolved 
or installed state some listed errors in resolving dependencies.  I was using 
the Felix Web Console to examine the bundles.  At this point, I wasn't sure which
bundles should have been active/resolved/installed, so I focused on getting the
Felix Web Console running in the Glassfish-launched Felix (which turned out to be
Pretty easy).  Running this way showed that the bundles are all in various states 
(not all are active), so I stopped Investigating the embeddedgf path.

>I have a feeling Felix is probably taking longer to ensure a consistent class 
>space because of some resolver limitations in Felix. To work around this 
>resolver limitation, Glassfish uses a slightly different system package 
>export list (e.g., JAXB and JAX-WS packages are not exported by system 
>bundle). You can try out by using config.properties distributed by 
>glassfish (found in glassfish/osgi/felix/conf/config.properties). I have 
>tried this successfully. I know Felix dev team, Richard in particular, 
>are working very hard to improve this aspect of Felix resolver and they 
>have already made significant progress. If you used latest trunk, you 
>might not even face this problem.

I had started with Felix 2.0.1, but I just grabbed 2.0.4 and will try again to see how it goes.
I'll post the results when I get a chance.

Thanks,
Larry


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Sahoo <Sa...@Sun.COM>.
Hi Larry,

embeddedgf approach should be followed if you have a need to embed 
glassfish in an existing OSGi runtime so that you don't end up with two 
OSGi runtimes. As already answered, if you don't have such a 
requirement, then better to stick to the standard glassfish start up 
sequence, i.e., start glassfish launcher and let it start Felix for you. 
That's what has been tested by GlassFish team more than any other 
startup sequence.

Having said that, embeddedgf approach should also work. I don't know 
what is making you to conclude about missing dependencies when you 
follow the instructions in that blog to embed glassfish in felix. I have 
a feeling Felix is probably taking longer to ensure a consistent class 
space because of some resolver limitations in Felix. To work around this 
resolver limitation, GlassFish uses a slightly different system package 
export list (e.g., JAXB and JAX-WS packages are not exported by system 
bundle). You can try out by using config.properties distributed by 
glassfish (found in glassfish/osgi/felix/conf/config.properties). I have 
tried this successfully. I know Felix dev team, Richard in particular, 
are working very hard to improve this aspect of Felix resolver and they 
have already made significant progress. If you used latest trunk, you 
might not even face this problem.

Thanks,
Sahoo

Larry Touve wrote:
> Hello,
>
>   I've been rapidly learning the ins & outs of OSGi and was wondering if any others were in similar situations as we are.  We are re-architecting an existing web based system using an OSGI based framework.  We currently create an ear file that is deployed to a JBoss server.  We are moving an architecture where we deploy bundles to an OSGi framework.
>
> I have an existing Felix 2.0.1 installation and have tried (unsuccessfully) to deploy Glassfish V3 using Sahoo's embeddedgf activator<http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime>.  It installs all of the bundles and seems to start some of them, but there seems to be some unresolved dependencies, and the domain doesn't start up.  Has anyone tried this with any success?
>
> My next approach was to simply start up Glassfish, then use the Felix framework that Glassfish starts up.  I have dropped the Felix Web Console bundles in the autodeploy directory and everything starts up fine - I can access the domain root page, the GF Admin console, and the Felix Web Console.  I was curious to see what other's opinions were as to this scenario in a production environment (starting up GF and using its Felix, as opposed to starting up Felix, then deploying GF to it).
>
> We are looking at Glassfish vs. something lightweight like Jetty or Tomcat for a couple of reasons: we will be using JMS and JDBC datasources, and more importantly Glassfish V3 has been approved and accredited for the system we will be deploying to.
>
> Thanks,
>  Larry
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/4/10 9:39 AM, Larry Touve wrote:
> Hello,
>
>    I've been rapidly learning the ins&  outs of OSGi and was wondering if any others were in similar situations as we are.  We are re-architecting an existing web based system using an OSGI based framework.  We currently create an ear file that is deployed to a JBoss server.  We are moving an architecture where we deploy bundles to an OSGi framework.
>
> I have an existing Felix 2.0.1 installation and have tried (unsuccessfully) to deploy Glassfish V3 using Sahoo's embeddedgf activator<http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime>.  It installs all of the bundles and seems to start some of them, but there seems to be some unresolved dependencies, and the domain doesn't start up.  Has anyone tried this with any success?
>
> My next approach was to simply start up Glassfish, then use the Felix framework that Glassfish starts up.  I have dropped the Felix Web Console bundles in the autodeploy directory and everything starts up fine - I can access the domain root page, the GF Admin console, and the Felix Web Console.  I was curious to see what other's opinions were as to this scenario in a production environment (starting up GF and using its Felix, as opposed to starting up Felix, then deploying GF to it).
>    

Well, for now, I'd stick with starting GF since the other approach is 
only at the experimental stages, but I think it will eventually work 
just as well either way in the future.

Essentially, the GF launcher is just a custom OSGi framework launcher, 
so there is very little difference between the two approaches.

-> richard
> We are looking at Glassfish vs. something lightweight like Jetty or Tomcat for a couple of reasons: we will be using JMS and JDBC datasources, and more importantly Glassfish V3 has been approved and accredited for the system we will be deploying to.
>
> Thanks,
>   Larry
>
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: Glassfish OSGI and Felix

Posted by Karl Pauls <ka...@gmail.com>.
If you are targeting glassfish anyways, I'd say it makes sense to not
wrap it inside another felix instance. If you still want to do that,
maybe give us the output of the bundles not resolving for glassfish.
Furthermore, try to use felix 2.0.4 instead of felix 2.0.1.

regards,

Karl

On Thu, Mar 4, 2010 at 3:39 PM, Larry Touve <lt...@potomacfusion.com> wrote:
> Hello,
>
>  I've been rapidly learning the ins & outs of OSGi and was wondering if any others were in similar situations as we are.  We are re-architecting an existing web based system using an OSGI based framework.  We currently create an ear file that is deployed to a JBoss server.  We are moving an architecture where we deploy bundles to an OSGi framework.
>
> I have an existing Felix 2.0.1 installation and have tried (unsuccessfully) to deploy Glassfish V3 using Sahoo's embeddedgf activator<http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime>.  It installs all of the bundles and seems to start some of them, but there seems to be some unresolved dependencies, and the domain doesn't start up.  Has anyone tried this with any success?
>
> My next approach was to simply start up Glassfish, then use the Felix framework that Glassfish starts up.  I have dropped the Felix Web Console bundles in the autodeploy directory and everything starts up fine - I can access the domain root page, the GF Admin console, and the Felix Web Console.  I was curious to see what other's opinions were as to this scenario in a production environment (starting up GF and using its Felix, as opposed to starting up Felix, then deploying GF to it).
>
> We are looking at Glassfish vs. something lightweight like Jetty or Tomcat for a couple of reasons: we will be using JMS and JDBC datasources, and more importantly Glassfish V3 has been approved and accredited for the system we will be deploying to.
>
> Thanks,
>  Larry
>
>



-- 
Karl Pauls
karlpauls@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org