Issue Details (XML | Word | Printable)

Key: GLASSFISH-15772
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Sanjeeb Sahoo
Reporter: Joe Di Pol
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
glassfish

3.0.1 to 3.1 update requires removal of osgi-cache for the DAS to start

Created: 31/Jan/11 04:34 PM   Updated: 20/Oct/11 12:04 PM   Resolved: 20/Oct/11 12:03 PM
Component/s: OSGi
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1_b09, 4.0

Time Tracking:
Not Specified

File Attachments: 1. Text File upgrade-patch.txt (3 kB) 02/Feb/11 10:46 PM - Sanjeeb Sahoo

Environment:

Solaris 11 Express

Issue Links:
Dependency
 
Related
 

Tags: 3_1-exclude 3_1-next 3_1-upgrade 3_1_1-scrubbed
Participants: Alex Pineda, Chris Kasso, Joe Di Pol, Nazrul, Richard S. Hall, Sanjeeb Sahoo and Snjezana Sevo-Zenzerovic


 Description  « Hide

After upgrading from 3.0.1 to 3.1 I can't start the DAS unless I remove osgi-cache. Here are the details:

  • Unzipped glassfish-3.0.1-b22.zip
  • "pkg list", answer 'y' to install pkg
  • "pkg list" to verify package versions
  • asadmin start-domain, asadmin version, asadmin stop-domain
  • Edit .org.opensolaris,pkg/cfg_cache and change
    preferred-authority = dev.glassfish.org
  • pkg image-update, pkg list to verify 3.1 packages are installed
  • asadmin start-domain appears to work, but log file has the following
    exception and no subsequent asdmin commands can contact the DAS.
    -----------------------------------------------------------------
    [#|2011-01-31T15:52:41.334-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-1;|java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
    at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
    Caused by: com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [43] State [INSTALLED] [org.glassfish.web.weld-integration(Weld integration for glassfish):3.1]
    at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:174)
    at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:341)
    at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:121)
    at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:108)
    at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:132)
    at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
    at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:698)
    at java.util.AbstractList$Itr.next(AbstractList.java:345)
    at java.util.AbstractCollection.toArray(AbstractCollection.java:124)
    at java.util.ArrayList.addAll(ArrayList.java:472)
    at com.sun.enterprise.v3.server.SnifferManagerImpl.getSniffers(SnifferManagerImpl.java:92)
    at com.sun.enterprise.v3.server.PostInitializer.postConstruct(PostInitializer.java:63)
    at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:128)
    at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:88)
    at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:79)
    at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
    at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:136)
    at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
    at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
    at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
    ... 6 more
    Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.web.weld-integration [43]: Unable to resolve 43.1: missing requirement [43.1] package; (&(package=com.sun.enterprise.security)(version>=3.1.0)) [caused by: Unable to resolve 208.1: missing requirement [208.1] package; (&(package=com.sun.jaspic.config.factory)(version>=3.1.0)) [caused by: Unable to resolve 263.0: missing requirement [263.0] package; (package=com.sun.security.auth.login)]]
    at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1719)
    at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
    at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:166)
    ... 27 more
    #]

[#|2011-01-31T15:52:41.368-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=39;_ThreadName=Thread-1;|*ERROR* Configuration org.apache.felix.fileinstall.510e2b02-1ab9-4285-9170-c30d9f443728 referred to by factory org.apache.felix.fileinstall does not exist|#]
-----------------------------------------------------------------

  • If I kill the DAS, remove osgi-cache, then start the domain the domain
    comes up OK.
  • If I repeat the test, but try to start the 3.1 domain with --upgrade
    it also fails with an OSGi exception (albeit a different one):

ERROR: Error starting file:/export2/home/dipol/tmp/gf/glassfishv3/glassfish/modules/autostart/osgi-web-container.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.osgi-web-container [217]: Unable to resolve 217.0: missing requirement [217.0] package; (&(package=com.sun.enterprise.web)(version>=3.0.0)) [caused by: Unable to resolve 175.1: missing requirement [175.1] package; (&(package=com.sun.web.security)(version>=3.1.0)) [caused by: Unable to resolve 188.1: missing requirement [188.1] package; (&(package=com.sun.enterprise.security)(version>=3.1.0)) [caused by: Unable to resolve 208.1: missing requirement [208.1] package; (&(package=com.sun.jaspic.config.factory)(version>=3.1.0)) [caused by: Unable to resolve 263.0: missing requirement [263.0] package; (package=com.sun.security.auth.login)]]]])
org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.osgi-web-container [217]: Unable to resolve 217.0: missing requirement [217.0] package; (&(package=com.sun.enterprise.web)(version>=3.0.0)) [caused by: Unable to resolve 175.1: missing requirement [175.1] package; (&(package=com.sun.web.security)(version>=3.1.0)) [caused by: Unable to resolve 188.1: missing requirement [188.1] package; (&(package=com.sun.enterprise.security)(version>=3.1.0)) [caused by: Unable to resolve 208.1: missing requirement [208.1] package; (&(package=com.sun.jaspic.config.factory)(version>=3.1.0)) [caused by: Unable to resolve 263.0: missing requirement [263.0] package; (package=com.sun.security.auth.login)]]]]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409) (albeit a different one):
at org.apache.felix.framework.Felix.startBundle(Felix.java:1719)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1148)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [249] State [INSTALLED] [org.glassfish.loadbalancer.load-balancer-admin(Load-Balancer admin):3.1]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:174)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:341)
at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:121)
at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:108)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:132)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
at org.glassfish.config.support.DomainXml.upgrade(DomainXml.java:152)
at org.glassfish.config.support.DomainXml.run(DomainXml.java:118)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateConfig(AbstractModulesRegistryImpl.java:173)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:155)
at com.sun.enterprise.module.bootstrap.Main.createHabitat(Main.java:430)
at org.jvnet.hk2.osgiadapter.HK2Main.createHabitat(HK2Main.java:93)
at org.glassfish.kernel.GlassFishActivator$1.newGlassFish(GlassFishActivator.java:104)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
... 6 more
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.loadbalancer.load-balancer-admin [249]: Unable to resolve 249.0: missing requirement [249.0] package; (&(package=com.sun.enterprise.security.ssl)(version>=3.1.0)) [caused by: Unable to resolve 208.1: missing requirement [208.1] package; (&(package=com.sun.jaspic.config.factory)(version>=3.1.0)) [caused by: Unable to resolve 263.0: missing requirement [263.0] package; (package=com.sun.security.auth.login)]]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1719)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:166)
... 19 more



Richard S. Hall added a comment - 31/Jan/11 04:55 PM

Nothing jumps out at me in these exception messages. Was there some change in the way the package com.sun.security.auth.login is being exported and/or imported?


Richard S. Hall added a comment - 31/Jan/11 05:38 PM

Can I reproduce this situation by just using a GFv3 osgi-cache with a GFv3.1 installation?

Off the top of my head, the only thing that I can think of is that the bundles in the modules/ directory are not all being installed/updated in a single pass. So, perhaps some new bundles are trying to be used with old bundles that don't provide all the needed packages. But this is just a guess.


Sanjeeb Sahoo added a comment - 01/Feb/11 03:37 AM

Yes, I can reproduce the issue.

1. com.sun.security.auth.login is a package exported by system bundle fragment "glassfish-extra-jre-packages.jar." This bundle did not use to export that package in v3.0.1. This can be confirmed from the svn history shown below:

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn annotate core/extra-jre-packages/pom.xml | grep com.sun.security.auth.login
43610 kumarjayanti com.sun.security.auth.login,
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn log -r43610 core/extra-jre-packages/pom.xml
------------------------------------------------------------------------
r43610 | kumarjayanti | 2010-12-09 12:39:58 +0530 (Thu, 09 Dec 2010) | 1 line

fix for 14881 and 14537
------------------------------------------------------------------------

2. Run using "asadmin start-domain -v" the very first time after running "pkg image-update." You will actually see the bundles getting updated and glassfish-extra-jre-packages.jar is one of the bundles which get updated. We do issue a refreshPackages() after updating all bundles, but it seems to me that there is no way for a system bundle to be refreshed. Richard can comment more on this.

3. There is definitely one issue in 3.1 felix configuration because of which bundles from endorsed dir are not getting updated properly. In v3.0.x, we used to install the endorsed bundles with url:
glassfish/modules/endorsed/javax.annotation.jar
Now, we try to install them as
glassfish/modules//endorsed/javax.annotation.jar
Because of the double //, the locations don't match and we end up installing the bundles twice. This is quite simple to fix. The fix involves changing felix config file only. But, that alone does not fix the entire issue reported here. We have to understand how to refresh system bundle fragments.


Sanjeeb Sahoo added a comment - 01/Feb/11 03:41 AM

Since there is a work around, how critical is the bug at this stage of release? Can we document the work around for people upgrading from 3.0.x to 3.1? It will only be applicable for those users. Pl note, we don't even know a fix at this point of time.


Sanjeeb Sahoo added a comment - 01/Feb/11 04:14 AM

Please refer to #3 in my first comment. If we fix the felix config file for endorsed bundles, then server will start fine by just restarting. There is no need to clean the osgi-cache. In other words, the exception will happen only the first time.


Richard S. Hall added a comment - 01/Feb/11 07:29 AM

Although not a heavily tested feature, but if you need to "refresh" the system bundle then you must call update() on it. This will stop the framework and restart it.

So, in theory, if we detect the case where the framework needs to be refreshed, then we should update() the system bundle first before restarting any other bundles. Of course, this is a little tricky since the bundle performing the update() will get stopped as a result of stopping the framework, so it should do this as its last step probably on a separate thread. I think when that bundle restarted, it should be able to just treat the restart as a normal one.


Joe Di Pol added a comment - 01/Feb/11 10:00 AM

Not sure if this matters or not, but there are two different exceptions listed in the bug description. The first is encountered when starting the domain, the second is encountered when starting the domain with "--upgrade".


Sanjeeb Sahoo added a comment - 01/Feb/11 10:23 AM

Yes, they are all caused by the same issue. If we fix GLASSFISH-15778, then both the scenarios will succeed after one failed attempt.


Alex Pineda added a comment - 02/Feb/11 07:58 AM

Just want to note that during our Update testing, we have been removing the osgi-cache directory as noted in issue http://java.net/jira/browse/GLASSFISH-11880, but with the plan to run "asadmin --upgrade" as part of updating a 3.0 or 3.0.1 system, it appears that removing the osgi-cache directory will not work anymore and we will need a fix to start the domain. Am I correct in my understanding of this issue? Can someone please confirm.


Snjezana Sevo-Zenzerovic added a comment - 02/Feb/11 10:50 AM

Alex, I think that these two requirements (cleaning up OSGi cache and running 'asadmin -upgrade') are rather ortogonal. As I understand it, cleanup of OSGi cache will be required if this issue is not resolved and it apparently is, since 15778 is fixed and closed. On the other hand, running domain config upgrade remains necessary due to other issues we run into. So, at this point, my understanding is that you will not need to remove OSGi cache but you will need to restart the domain with upgrade option.


Nazrul added a comment - 02/Feb/11 12:07 PM

Have we considered removing the OSGi cache when domain is started with --upgrade option?


Joe Di Pol added a comment - 02/Feb/11 01:56 PM - edited

I tried the nightly b41-02_02_2011 which I think has the fix for 15778. This time I tested by replacing the 3.1 domain1 with the 3.0.1 domain1. I made sure that the install location for 3.1 matched that of where 3.0.1 was installed. Now when I run start-domain with --upgrade I get the follow exceptions and it hangs:

INFO: Successfully launched in 16 msec.
Launching GlassFish on Felix platform
Feb 2, 2011 2:06:29 PM Main start
WARNING: Exception while starting bundle org.glassfish.core.kernel [204]
org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.core.kernel [204]: Unable to resolve 204.0: missing requirement [204.0] package; (&(package=com.sun.appserv.server)(version>=3.0.0)) [caused by: Unable to resolve 202.0: missing requirement [202.0] package; (&(package=com.sun.enterprise.module)(version>=1.0.0)) [caused by: Unable to resolve 57.0: missing requirement [57.0] package; (&(package=com.sun.hk2.component)(version>=1.0.0)) [caused by: Unable to resolve 198.0: missing requirement [198.0] package; (package=org.jvnet.tiger_types)]]]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1719)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.jvnet.hk2.osgimain.Main.start(Main.java:154)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1827)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1744)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1148)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:662)
org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.osgi-web-container [217]: Unable to resolve 217.0: missing requirement [217.0] package; (&(package=com.sun.enterprise.config.serverbeans)(version>=3.0.0)) [caused by: Unable to resolve 10.0: missing requirement [10.0] package; (&(package=com.sun.appserv.server.util)(version>=3.0.0)) [caused by: Unable to resolve 187.0: missing requirement [187.0] package; (&(package=com.sun.enterprise.module.bootstrap)(version>=1.0.0)) [caused by: Unable to resolve 57.0: missing requirement [57.0] package; (&(package=com.sun.hk2.component)(version>=1.0.0)) [caused by: Unable to resolve 198.0: missing requirement [198.0] package; (package=org.jvnet.tiger_types)]]]]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1719)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1148)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:662)
ERROR: Error starting file:/export2/home/dipol/tmp/gf/glassfishv3/glassfish/modules/autostart/osgi-web-container.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.osgi-web-container [217]: Unable to resolve 217.0: missing requirement [217.0] package; (&(package=com.sun.enterprise.config.serverbeans)(version>=3.0.0)) [caused by: Unable to resolve 10.0: missing requirement [10.0] package; (&(package=com.sun.appserv.server.util)(version>=3.0.0)) [caused by: Unable to resolve 187.0: missing requirement [187.0] package; (&(package=com.sun.enterprise.module.bootstrap)(version>=1.0.0)) [caused by: Unable to resolve 57.0: missing requirement [57.0] package; (&(package=com.sun.hk2.component)(version>=1.0.0)) [caused by: Unable to resolve 198.0: missing requirement [198.0] package; (package=org.jvnet.tiger_types)]]]])


Snjezana Sevo-Zenzerovic added a comment - 02/Feb/11 04:14 PM

At this point I would be sorely tempted to either require cache cleanup or have it done by upgrade hook as suggested by Nazrul...


Alex Pineda added a comment - 02/Feb/11 05:44 PM

My reference to issue 11880 had an extra comma in the link and thus, the bug was not visible. The clean link is http://java.net/jira/browse/GLASSFISH-11880


Sanjeeb Sahoo added a comment - 02/Feb/11 06:48 PM

Since we are talking about removing osgi-cache either manually or automatically, the simplest solution would be to change the cache-directory name for 3.1 to something like "osgi-cache-31" so that when user either upgrades an existing domain or updates an existing installation, they won't see stale cache. It is a fairly simple configuration change. Should I go ahead and do this?


Chris Kasso added a comment - 02/Feb/11 07:37 PM

Why retain it and what happens when we ship 3.2? We rename it again to osgi-cache-32?

If the decision is that the cache should not be retained then I would vote for removing it automatically. I wish someone could describe or point me to a document that describes the circumstance in which the cache should be removed.


Richard S. Hall added a comment - 02/Feb/11 07:42 PM

FYI:

It would be great if we could ultimately fix this. The issue is a slightly tricky one, but Sahoo and I have come up with an approach to properly solve the issue. The issue boils down to the fact that system bundle fragments used to expose some class path classes do not get refreshed when updated like normal bundles; in those cases you must restart the framework. This is possible for us to do in the launcher, we just don't currently do it.

One downside, though, is that while looking into this, I uncovered a bug in Felix related to restarting an instance of the framework. So, to properly fix it, not only do we need to implement the solution to address the issue above, but we'll also need another release of Felix to address this framework restart bug.


Richard S. Hall added a comment - 02/Feb/11 07:45 PM - edited

Regarding when the cache should be removed, I would say never. Or at least not unless we can guarantee that the user hasn't installed any other bundles. The cache is not something that can always be recreated when deleted if bundles have persisted state, so deleting it automatically could irritate some people. Since we do allow people to install arbitrary bundles, we cannot assume that they will never install a bundle that maintains state.


Chris Kasso added a comment - 02/Feb/11 08:04 PM

If it would take another week for the new Felix release then I don't think we can accommodate it now. The schedule won't allow it.

An alternative would be to implement the cache removal for 3.1 and deliver the correct fix in 3.2 at which point the removal code could be, well, removed.


Richard S. Hall added a comment - 02/Feb/11 08:12 PM

Yeah, I knew another Felix release would be problematic, which is why I mentioned it. I think your proposal sounds reasonable.

However would we want to consider renaming it instead of deleting it? osgi-cache.bak or something? I don't know the odds that we might irritate someone.


Chris Kasso added a comment - 02/Feb/11 09:30 PM

I agree and renaming it to osgi-cache.bak would seem reasonable given it maybe maintaining persisted state.


Sanjeeb Sahoo added a comment - 02/Feb/11 10:46 PM

See the attached patch which does the following:
When -upgrade option is used, the launcher will rename the osgi-cache directory to osgi-cache$timestamp. It will log a message with the renamed directory name. If it fails to rename for whatever reason (e.g., some process holding a lock on the file e.g.), then it throws an exception. This patch is a minor improvement over what Bobby suggested earlier in a private email.

I have tested this patch and it works. Please note, I don't own admin module, so it will be better if someone in admin team checks this in. Nazrul, please reassign if you agree to this.


Sanjeeb Sahoo added a comment - 03/Feb/11 11:45 AM

Committed the work around suggested in the earlier attached patch.

trunk:
Sending admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java
Sending admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/LocalStrings.properties
Transmitting file data ..
Committed revision 44878.

3.1 branch:
Sending admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncher.java
Sending admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/LocalStrings.properties
Transmitting file data ..
Committed revision 44879.

Excluding this bug from 3.1 release as well.


Chris Kasso added a comment - 04/Feb/11 12:54 PM

Sanjeeb Sahoo added a comment - 19/Oct/11 06:06 AM

Can the submitter try upgrading from 3.0.x to 3.1.x and tell me if they still any issues? This should no longer be an issue after the work we have done wrt osgi-cache in 3.1.1. If it is not an issue, I would like to mark it as resolved in 3.1.1.


Sanjeeb Sahoo added a comment - 20/Oct/11 12:03 PM

This bug is fixed as part of the following check in which addresses a few other similar bugs as well. See svn log for details.
3.1.1 checkin details:
Sending core/bootstrap/osgi.bundle
Sending core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/ASMainHelper.java
Deleting core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/AutoProcessor.java
Sending core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/Constants.java
Deleting core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/EmbeddedOSGiGlassFishRuntimeBuilder.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/GlassFishDecorator.java
Deleting core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/GlassFishMainActivator.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/GlassFishRuntimeDecorator.java
Deleting core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/OSGiFrameworkLauncher.java
Deleting core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/OSGiGlassFishRuntimeBuilder.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/BundleProvisioner.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/Constants.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntime.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntimeBuilder.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/GlassFishMainActivator.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/Jar.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiFrameworkLauncher.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishImpl.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntime.java
Adding core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntimeBuilder.java
Sending core/bootstrap/src/main/resources/META-INF/services/org.glassfish.embeddable.spi.RuntimeBuilder
Sending core/kernel/osgi.bundle
Sending core/kernel/pom.xml
Deleting core/kernel/src/main/java/org/glassfish/kernel/GlassFishActivator.java
Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Sending packager/glassfish-nucleus/pom.xml
Sending pom.xml
Transmitting file data ......................
Committed revision 47494.

Forward ported to trunk in svn rev #47505.