[GLASSFISH-18897] Remove non OSGI (exception-annotation-processor.jar) from glassfish-corba-orb of glassfish-corba bundle Created: 13/Jul/12  Updated: 16/Jul/12

Status: Open
Project: glassfish
Component/s: orb, packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: vijay_oracle Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

cp glassfish3/glassfish/config/osgi.properties glassfish3/glassfish/domains/domain1/config
set glassfish.osgi.ondemand=true
Start Glassfish server (./asadmin start-domain -v)


Attachments: Text File Error.txt    
Tags: corba, packager

 Description   

glassfish-corba artifact has a dependency on artifact id glassfish-corba-orb with group id org.glassfish.corba; being an external jar it has a dependency on exception-annotation-processor.jar which is non OSGI and has no OSGI metadata available. Because of this plain jar being packaged and available in modules directory in distribution the server fails to startup.

The JAR needs to be removed from getting packaged during the build.

Please find the Exception attached.






[GLASSFISH-11336] glassfish-ejb-lite has a runtime dependency on glassfish-jpa Created: 18/Dec/09  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Alexis MP Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-13839 ejb-container should not have hard ru... Open
Issuezilla Id: 11,336
Tags: 3_1-exclude

 Description   

The "glassfish-ejb-lite" IPS package contains ejb-container.jar which imports org.glassfish.persistence.common;version="3.0"

The implementation for org.glassfish.persistence.common is part of the glassfish-jpa package (persistence-common.jar in fact).
glassfish-jpa also drags along glassfish-jca...

ejb-container.jar should not need to import org.glassfish.persistence.common.
(glassfish-jpa should not need to be present to use glassfish-ejb-lite).



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

Tentatively setting target milestone to ms7. ejb-container issue 13839 has been
filed to address actual ejb-container dependency and fix for that issue will
implicitly fix this one.

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

Excluding the issue from 3.1 release and setting target milestone to 3.2 since
fix requires extensive changes in ejb-container. As temporary workaround, 3.1
glassfish-ejb-lite package will have defined "require" dependency on
glassfish-jpa to prevent runtime problems.





[GLASSFISH-12288] Zip version of downloads should contain the verson number Created: 18/Jun/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: v3.0.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: sandoz Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 12,288

 Description   

GlassFish 3.0.1 and GlassFish 3.1 promoted and nightly zip files when unziped
create a directory:

glassfishv3

this should be renamed to:

glassfish-<version>

where <version> corresponds to the property GlassFish version, say
glassfish-3.0.1, and any indication of promoted or nightly, say
glassfish-3.1-ea-b04.



 Comments   
Comment by Alexis MP [ 18/Jun/10 ]

cc

Comment by Ryan O'Connell [ 18/Jun/10 ]

IMO, this is a bad idea. Many automated tasks (that run daily) assume the value
of the installation path and to change the install location on a build by build
basis would break many of these tasks. The automated tasks can certainly be
fixed but this could cause quite a few short term issues and require work that
doesn't need to be done.

I think a consistent install location is much more user friendly. The version
info is in the bundle name. That seems sufficient.

Just my $0.02.

Comment by sandoz [ 18/Jun/10 ]

I totally disagree. You seem to be making the argument from the position of
convenience for us rather than our users.

I consider it the opposite of user friendly for users who download GlassFish and
unzip. It goes against common convention that the zip file name correlates to
the directory name that is created when unzipped. It is not hard for tooling to
handle this situation if that convention is adhered to.

Especially for stable releases i would expect the version name to be in the
unzipped directory (e.g. download a zip of Tomcat for example). Also the naming
is incorrect the 'v' is no longer relevant.

Comment by Scott Fordin [ 18/Jun/10 ]

Please let me know if this RFE is implemented, because it will have a
documentation impact. Also, shouldn't this issue type really be an RFE rather
than a DEFECT?

Comment by Ryan O'Connell [ 18/Jun/10 ]

I certainly agree that if the "v3" in the path was meant to signify a specific
version then it should probably match the appropriate version, similar to Tomcat
and other distributions.

I just wanted to point out that this is a significant change and there are
ramifications for such a change. If these ramifications have been considered
and the change is deemed necessary, great. I'm not sure I agree with your
assumption that the only users who will find this change unfriendly is "us". I
have a feeling some of our users (not "us") may also find this change unfriendly.

As always just my $0.02.

Comment by ludo [ 18/Jun/10 ]

Well, maybe too late for this to change as both NetBeans 6.9 and Eclipse 3.6 depend (I think) on this file
layout bug...

Or involve me and Vince on the status...

Comment by Snjezana Sevo-Zenzerovic [ 18/Jun/10 ]

Moving to packaging subcategory, taking ownership, marking as enhancement...

FWIW, there will be no changes to current 3.0.1 release which is already out of
the door as the result of this issue, no matter what we decide going forward.

As is obvious from previous comments there are pros and cons to this. Another
"con" argument is that it becomes very easy for user to shoot themselves in the
foot if they rely solely on the name of top level directory to determine the
actual version of server runtime since all our distributions are pkg(5) enabled
and user can easily upgrade the runtime to any newer minor or update release or
even to newer promoted build. In extreme cases, update client can be set to
apply available updates automatically.

The original intent of "glassfishv3" naming was to contain only the major
version and distinguish the installation directory from, say, glassfishv2 (or
glassfish4 once that happens). Within that single major version, all upgrade
paths to minor or update releases are expected to be supported through pkg(5)
and UC clients so the only thing that is still guaranteed after such update is
that the major version is the same as the one at the time of original installation.

As per current 3.1 file layout specification, we will remove "v" from top level
directory so it will become glassfish3 but that's the only change that was
planned for the rest of 3.x release lifecycle.

Comment by janey [ 18/Jun/10 ]

cc'ing myself

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-15648] Make IPS package dedicated to bean-validator Created: 21/Jan/11  Updated: 10/Dec/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

>>>>> On Wed, 19 Jan 2011 13:00:20 -0800, Snjezana Sevo-Zenzerovic said:

EB> How much work would it be to create a bean-validator IPS package? What
EB> other packages would be impacted and what changes would they need to
EB> make?
EB>
SS> We would need to create dedicated bean validator package and adjust
SS> glassfish-hk2 package dependency so that it depends on bean-validator
SS> package. We would also need to add new package to the dependency list
SS> for distribution metapackages and incorporation packages which define
SS> overall distribution content.

SS> In any case, this is something we can consider doing in 3.2 release time
SS> frame - I don't see major issues from technical point of view but Jerome
SS> may have some thoughts on the interaction of HK2 with potentially
SS> different bean validator versions.
EB> Regarding the monetary incentive angle for this. Because bean-validator
EB> itself is something we get from JBoss I don't think it makes much sense
EB> to offer it just in the "support" repository. In fact, it might make sense
EB> to only offer it in the "dev" repository.
EB>
SS> Well, the same version of bean validator could very well live in
SS> different repositories during its lifecycle - it would start in "dev"
SS> and move upwards to more stable repositories as we stabilize our own
SS> release.

SS> Being able to decouple bean validator and offer potentially unstable
SS> version as "dev" content would certainly help with some aspects of
SS> content refresh so thanks for bringing this up.



 Comments   
Comment by Nazrul [ 10/Dec/12 ]

This is an important but nice to have feature for GlassFish build infrastructure. We may work on this after all core infrastructure is in place.





[GLASSFISH-5564] Remove duplicate pkg-client jar Created: 20/Aug/08  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Nazrul Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,564
Tags: 3_1-exclude

 Description   

Build: GFv3 Prelude b19

Currently, we have two copies of pkg-client jars.
1) glassfishv3-prelude/glassfish/modules/pkg-client-1.0.7-14.1084.jar
2) glassfishv3-prelude/pkg/lib/pkg-client.jar

#1 (pkg-client under under glassfish/modules) should be removed.



 Comments   
Comment by kumara [ 20/Aug/08 ]

Add gfv3-prelude-include to status whiteboard

Comment by kumara [ 03/Sep/08 ]

v3 defect tracking

Comment by Snjezana Sevo-Zenzerovic [ 08/Sep/08 ]

...

Comment by kumara [ 22/Sep/08 ]

To be addressed after Prelude release. Please make sure than admin console and
pkg use the same version while creating distributions.

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Nazrul [ 24/Jun/09 ]

We should fix this for GFv3.

Comment by Snjezana Sevo-Zenzerovic [ 02/Oct/09 ]

This is P3 as per priority guidelines - workaround in the feature that needs to
be fixed.

Comment by Snjezana Sevo-Zenzerovic [ 03/Nov/09 ]

Based on the discussion with Jerome, fix is deemed too risky. Deferring to v3.1.

Comment by Snjezana Sevo-Zenzerovic [ 08/Nov/10 ]

Non-critical issue, deferring to 3.2.

Comment by Snjezana Sevo-Zenzerovic [ 15/Feb/13 ]

Deferring to future release due to time/resource constraints and low impact.





[GLASSFISH-6535] Need to fix the names of the jars Created: 14/Oct/08  Updated: 06/Oct/10

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Nazrul Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,535
Tags: 3_1-exclude

 Description   

Issue 5559 only addressed removing the SNAPSHOT from the jar name. We still need
to fix the jar names.

  • Some jars use reverser domain name (org.eclipse.persistence.core-1.0.jar)
  • Some jars use regular names with dashes (admin-cli.jar)
  • Some jars use package names (javax.annotation.jar)
  • Some of the jars are under a different directory called "web" (Why is web
    treated differently than the rest?).

Here are the latest from build 28a of GFv3 Prelude.

admin-cli.jar grizzly-optionals.jar
admin-util.jar hk2-core.jar
amx-api.jar hk2.jar
amx-impl.jar inmemory.jacc.provider.jar
annotation-framework.jar internal-api.jar
ant.jar javax.activation.jar
api-exporter.jar javax.annotation.jar
asm-all-repackaged.jar javax.enterprise.deploy.jar
auto-depends.jar javax.mail.jar
branding-fragment.jar javax.persistence.jar
branding.jar javax.resource.jar
cli-framework.jar javax.security.auth.message.jar
cli-optional.jar javax.security.jacc.jar
common-util.jar javax.servlet.jar
commons-codec-repackaged.jar javax.servlet.jsp.jar
config-api.jar javax.transaction.jar
config.jar javax.xml.stream.jar
connectors-internal-api.jar jdbc-admin.jar
connectors-runtime.jar jmxremote_optional-repackaged.jar
console-branding-plugin.jar jpa-connector.jar
console-common.jar jsf-api.jar
console-custom-branding-plugin.jar jsftemplating.jar
console-jdbc-plugin.jar jta.jar
console-plugin-service.jar kernel.jar
console-security-plugin.jar launcher.jar
console-updatecenter-plugin.jar ldapbp-repackaged.jar
console-web-plugin.jar monitoring-core.jar
container-common.jar org.eclipse.persistence.antlr.jar
dataprovider.jar org.eclipse.persistence.asm.jar
deployment-admin.jar org.eclipse.persistence.core.jar
deployment-autodeploy.jar org.eclipse.persistence.jpa.jar
deployment-client.jar org.eclipse.persistence.oracle.jar
deployment-common.jar osgi-adapter.jar
deployment-javaee-core.jar pkg-client.jar
dol.jar realms.jar
flashlight-agent.jar registration-api.jar
flashlight-framework.jar registration-impl.jar
gf-connectors-connector.jar security.jar
gf-jruby-connector.jar securitycommon.jar
glassfish-api.jar server-mgmt.jar
glassfish-ee-api.jar stats77.jar
glassfish-mbeanserver.jar sysnet-registration-repackaged.jar
glassfish-naming.jar tiger-types-osgi.jar
glassfish-registration.jar transaction-internal-api.jar
glassfish.jar web/
grizzly-jruby-module.jar work-management.jar
grizzly-jruby.jar wstx-asl.jar
grizzly-module.jar



 Comments   
Comment by Nazrul [ 14/Oct/08 ]

Need to fix this after GFv3 Prelude.

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Nazrul [ 24/Jun/09 ]

We should fix this before we ship GFv3. Based on our conversation we liked
"org.eclipse.persistence.jpa.jar" style name.

Comment by kumara [ 14/Sep/09 ]

Assign to ss141213. Please propose a scheme that can be implemented by snjezana and janey.

Comment by Sanjeeb Sahoo [ 23/Sep/09 ]

I don't think it is easy to fix this now. It's too late. So, excluding from v3
list of bugs to be fixed. If someone wants to fix it, here is something to keep
in mind:
What I have come across in various open source projects, the convention seems to
be this:
groupId: URL of the project responsible for the artifact
artifactId: primary Java package name
version: project version
Based on this, most of our artifacts need to change. We seem to be using
different groupId as well, e.g., org.glassfish.web, org.glassfish.deployment.
Instead, we should be using org.glassfish as groupId in all cases. The
artifactId should change to org.glassfish.web.glue, org.glassfish.web.connector,
etc. Then, the jar name automatically becomes org.glassfish.web.glue.jar or
org.glassfish.web.connector.jar.

Same holds true for HK2 artifacts or any other artifact.

We should also fix name and description field in pom.xmls as they appear as
bundle name and description when someone inspects the OSGi bundles using any tool.

Comment by kumara [ 07/Dec/09 ]

Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
issues submitted on v2.x release because they might not apply to v3.next release.

Comment by Sanjeeb Sahoo [ 06/Oct/10 ]

Reassign to packaging team

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

To be realistic, this issue will need to be addressed from the scratch in the
next major release...





[GLASSFISH-1353] Make source zips available for downloads Created: 20/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: ryan_shoemaker Assignee: ss144236
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,353

 Description   

It is really tedious to have to check out a copy of the glassfish workspace each
time I need to install a new build just so I have the sources available in the
debugger. Would it be possible to include (even as a separate download) a src
zip to go along with each build?



 Comments   
Comment by kohsuke [ 23/Oct/06 ]

+1. People developing system-level additions to Glassfish, like JAX-WS, is
having an awfuly hard time because of this.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-17522] atomic distribution does not start because of missing modules Created: 28/Oct/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

There seems to be missing modules which is causing atomic distribution to fail to start.



 Comments   
Comment by TangYong [ 22/Jun/12 ]

The issue seems to be the same as http://java.net/jira/browse/GLASSFISH-18642.

Comment by Sanjeeb Sahoo [ 18/Feb/13 ]

Exception seen in recent build (svn #59497)

Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: A MultiException has 1 exceptions. They are:
1. org.glassfish.hk2.api.MultiException: A MultiException has 2 exceptions. They are:
1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW]
2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
implementation=org.glassfish.common.util.admin.HK2BindTracingService
contracts=

{org.glassfish.common.util.admin.HK2BindTracingService,org.glassfish.hk2.api.ValidationService}
scope=javax.inject.Singleton
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=Bundle-SymbolicName={org.glassfish.main.common.util},Bundle-Version={4.0.0.SNAPSHOT}
rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW],13171230)
proxiable=null
analysisName=null
id=425
locatorId=0
identityHashCode=10284000
reified=false)


at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:202)
at com.sun.enterprise.module.bootstrap.Main.createServiceLocator(Main.java:272)
at org.jvnet.hk2.osgiadapter.HK2Main.createServiceLocator(HK2Main.java:120)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:95)
at com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.newGlassFish(GlassFishRuntimeDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.newGlassFish(OSGiGlassFishRuntime.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
... 6 more
Caused by: A MultiException has 2 exceptions. They are:
1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW]
2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
implementation=org.glassfish.common.util.admin.HK2BindTracingService
contracts={org.glassfish.common.util.admin.HK2BindTracingService,org.glassfish.hk2.api.ValidationService}

scope=javax.inject.Singleton
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=Bundle-SymbolicName=

{org.glassfish.main.common.util}

,Bundle-Version=

{4.0.0.SNAPSHOT}

rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW],13171230)
proxiable=null
analysisName=null
id=425
locatorId=0
identityHashCode=10284000
reified=false)

at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1631)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:360)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:378)
at org.jvnet.hk2.internal.ServiceLocatorImpl.checkConfiguration(ServiceLocatorImpl.java:1268)
at org.jvnet.hk2.internal.ServiceLocatorImpl.addConfiguration(ServiceLocatorImpl.java:1536)
at org.jvnet.hk2.internal.DynamicConfigurationImpl.commit(DynamicConfigurationImpl.java:212)
at org.glassfish.hk2.bootstrap.HK2Populator.populate(HK2Populator.java:137)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.parseInhabitants(OSGiModuleImpl.java:396)
at org.jvnet.hk2.osgiadapter.AbstractOSGiModulesRegistryImpl.parseInhabitants(AbstractOSGiModulesRegistryImpl.java:119)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:180)
... 12 more
Caused by: com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:223)
at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:79)
at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1623)
... 21 more
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.common.util [47]: Unable to resolve 47.0: missing requirement [47.0] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.api)(version>=4.0.0)(Unable to render embedded object: File ( Unable to resolve 52.0: missing requirement [52.0] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.grizzly.http.server)(version>=2.3.0)() not found.(version>=3.0.0))) [caused by: Unable to resolve 12.0: missing requirement [12.0] osgi.wiring.package; (osgi.wiring.package=org.glassfish.gmbal) [caused by: Unable to resolve 38.0: missing requirement [38.0] osgi.wiring.package; (osgi.wiring.package=org.glassfish.pfl.basic.algorithm)]]]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3962)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2025)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:215)
... 23 more





[GLASSFISH-18340] consolidate packager/nucleus-corba-base module with packager/nucleus-common Created: 08/Feb/12  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: Cheng Fang Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-17489 Remove glassfish-naming from nucleus ... Resolved
Tags: nucleus-cleanup

 Description   

Now that glassfish-naming module and its corba dependency have been removed from nucleus, packager/nucleus-corba-base is no longer related to corba. It now handles the packaging of pfl-*.jars. From the discussion with Tom Mueller, we may want to merge the remaining logic in nucleus-corba-base into nucleus-common and remove nucleus-corba-base module.

As of now, the following files reference nucleus-corba-base:
./distributions/nucleus/pom.xml
./packager/nucleus-common/build.xml
./packager/nucleus-common/pom.xml
./packager/nucleus-corba-base/build.xml
./packager/nucleus-corba-base/pom.xml
./packager/pom.xml






[GLASSFISH-18615] [packager changes] Separate reosurces component from jca component Created: 11/Apr/12  Updated: 11/Apr/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-18614 Separate reosurces component from jca... Open

 Description   

Please refer the issues
GLASSFISH-18614 and GLASSFISH-17657
A new packager module for "resources" (appserver/resources) need to be created.






[GLASSFISH-19368] Source bundle for each promoted build Created: 26/Nov/12  Updated: 26/Nov/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arungupta Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: javaone

 Description   

Based upon feedback received from the GlassFish Community Event at JavaOne and discussed internally, please release a zip with all source files for each promoted build on java.net. This needs to be done for future builds only.






[GLASSFISH-18760] pkg-toolkit and pkg-toolkit-corporation packages do not have a license. Created: 23/May/12  Updated: 27/Jun/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jclingan Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-next

 Description   

pkg-toolkit and pkg-toolkit-corporation packages do not have a license. I realize these are meta-packages, but the least path of resistance to satisfying legal requirements is to simply add the appropriate license to these packages.



 Comments   
Comment by jclingan [ 24/May/12 ]

Please add mq-branding IPS package to this issue.
Thank you.





[GLASSFISH-21215] UserError: ACC007 -- JAR does not contain a manifest Created: 26/Sep/14  Updated: 26/Sep/14

Status: Open
Project: glassfish
Component/s: deployment, ide-integration, packaging
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: thufir Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: netbeans
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 14.04



 Description   

background:

Java Web Start
Java Web Start allows your application client to be easily launched and automatically downloaded and updated. It is enabled for all application clients by default. For more information, see Using Java Web Start.

GlassFish Server Open Source Edition
Application Development Guide Release 4.0
page 172

and

Downloading and Launching an Application Client
If Java Web Start is enabled for your deployed application client, you can launch it for testing. Simply click on the Launch button next to the application client or application's listing on the App Client Modules page in the Administration Console.

GlassFish Server Open Source Edition
Application Development Guide Release 4.0
page 176

This, in fact, is incorrect. Appclient applications which run from the IDE launch from Glassfish missing the manifest. Glassfish fails to include the manifest with the JNLP file, resulting in errors such as:

org.glassfish.appclient.client.acc.UserError: ACC007: The app client file
/__JWSappclient/__app/SingletonQueue/SingletonQueueClient/
SingletonACCClient.jar does not contain a manifest; the app client
container cannot process it. Embedded programs should pass URIs with
scheme "jar:" for JAR files and scheme "file:" for directories.



 Comments   
Comment by thufir [ 26/Sep/14 ]

https://netbeans.org/bugzilla/show_bug.cgi?id=231769

http://markmail.org/message/5usjywzpyw3weesb#query:+page:1+mid:5usjywzpyw3weesb+state:results

http://forums.netbeans.org/topic22551.html

https://www.java.net/node/700937?force=967

http://stackoverflow.com/questions/11606529/need-help-running-an-ejb-app

apparently the error is caused by:

ACC007.diag.cause.1 = The file might not be a valid app client JAR or undeployed EAR. It might be another kind of file or have become corrupted.

neither of which is accurate. The EAR is valid and deploys, isn't corrupted.

https://community.oracle.com/thread/1570742?start=0&tstart=0

http://osdir.com/ml/java-netbeans-devel/2009-12/msg00043.html

https://forums.netbeans.org/topic21177.html

https://netbeans.org/bugzilla/show_bug.cgi?id=231769

https://www.java.net/node/700937?force=679

which is enough errors, and not enough solutions, to suggest that there's either a bug with glassfish itself or with the documentation. In any event, I can include logs if that's useful.





[GLASSFISH-19816] Package jline separately Created: 10/Mar/13  Updated: 10/Mar/13

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GLASSFISH-19124 introduces jline library in glassfish, but it packages it inside osgi-cli-interactive.jar. In future consider making available jline for subsystems to use by packaging it as a standalone bundle.






[GLASSFISH-19724] Error when downloading Java SE Examples Created: 24/Feb/13  Updated: 23/May/13

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: MathiasBehne Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java 7, glassfish 3.1.2, javaee6



 Description   

Application ID: [GlassFish Update Tool 2.3.5 (Build 56.2852)]
Timestamp : [2013-02-24 22:36:24 Malay Peninsula Standard Time(Malay Peninsula Standard Time)]
wx Version : [2.8.10.1]
wx Platform : [__WXMSW__]
Python Version: [2.4.6]
Platform : [Microsoft-Windows-32bit-WindowsPE]

Traceback (innermost last):
File "C:\Program Files (x86)\glassfish-3.1.2.2\updatetool\vendor-packages\updatetool\gui\mainframe.py", line 2086, in __image_install
img.make_install_plan(pkg_list, tracker_task, lambda: False, False)
File "C:\Program Files (x86)\glassfish-3.1.2.2\pkg\vendor-packages\pkg\client\image.py", line 2581, in make_install_plan
self.__call_imageplan_evaluate(ip, verbose)
File "C:\Program Files (x86)\glassfish-3.1.2.2\pkg\vendor-packages\pkg\client\image.py", line 620, in __call_imageplan_evaluate
ip.evaluate()
File "C:\Program Files (x86)\glassfish-3.1.2.2\pkg\vendor-packages\pkg\client\imageplan.py", line 464, in evaluate
self.add_pkg_plan(f)
File "C:\Program Files (x86)\glassfish-3.1.2.2\pkg\vendor-packages\pkg\client\imageplan.py", line 389, in add_pkg_plan
pp.evaluate(self.old_excludes, self.new_excludes)
File "C:\Program Files (x86)\glassfish-3.1.2.2\pkg\vendor-packages\pkg\client\pkgplan.py", line 148, in evaluate
raise RuntimeError, ["Duplicate actions", ddups]
RuntimeError: ['Duplicate actions', [(('dir', 'jdk7'), set([<pkg.actions.directory.DirectoryAction object at 0x09AB7030>, <pkg.actions.directory.DirectoryAction object at 0x08325CF0>])), (('dir', 'jdk7/demo'), set([<pkg.actions.directory.DirectoryAction object at 0x09AB7150>, <pkg.actions.directory.DirectoryAction object at 0x08325F30>])), (('dir', 'jdk7/demo/applets'), set([<pkg.actions.directory.DirectoryAction object at 0x09AB7530>, <pkg.actions.directory.DirectoryAction object at 0x0794D1D0>])), (('dir', 'jdk7/demo/applets/Animator'), set([<pkg.actions.directory.DirectoryAction object at 0x08592570>, <pkg.actions.directory.DirectoryAction object at 0x08EA8210>])), (('dir', 'jdk7/demo/applets/Animator/audio'), set([<pkg.actions.directory.DirectoryAction object at 0x09B5FAF0>, <pkg.actions.directory.DirectoryAction object at 0x07C02790>])), (('dir', 'jdk7/demo/applets/Animator/images'), set([<pkg.actions.directory.DirectoryAction object at 0x09B5FC10>, <pkg.actions.directory.DirectoryAction object at 0x07C028B0>])), (('dir', 'jdk7/demo/applets/Animator/images/Beans'), set([<pkg.actions.directory.DirectoryAction object at 0x08F9C150>, <pkg.actions.directory.DirectoryAction object at 0x080CCDD0>])), (('dir', 'jdk7/demo/applets/Animator/images/SimpleAnimation'), set([<pkg.actions.directory.DirectoryAction object at 0x08F9C270>, <pkg.actions.directory.DirectoryAction object at 0x080CCEF0>])), (('dir', 'jdk7/demo/applets/ArcTest'), set([<pkg.actions.directory.DirectoryAction object at 0x08592690>, <pkg.actions.directory.DirectoryAction object at 0x08EA8330>])), (('dir', 'jdk7/demo/applets/BarChart'), set([<pkg.actions.directory.DirectoryAction object at 0x085927B0>, <pkg.actions.directory.DirectoryAction object at 0x08EA8450>])), (('dir', 'jdk7/demo/applets/Blink'), set([<pkg.actions.directory.DirectoryAction object at 0x085928D0>, <pkg.actions.directory.DirectoryAction object at 0x08EA8570>])), (('dir', 'jdk7/demo/applets/CardTest'), set([<pkg.actions.directory.DirectoryAction object at 0x085929F0>, <pkg.actions.directory.DirectoryAction object at 0x08EA8690>])), (('dir', 'jdk7/demo/applets/Clock'), set([<pkg.actions.directory.DirectoryAction object at 0x08592B10>, <pkg.actions.directory.DirectoryAction object at 0x08EA87B0>])), (('dir', 'jdk7/demo/applets/DitherTest'), set([<pkg.actions.directory.DirectoryAction object at 0x08592C30>, <pkg.actions.directory.DirectoryAction object at 0x08EA88D0>])), (('dir', 'jdk7/demo/applets/DrawTest'), set([<pkg.actions.directory.DirectoryAction object at 0x08592D50>, <pkg.actions.directory.DirectoryAction object at 0x08EA89F0>])), (('dir', 'jdk7/demo/applets/Fractal'), set([<pkg.actions.directory.DirectoryAction object at 0x08592E70>, <pkg.actions.directory.DirectoryAction object at 0x08EA8B10>])), (('dir', 'jdk7/demo/applets/GraphLayout'), set([<pkg.actions.directory.DirectoryAction object at 0x09B5F0D0>, <pkg.actions.directory.DirectoryAction object at 0x08EA8D50>])), (('dir', 'jdk7/demo/applets/GraphLayout/audio'), set([<pkg.actions.directory.DirectoryAction object at 0x09268490>, <pkg.actions.directory.DirectoryAction object at 0x08AF02D0>])), (('dir', 'jdk7/demo/applets/GraphicsTest'), set([<pkg.actions.directory.DirectoryAction object at 0x08592F90>, <pkg.actions.directory.DirectoryAction object at 0x08EA8C30>])), (('dir', 'jdk7/demo/applets/JumpingBox'), set([<pkg.actions.directory.DirectoryAction object at 0x09B5F1F0>, <pkg.actions.directory.DirectoryAction object at 0x08EA8E70>])), (('dir', 'jdk7/demo/applets/JumpingBox/sounds'), set([<pkg.actions.directory.DirectoryAction object at 0x091D38B0>, <pkg.actions.directory.DirectoryAction object at 0x07CD5AD0>])), (('dir', 'jdk7/demo/applets/MoleculeViewer'), set([<pkg.actions.directory.DirectoryAction object at 0x09B5F310>, <pkg.actions.directory.DirectoryAction object at 0x08EA8F90>])), (('dir', 'jdk7/demo/applets/MoleculeViewer/models'), set([<pkg.actions.directory.DirectoryAction object at 0x08CFD5F0>, <pkg.actions.directory.DirectoryAction object at 0x08B1A150>])), (('dir', 'jdk7/demo/applets/NervousText'), set([<pkg.actions.directory.DirectoryAction object at 0x09B5F430>, <pkg.actions.directory.DirectoryAction object at 0x07C020D0>])), (('dir', 'jdk7/demo/applets/SimpleGraph'),

. . .



 Comments   
Comment by Joe Di Pol [ 23/May/13 ]

(I had to trim some text from the description to get this bug to save...)

It would be good if the reporter could state exactly what install bundled was used. SDK? Full or Web? With or without bundled JDK? I was unable to reproduce the problem with the web profile SDK without bundled JDK.

In any case the error is when installing the Java SE samples, and is caused by the fact that our Java SE IPS packages include support for both 32 and 64 bit windows and rely on the variant.os.bits configuration property to select which file to install. If that property is not set, then both files are installed resulting in the error reported.

variant.os.bits should be set to 32 or 64 in the [variants] section of:

installdir/.org.opensolaris,pkg/cfg_cache

like this:

[variants]
variant.os.bits = 32

For some reason it looks like that was not set for the Reporter. The work-around is to add such a line to cfg_cache if it doesn't exist.

Assigning to Snjezana since she knows this stuff well.





[GLASSFISH-20327] Debian Contribution Created: 17/Apr/13  Updated: 17/Apr/13

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: future release
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian 7 "Wheezy"



 Description   

Debian is known as the most reliable and stable operating system since decades. With the advent of Ubuntu it became rather popular. One drawback is that even the latest Generation of Debian (Codename "Wheezy") provides only a 2.1.1 release of GlassFish.

It would be great to see a more recent release of GlassFish found in the next Debian Distribution. To make this happen, it would be great if the GlassFish Installation Team would contact the GlassFish Team at the Debian Project to learn what the reason is for sticking with 2.1.1 and what steps are needed to upgrade to (at least) 3.1.2.2 with the next Debian release (v8, Codename "Jessie").

For contact information please see http://packages.debian.org/sid/glassfish-javaee.

The Debian Community would be happy to see GlassFish 3+ bundled within Debian "Jessie"!






[GLASSFISH-20811] Classpath issues with embedded Glassfish 4.0 and Guava 15.0 (Google Collection library) Created: 16/Sep/13  Updated: 03/Oct/13

Status: Open
Project: glassfish
Component/s: classloader, embedded, packaging
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: truemmer666 Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Maven 3.0.5, glassfish-embedded-all 4.0, arquillian 1.1.1.FINAL, arquillian-glassfish-embedded-3.1 1.0.0.CR4, Guava 15.0


Tags: classpath, embedded, guava

 Description   

We're unable to run Unit Tests with Arquillian and embedded Glassfish 4.0 if an application under test is using Guava 15.0.
The tests work with older versions of Guava (for example 13.01). The problem seems to originate in Glassfish using its own version of the Googles Collection library, which is subject to change and has been moved into the Guava project.

Can you guys suggest a solution to this problem, or do you know any good workarounds?

This is mentioned on the Guava-Homepage:

Guava contains a strictly compatible superset of the old, deprecated Google Collections Library. You should not use that library anymore.

This is the stack trace which occurs during deployment:

Sep 16, 2013 10:37:50 AM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor
	at org.jboss.weld.logging.WeldMessageConveyor.<init>(WeldMessageConveyor.java:61)
	at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27)
	at org.jboss.weld.logging.LoggerFactory.<init>(LoggerFactory.java:37)
	at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:53)
	at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:164)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:441)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:100)
	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
	at org.jboss.arquillian.container.glassfish.embedded_3_1.GlassFishContainer.deploy(GlassFishContainer.java:227)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
	at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)


 Comments   
Comment by Yser [ 16/Sep/13 ]

I had the same problem with testing a EJB-Archive with the embedded EJBContainer.
As a workaround I just removed the beans.xml from the archive and it worked for me, maybe that helps you.

Comment by obfischer [ 17/Sep/13 ]

The problem is that embedded Glassfish is a uberjar therefore we are not able to take influence on the dependencies provided by it. I had similar issues with embedded Glassfish and created GLASSFISH-20806 as RFE.

Comment by truemmer666 [ 17/Sep/13 ]

The problem is that MapMaker is deprecated and methods have been removed or moved to CacheBuilder.

makeComputingMap(Function<? super K,? extends V> computingFunction)

Deprecated.
Caching functionality in MapMaker is being moved to CacheBuilder, with makeComputingMap(com.google.common.base.Function<? super K, ? extends V>) being replaced by CacheBuilder.build(com.google.common.cache.CacheLoader<? super K1, V1>). See the MapMaker Migration Guide for more details. This method is scheduled for deletion in February 2013.

Comment by javaneze [ 03/Oct/13 ]

We have the same issue with Emb. GlassFish 3.1.2 and Guava 1.5 (it hit us just after I updated the version). It would be nice for GlassFish to remove this
restriction and make sure is using Guava as a proper dependency.

Thanks!





[GLASSFISH-2565] Platform Independent Install Package Created: 07/Mar/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: zwe Assignee: ss144236
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,565

 Description   

Hi,
Would you please supply a platform independent install package? (like JBoss) I
know that GlassFish using JNI and have platform dependent dynamic libraries and
batch/shell scripts, how about to package all the supported platforms (Solaris
Sparc/x86, Linux, Windows and MacOS) together?

For me, I want to use GlassFish on Windows, Linux, Solaris X86, it's not easy to
download 3 packages each time when there is a new build. I really like pure Java
application server application implementations like JBoss and JOnAS, and I hope
GlassFish have such kind of installer package at least although it is not pure
Java implementation.

Thanks.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-21367] Glassfish prevents applications from using bundled JNA Created: 29/May/15  Updated: 29/May/15

Status: Open
Project: glassfish
Component/s: OSGi, packaging, security
Affects Version/s: 3.1.2.2, 4.1, future release
Fix Version/s: None

Type: Bug Priority: Major
Reporter: emailnbw Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2.2 and higher including current nightly



 Description   

Glassfish is bundling JNA 3.2.2 inside libpam4j-repackaged.jar. This horribly old version of JNA does not support functionality, like allowing overriding of the system JNA with a bundled JNA via the system property jna.nosys=true. This prevents a web app which bundles a newer/different version of JNA from every being able to use it.

It also does not support logging the DLL search path used by JNA via jna.debug_load=true.

Finally, among other things, this version does not support a Native.loadLibrary API which allows one to supply a custom classloader for use in loading DLLs. This is important on windows because DLLs remain locked by the web application classloader (vs. a custom classloader) during an undeploy/deploy cycle preventing their removal/cleanup. You can work around this by using the API that supports a custom class loader.

As a workaround for this I repacked the libpam4j-repackaged.jar with the contents of a JNA.jar from the JNA 4.1.0 distro.

Please update the version of JNA bundled by this JAR in Glassfish.






[GLASSFISH-11389] javax:javaee-api:6.0 and javax.jvaee-web-api:6.0 are missing source jars Created: 05/Jan/10  Updated: 27/Feb/15

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: kohsuke Assignee: Romain Grécourt
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issue Links:
Relates
relates to GLASSFISH-21226 Java EE 6 API in the Maven repository... Open
Issuezilla Id: 11,389

 Description   

Those jars in the Maven repository should have their corresponding source jar
files to assist developers.



 Comments   
Comment by ludo [ 05/Jan/10 ]

To assist developers to do what?
The corresponding JARs are stripped (no bytecode for methods) and are meant to
be used only for compilation. IDEs like NB or Eclipse bundle a zip for the javadoc.
What other use case do you need to get the src? Debugging? In this case, these
jars are not used for execution so also not for debugging. In the case of
debugging, I think there is a complete GF src somewhere to step into the real
code you execute from the real non stripped gf jars.

Comment by kohsuke [ 05/Jan/10 ]

Use case 1: javadoc lookup
Maven-aware IDEs don't suddenly notice that the dependency I have is JavaEE API
and switch to the right javadoc. This is certainly true for Eclipse and IDEA,
and I suspect it to be the same with NetBeans Maven support.

In those IDEs, if I'm writing my code and wanted to quickly check the javadoc of
those APIs, they need the accompanied source jar to be able to display them.
Ditto for figuring out the default parameter names when implementing/overriding
methods defined in the spec. IDEs don't use the bytecode for this, but instead
they do this by parsing the source files.

Use case 2: step executing inside spec classes
Some of the classes in JavaEE API have methods that are often worth executing.
When the debugger steps into those code, it needs the source files to be able to
display what's being executed. For this purpose, it's OK that javaee-api.jar can
be stripped — the debugger executes actual classes in the app server — but
you do need to have the source files.

The whole point of providing source jars is so that the necessary association
happens automatically. It's true that the user can get the complete GlassFish
source bundle and tell their IDEs to do the right thing, but the reason Maven
users use Maven is so that those grunt work can be handled by a program, instead
of using precious human time.

Comment by ludo [ 05/Jan/10 ]

But these jars are stripped: no byte code for method
For javadoc, both Eclipse and NB bundles have the ee 6 doc inline embedded.

Comment by kohsuke [ 05/Jan/10 ]

As I wrote, it doesn't matter if the actual jar file has executable byte code in
it or not; IDE doesn't use them.

Even if your IDE has the EE6 docs bundled, I doubt if it kicks in when importing
a Maven project. Those javadocs are presumably associated with system-defined
"JavaEE" library, but when I load my Maven project, it doesn't use those as
dependencies; it just depends on ~/.m2/repository/javax/javaee-api/6.0/javaee-
api-6.0.jar as a library, and IDE won't have any javadoc nor the source code for
that.

Comment by ludo [ 05/Jan/10 ]

Make sense:=)

Comment by ludo [ 07/Oct/10 ]

Legal aspect issue, not for 3.1. Moving to P4

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Darious3 [ 20/Dec/12 ]

Any progress here? I know legal aspects take a long time to resolve, but has any of the legal work been started 2 years ago?

Comment by Romain Grécourt [ 20/Dec/12 ]

Fixing this for ee6 is not a priority.
However it will be done correctly for ee7.

Comment by Darious3 [ 20/Dec/12 ]

Romain, that is great news! Thanks!

It would be even better if it was done for Java EE 6 as well, but as EE 7 is the way forward anyway that's good enough for me.

If it isn't done for EE 6 though, shouldn't this issue be either closed or renamed?

Comment by Tom Mueller [ 07/Feb/13 ]

Reassigning to Romain since Ludo is no longer on the project.

Comment by aplossystems [ 28/Jun/13 ]

This has massively ruined my day. I'm moving from Glassfish and my JSF tutorial isn't printed out the bean value to the view. I just wanted to debug the FaceServlet init method to make sure it was being loaded. Normally a 10 second job but looks like it's going to be another few hours down the pan.

Comment by kithouna [ 26/Sep/13 ]

What's the status of this now that Java EE 7 has been released?

Comment by wsalembi [ 14/Mar/14 ]

Any chances that the source code will ever be released on the java maven repository?

http://download.java.net/maven/2/javax/javaee-api/6.0/
http://download.java.net/maven/2/javax/javaee-web-api/6.0/





[GLASSFISH-11252] zip bundles: uuid in cfg_cache should be removed Created: 04/Dec/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: ckamps Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: HTML File cfg_cache-after     HTML File cfg_cache-before    
Issuezilla Id: 11,252

 Description   

Using latest-glassfish.zip from Dec 3, the file
glassfishv3/.org.opensolaris,pkg/cfg_cache has uuid entries for each
publisher/repo, but it should not. The uuid = lines need to be removed from the
cfg_cache file prior to shipping the .zip file.

The uuids will be automatically generated by the pkg(5) tooling as those tools
are used to manage the installation.

Excluding the UUIDs from the pre-installed image is important because the UUIDs
enable us to report on unique installation instances. If the same UUIDs are
hardcoded across installations, then our reporting sees much fewer instances
than exist.

<SNIP>
...
[authority_stable.glassfish.org]
origin = http://pkg.glassfish.org/v3/stable/
ssl_key = None
ssl_cert = None
uuid = 24019f82-dfd5-11de-83d8-0003ba2efce4
repo.related_uris = []
...
</SNIP>



 Comments   
Comment by ckamps [ 04/Dec/09 ]

Confirmed that this issue is also present in the latest-web.zip file.

Comment by scatari [ 04/Dec/09 ]

Transferring to Snjezana for further evaluation.

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

I am confused. This is what distribution assembly document says:

"If you are using a universal image along with the pkg(5) Java Bootstrap
facility, then the publisher UUID will be reset automatically when the bootstrap
is executed. The Java Bootstrap facility also has an input value for determining
whether anonymous information should be sent to the server. If this is set, then
the send-uuid property will be set to true within the image. "

All GF zip files, both the standalone image and the one used for installer
payload are universal images, without bundled client. So, they would fall under
this section and shouldn't this mean that bootstrap overrides initial UUID
values. Did that change?

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

Created an attachment (id=4038)
Initial cfg_cache

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

Created an attachment (id=4039)
cfg_cache after client bootstrap

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

I'll take the liberty of closing this issue since I just verified that client
bootstrap still properly updates all initial UUID values. "Before" and "after"
cfg_cache files are being attached.

Comment by ckamps [ 04/Dec/09 ]

You are correct in that the bootstrap code will reset all of the UUIDs. Sorry
about that. This issue is not a P3 for that reason.

However, it's still a relevant issue in those cases where a user has multiple
images installed and is using tools from another image to manage the
non-bootstrapped image. In this case, the uuids won't get reset because the
bootstrap is never used. Lowering to a P4 because although the exposure is
less, it's still an issue.

This situation will become more common because we have numerous pkg(5) product
distributions with their own copies of pkg(5) tools: various versions of GF v3,
v3 bundled in various IDEs, Web Space, MQ, Web Stack, etc.

Since the Python pkg(5) code will set the uuid on all publishers when uuid = is
not present, it's actually a better practice to not include uuid = at all in the
pre-installed images. So when someone points Update Tool to an image that has
not been bootstrapped, that image will get new UUIDs when the uuid = lines are
not already present. If they're already present, the hardcoded factory UUIDs
will remain in effect.

Although the install image checklist already calls for removing the uuid =
settings, we'll update the Install Image Assemblers guide with this information.
Here's the checklist document:

http://wikis.sun.com/display/IpsBestPractices/Packaging+and+Install+Bundle+Checklist

Comment by Snjezana Sevo-Zenzerovic [ 04/Dec/09 ]

Very well. We'll take care of this in the trunk, setting target release to 3.1.

Comment by ckamps [ 05/Dec/09 ]

The plot thickens. Changing to RFE. Ironically, even if we wanted to modify the
GF cfg_cache to exclude the uuid = settings, it will not work. Until we make
some enhancements to how the Java API and bootstrap work, excluding uuid = in
the GF bundles installerless zip bundles is not feasible. Once the UC project
files an RFE to address some gaps on the UC side, we'll update this RFE with a
pointer to that issue.

Excluding uuid = in product bundles that don't make use of the pkg(5) Java API
apart from perhaps the initial bootstrap (e.g. Web Space, MQ, Web Stack, etc)
continues to be a recommended best practice because the pkg(5) Python API will
always automatically add the uuid settings.

Here's why excluding uuid = in the cfg_cache won't work with GF zip bundles today:

1) The bootstrap doesn't currently automatically add uuids when no uuid =
entries exist. It only resets uuid = entries when they exist. In the GF case,
this gap wouldn't matter that much because of the next aspect.

2) When start-domain is executed, the GF code uses the pkg(5) Java API to set
the uuids to the same value so as to align with the uuid used to identify and
potentially register the installation of GF. However, due to the behavior of
the Java API, it appears this setting only takes effect when the uuid = entries
already exist.

(I have not tested the installer-wrapped GF bundles to see how they would behave
with uuid = not present).

As a result of this investigation, the UC team is looking into enhancing the
bootstrap and pkg(5) Java API to better handle cases where uuid = is not present
at all.

Related issues:

1) Double uuids for same installation:

Given the behavior today where start-domain effectively resets the uuids a
second time for the same installation, our backend usage reporting is probably
counting more unique installations than actually exist. Perhaps this issue is
limited to the use of GF zip bundles. The UC team will look into the reporting
system impact.

2) Running bootstrap after start-domain overwrites sync'd uuids:

This is actually a very likely scenario:

  • User downloads zip and expands it.
  • User knows nothing about bin/updatetool and starts the domain.
  • During start-domain, uuids are set and sync'd.
  • Later on, user executes bin/updatetool which in turn executes the bootstrap.

At this point the bootstrap overwrites the sync'd up uuids as set via
start-domain. Another start-domain will sync the uuids again, but in the
meantime, a series of updates or installs may have occurred via the Update Tool
with the unsync'd uuids.

Comment by ckamps [ 05/Jan/10 ]

In the upcoming UC 2.3 Update 1 and 2.4 releases, the absence of "uuid ="
settings from the cfg_cache will result in UUIDs being automatically assigned or
assigned via the setAuthority() method of the Image.java class.

This means that this RFE to remove the factory UUIDs from the GF bundles can be
addressed in GF 3.1 as long as 2.3 U1 or greater of the toolkit pkg-client.jar
is used.

Here's the toolkit issue that was fixed:

https://updatecenter2.dev.java.net/issues/show_bug.cgi?id=1955

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-12676] Add additional package info metadata to GlassFish packages Created: 15/Jul/10  Updated: 10/Dec/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Snjezana Sevo-Zenzerovic Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,676

 Description   

Define additional package info metadata for 3.1 GlassFish packages as defined in
Best Practices:

https://wikis.oracle.com/display/IpsBestPractices/Packaging+Best+Practices+-+Additional+Package+Info



 Comments   
Comment by Nazrul [ 10/Dec/12 ]

This is an important but nice to have feature for GlassFish build infrastructure. We may work on this after all core infrastructure is in place.





[GLASSFISH-8720] pkg(5) toolkit packages need to be removed from community contrib repo Created: 14/Jul/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: ckamps Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-8502 GlassFish v3 Preview download has 'co... Resolved
Issuezilla Id: 8,720

 Description   

The following two repositories contain the pkg(5) toolkit packages, but they
should not be present. These packages need to be removed from these
repositories because attempting to maintain and update these packages in
addition to the packages in the appropriate release/, support/, etc repos adds
unnecessary cost and complexity. Additionally, if these packages are not
maintained and updated and a user happens to install the packages from these
contrib repos, they will never receive updates to them.

Here are the two contrib repos with these unnecessary packages:

http://pkg.glassfish.org/v3/contrib/
http://pkg.sun.com/glassfish/v3/contrib/

The packages are:

pkg
pkg-extra-tools
pkg-java
pkg-toolkit
python2.4-minimal
updatetool
wxpython2.8-minimal

WARNING: Since v3 Preview initially shipped with an incorrect preferred repo
setting (see the following issue), removal of the pkg(5) toolkit packages from
the pkg.glassfish.org/v3/contrib/ repo will cause failures under some
conditions. Those conditions will be documented here shortly.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=8502



 Comments   
Comment by ckamps [ 14/Jul/09 ]

I confirmed that the toolkit packages can be removed from the
pkg.sun.com/glassfish/v3/contrib/ because the v3 Preview points to the
pkg.glassfish.org/v3/contrib/ as its preferred repo. Consequently, cleaning up
pkg.sun.com/glassfish/v3/ should be feasible at this stage.

Comment by ckamps [ 07/Aug/09 ]

Splitting this issue into two because the pkg.sun.com contrib issue can be
addressed now while the community contrib issue will have to wait until later on.

Comment by ckamps [ 07/Aug/09 ]

This issue has been modified to focus only on the removal of the toolkit
packages from the community contrib repo.

A new issue has been filed to address removal of the toolkit packages from the
sun.com contrib repo:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=9067

Comment by kumara [ 01/Sep/09 ]

naman -> snjezana

Comment by Snjezana Sevo-Zenzerovic [ 15/Sep/09 ]

We'll remove these packages at FCS time since at that point we'll presumably
retire any support for Preview community distribution.

Comment by Snjezana Sevo-Zenzerovic [ 02/Nov/09 ]

Repository housekeeping task. Will be addressed after HCF.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-9332] SunPKCS11 initialization error w/ 64bit VM Created: 01/Sep/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: v2.1.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: eileeny Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: SunOS
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 9,332
Status Whiteboard:

v3_exclude,V2.1.1exclude


 Description   

Unable to start b30 with jdk1.6.0_16 64bit VM. start-domain fails with the
following error:

[#|2009-08-27T16:40:36.675-0700|SEVERE|sun-appserver2.1|javax.enterprise.system.
core.security|_ThreadID=10;_ThreadName=main;_RequestID=7f935454-876c-4018-8ed1-c
091c61adeb2;|SEC8001: Exception in initializing SunPKCS11.
java.lang.UnsatisfiedLinkError: /export/appservers/sjsas/lib/sparcv9/libnss3.so:
ld.so.1: java: fatal: /export/appservers/sjsas/lib/libnssutil3.so: wrong ELF cl
ass: ELFCLASS32
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at com.sun.enterprise.ee.security.NssStore.<clinit>(NssStore.java:100)
at com.sun.enterprise.ee.security.EESecuritySupportImpl.initNSS(EESecuri
tySupportImpl.java:151)
at com.sun.enterprise.ee.security.EESecuritySupportImpl.<init>(EESecurit
ySupportImpl.java:95)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at com.sun.enterprise.pluggable.PluggableFeatureFactoryBaseImpl.invoke(P
luggableFeatureFactoryBaseImpl.java:84)
at $Proxy0.getSecuritySupport(Unknown Source)
at com.sun.enterprise.security.SecurityUtil.getSecuritySupport(SecurityU
til.java:364)
at com.sun.enterprise.security.SSLUtils.<clinit>(SSLUtils.java:102)
at com.sun.enterprise.security.SecurityLifecycle.onInitialization(Securi
tyLifecycle.java:101)
at com.sun.enterprise.server.ApplicationServer.onInitialization(Applicat
ionServer.java:265)
at com.sun.enterprise.server.ondemand.OnDemandServer.onInitialization(On
DemandServer.java:103)
at com.sun.enterprise.server.PEMain.run(PEMain.java:399)
at com.sun.enterprise.server.PEMain.main(PEMain.java:336)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:415)

#]


 Comments   
Comment by kumarjayanti [ 03/Sep/09 ]

Hi,

Are you taking a Distribution of GlassFish that was built for 64 Bit ?. Can
you tell me where and how you obtained the GlassFish Server Instance.

Did you buy a 64 Bit GlassFish Enterprise server from Sun and then you see this
error ?. Or did Sun tell you that this Enterprise Server that you bought works
with 64 Bit VM. If so then it is a legitimate bug.

Otherwise you just need to make sure that the NSS shared libraries are 64 bit
compiled as well. The ones you are using are not 64 bit compiled.

You could get 64 bit NSS libraries for X86 systems here :
http://rpm.pbone.net/index.php3/stat/4/idpl/12386007/com/nss-3.12.2.0-4.el5.centos.x86_64.rpm.html

I am not sure where to get 64 bit NSS libraries for SOLARIS-SPARC.

Comment by meenap [ 22/Sep/09 ]

Tried 64bits JVM on GlassFish V2.1.1 B31b on Solaris 10 Sparc and was able to
reproduce this problem when starting domain1. This is on Enterprise Profile.

cat asadminenv.conf

  1. Copyright 2006 Sun Microsystems Inc. All rights reserved.
  2. Use is subject to license terms.
  3. Defines the defaults for the asadmin script. This file should only contain
    simple properties. Edit judiciously.
    AS_ADMIN_PORT=4848
    AS_ADMIN_PROFILE=enterprise
    AS_ADMIN_SECURE=true

[#|2009-09-22T12:37:37.313-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting
Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build
b31b-fcs) ...|#]

[#|2009-09-22T12:37:41.910-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;Java
HotSpot(TM) 64-Bit Server VM;1.6.0_16;Sun
Microsystems Inc.;|CORE5076: Using [Java HotSpot(TM) 64-Bit Server VM, Version
1.6.0_16] from [Sun Microsystems Inc.]|#]

[#|2009-09-22T12:37:42.314-0700|INFO|sun-appserver2.1|javax.enterprise.resource.jms|_ThreadID=11;_ThreadName=pool-1-thread-7;|Using
MQ RA for Broker lifecycle control|#]

[#|2009-09-22T12:37:42.359-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=12;_ThreadName=pool-1-thread-4;|SEC1001:
Security Manager
is ON.|#]

[#|2009-09-22T12:37:53.082-0700|SEVERE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;_RequestID=c1566bd0-d351-4033-8e4f-91bc3e8d1950;|SEC8001:
Exception in initializing SunPKCS11.
java.lang.UnsatisfiedLinkError: /export/home/appserver/lib/sparcv9/libnss3.so:
ld.so.1: java: fatal: /export/home/appserver/lib/libnssutil3.so: wrong ELF
class: ELFCLASS32
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at com.sun.enterprise.ee.security.NssStore.<clinit>(NssStore.java:100)
at
com.sun.enterprise.ee.security.EESecuritySupportImpl.initNSS(EESecuritySupportImpl.java:151)
at
com.sun.enterprise.ee.security.EESecuritySupportImpl.<init>(EESecuritySupportImpl.java:95)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at
com.sun.enterprise.pluggable.PluggableFeatureFactoryBaseImpl.invoke(PluggableFeatureFactoryBaseImpl.java:84)
at $Proxy0.getSecuritySupport(Unknown Source)
at
com.sun.enterprise.security.SecurityUtil.getSecuritySupport(SecurityUtil.java:364)
at com.sun.enterprise.security.SSLUtils.<clinit>(SSLUtils.java:102)
at
com.sun.enterprise.security.SecurityLifecycle.onInitialization(SecurityLifecycle.java:101)
at
com.sun.enterprise.server.ApplicationServer.onInitialization(ApplicationServer.java:265)
at
com.sun.enterprise.server.ondemand.OnDemandServer.onInitialization(OnDemandServer.java:103)
at com.sun.enterprise.server.PEMain.run(PEMain.java:399)
at com.sun.enterprise.server.PEMain.main(PEMain.java:336)
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.server.PELaunch.main(PELaunch.java:415)

#]
Comment by meenap [ 22/Sep/09 ]

Created an attachment (id=3261)
Server Log

Comment by Ed Bratt [ 22/Sep/09 ]

Changed Target Milestone to 2.1.1

Comment by kumarjayanti [ 22/Sep/09 ]

Yes ofcourse you will see this issue.

I have already stated and doing Google search for "wrong ELF class: ELFCLASS32"
will clearly tell you the reason.

You are using a 64 Bit VM and probably OS as well and trying to load a 32 bit
compiled NSS library : /export/home/appserver/lib/libnssutil3.so

I need to know the history of Enterprise Profile Testing with 64 Bit VM and
OSes. Did this combination ever work or is it being tested for the first time.
If it is a regression please clearly mention that in the Bug report.

Please note that the package of GlassFish Enterprise that you are using contains
a 32 bit compiled NSS. You will need to instead install 64 bit compiled NSS
libraries for Solaris for this to work.

I am changing the category of the bug to packaging. I am not aware if we ever
supported 64 bit NSS packaging in the history of GlassFish V2. Atleast i have
never heard about it ever since i took over the Security Module from Shing Wai.

Comment by eileeny [ 23/Sep/09 ]

This is a regression from b30 onward. The enterprise profile + 64 bit
combination has been a standard combination for performance testing and
successfully ran on b29 and earlier builds. Either the 64 bit NSS library is
now missing from the bundle or perhaps the security libraries are being loaded
differently.

Comment by kumarjayanti [ 23/Sep/09 ]

I am somewhat confident that the NSS library packaged is 32 bits based on the
error message.

The last change to code which loads the NSS library was 20 months ago, done by
Janey (something to do with AIX port).

So can you tell me how old is b29 and how old is b30.

http://fisheye5.cenqua.com/browse/glassfish/appserv-core-ee/appserv-core/src/java/com/sun/enterprise/ee/security/EESecuritySupportImpl.java#bSJSAS91_FCS_BRANCH

Branch SJSAS91_FCS_BRANCH :
------------------------------

1.4.6.1 annotated / raw | Diffs: previous, other | Lines: 335 ( +2, -0 )

Created: 2008-01-18 00:47:00 -0600 (20 months ago) | Author: janey | Changeset:
SJSAS91_FCS_BRANCH:janey:20080118064700
port AIX changes to 9.1.1

Branch point for: HA_STORE_SPI_BRANCH SAILFIN20_FCS_BRANCH SF20_MS1_BRANCH
SGES211_FCS_BRANCH SGES21_FCS_BRANCH SJSAS911_BETA_BRANCH

Tags: (hidden) show
------------------------------------

Comment by eileeny [ 23/Sep/09 ]

This is a regression from b30 onwards. Performance testing regularly tests with
64bit VM and enterprise profile and had no issues up to b29.

Comment by meenap [ 23/Sep/09 ]

Tried B29 with pointing to 64 Bits JDK1.6.0_16 and the default domain1 is
starting up fine, no issues there.

Version = Sun GlassFish Enterprise Server v2.1.1 (9.1.2) (build b29-fcs)
Command version executed successfully.

[#|2009-09-23T10:26:21.565-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;Java
HotSpot(TM) 64-Bit Server VM;1.6.0_16;Sun Microsystems Inc.;|CORE5076: Using
[Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_16] from [Sun Microsystems
Inc.]|#]

More details:
1) In B29, the bundled JDK in appserver is 1.5.0_20 and the bundled JDK in
appserver from B30 onwards is JDK1.6.0_16

2) B29 was promoted on 19th August and B30 was promoted on 26th August.

Comment by eileeny [ 23/Sep/09 ]

I was able to startup b30 w/ enterprise profile by setting AS_NSS=/usr/lib/mps.

I'm pretty sure it's a packaging error. In the solx86 install, two of the three
nss libraries in the lib/amd64 directory are 32bit libraries:
<web-x4100-7.74> pwd
/export/appservers/gfv211b30/lib/amd64
<web-x4100-7.70> file libnssckbi.so
libnssckbi.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked,
not stripped
<web-x4100-7.71> file libnss3.so
libnss3.so: ELF 32-bit LSB dynamic lib 80386 Version 1 [FPU], dynamically
linked, not stripped

Comment by eileeny [ 23/Sep/09 ]

Previous comment was regarding solx86 platform.

Problem is more complicated on solaris/sparc platform. All libraries in
$

{appserver_home}/lib/sparcv9 are 64bit, but 64bit libnss3.so is being linked to
32bit libnssutil3.so.

As a workaround, I can get the enterprise profile working on sparc if I set
AS_NSS=/usr/lib/mps in ${appserver_home}

/config/asenv.conf, and remove all the
files in $

{appserver_home}

/lib/sparcv9 that overlap with files in /usr/lib/mps.
AS_JAVA also needs to be set to jdk1.5.0 since the /usr/lib/mps libraries on
sparc do not work with jdk1.6.0.

Comment by kumarjayanti [ 24/Sep/09 ]

reassign

Comment by Snjezana Sevo-Zenzerovic [ 24/Sep/09 ]

Excluding from v3 bug list.

Comment by meenap [ 06/Oct/09 ]

Tried with B31d on Solaris 10 X86 with 64 Bits JDK1.6.0_16. Still seeing the
same startup issue.

[#|2009-10-06T15:37:15.964-0700|SEVERE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;_RequestID=2666d3da-c449-4c3c-ab01-55f334d0d700;|SEC8001:
Exception in initializing SunPKCS11.
java.lang.UnsatisfiedLinkError: /export/home/appserver/lib/amd64/libnss3.so:
ld.so.1: java: fatal: /export/home/appserver/lib/libnssutil3.so: wrong ELF
class: ELFCLASS32

The 64 bits libnss3.so file is being linked to 32 bits libnssutil3.so file
causing the above problem.

bigapp-xeon-2(aroot):lib/amd64 ->pwd
/export/home/appserver/lib/amd64
bigapp-xeon-2(aroot):lib/amd64 ->file libnss3.so
libnss3.so: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE CMOV],
dynamically linked, not stripped

bigapp-xeon-2(aroot):appserver/lib ->pwd
/export/home/appserver/lib
bigapp-xeon-2(aroot):appserver/lib ->file libnssutil3.so
libnssutil3.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked,
not stripped

I tried the workaround that Eileen mentioned here and modified the
/export/home/appserver/config/asenv.conf file of
AS_NSS="/usr/lib/mps"

After this, I was able to start the domain successfully.

Comment by meenap [ 06/Oct/09 ]

Tried B31d on Solaris 10 Spsrc and same issue is seen as in Sol X86 above.

[#|2009-10-06T16:24:54.877-0700|SEVERE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;_RequestID=49015535-32fa-453f-a4f4-6c9245e60d9f;|SEC8001:
Exception in initializing SunPKCS11.
java.lang.UnsatisfiedLinkError: /export/home/appserver/lib/sparcv9/libnss3.so:
ld.so.1: java: fatal: /export/home/appserver/lib/libnssutil3.so: wrong ELF
class: ELFCLASS32

bigapp-niagara-1(aroot):appserver/bin ->file
/export/home/appserver/lib/sparcv9/libnss3.so
/export/home/appserver/lib/sparcv9/libnss3.so: ELF 64-bit MSB dynamic lib
SPARCV9 Version 1, dynamically linked, not stripped

bigapp-niagara-1(aroot):appserver/bin ->file
/export/home/appserver/lib/libnssutil3.so
/export/home/appserver/lib/libnssutil3.so: ELF 32-bit MSB dynamic lib SPARC
Version 1, dynamically linked, not stripped

With workaround of pointing AS_NSS="/usr/lib/mps" and AS_NSS_BIN="/usr/lib/mps"
in asenv.conf file, I am still not able to start the domain. So the workaround
is not working on Solaris Sparc.

Found the following existing in this installation:

./export/home/appserver/imq/lib/sparcv9/libnssutil3.so
./export/home/appserver/imq/lib/libnssutil3.so
./export/home/appserver/lib/libnssutil3.so

bigapp-niagara-1(aroot):~ ->file
/export/home/appserver/imq/lib/sparcv9/libnssutil3.so
/export/home/appserver/imq/lib/sparcv9/libnssutil3.so: ELF 64-bit MSB dynamic
lib SPARCV9 Version 1, dynamically linked, not stripped

bigapp-niagara-1(aroot):~ ->file /export/home/appserver/imq/lib/libnssutil3.so
/export/home/appserver/imq/lib/libnssutil3.so: ELF 32-bit MSB dynamic lib SPARC
Version 1, dynamically linked, not stripped

bigapp-niagara-1(aroot):~ ->file /export/home/appserver/lib/libnssutil3.so
/export/home/appserver/lib/libnssutil3.so: ELF 32-bit MSB dynamic lib SPARC
Version 1, dynamically linked, not stripped

I don't see libnssutil3.so for 64-bit packaged in the build under lib directory
just like the imq directory. I am not sure if this is supposed to be packaged
and is missing in the build.

Comment by coding [ 08/Oct/09 ]
      • Issue 9332 has been confirmed by votes. ***
Comment by meenap [ 09/Oct/09 ]

Picked up the nightly build from:
/net/koori.sfbay/n/v02/glassfish_branch2.1.1/bundles/b31f-2009-10-08.

Did a quick test on Solaris Sparc and Solaris X86 by testing the start domain.

Sparc
*******
bigapp-niagara-1(aroot):appserver/lib ->pwd
/export/home/appserver/lib

bigapp-niagara-1(aroot):appserver/lib ->ls -l nss
rw-rr- 1 root root 26032 Oct 9 10:19 libasnss.so
rw-rr- 1 root root 1768100 Oct 9 10:19 libnss3.so
rw-rr- 1 root root 506776 Oct 9 10:19 libnssckbi.so
rw-rr- 1 root root 252620 Oct 9 10:19 libnssdbm3.so
rw-rr- 1 root root 176880 Oct 9 10:19 libnssutil3.so

bigapp-niagara-1(aroot):lib/sparcv9 ->pwd
/export/home/appserver/lib/sparcv9

bigapp-niagara-1(aroot):lib/sparcv9 ->ls -l nss
rw-rr- 1 root root 41504 Oct 9 10:19 libasnss.so
rw-rr- 1 root root 1849232 Oct 9 10:19 libnss3.so
rw-rr- 1 root root 622712 Oct 9 10:19 libnssckbi.so
rw-rr- 1 root root 275312 Oct 9 10:19 libnssdbm3.so
rw-rr- 1 root root 209904 Oct 9 10:19 libnssutil3.so

start
[#|2009-10-09T10:31:50.095-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting
Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build
b31f-fcs) ...|#]

[#|2009-10-09T10:31:54.717-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;Java
HotSpot(TM) 64-Bit Server VM;1.6.0_16;Sun
Microsystems Inc.;|CORE5076: Using [Java HotSpot(TM) 64-Bit Server VM, Version
1.6.0_16] from [Sun Microsystems Inc.]|#]

..............................

[#|2009-10-09T10:32:52.850-0700|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=10;_ThreadName=main;_RequestID=02b664d6-69b9-4369-b650-830e111589eb;|EJBLifeCycle:
Automatic timer migration component not enabled for DAS instance|#]

[#|2009-10-09T10:32:53.111-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Application
server startup complete.|#]

Domain started up successfully with 64 Bits JDK1.6.0_16 on Sparc.

X86
******

bigapp-xeon-2(aroot):appserver/lib ->pwd
/export/home/appserver/lib

bigapp-xeon-2(aroot):appserver/lib ->ls -l nss
rw-rr- 1 root root 24676 Oct 9 10:20 libasnss.so
rw-rr- 1 root root 2427148 Oct 9 10:21 libnss3.so
rw-rr- 1 root root 490276 Oct 9 10:21 libnssckbi.so
rw-rr- 1 root root 360444 Oct 9 10:21 libnssdbm3.so
rw-rr- 1 root root 195180 Oct 9 10:21 libnssutil3.so

bigapp-xeon-2(aroot):lib/amd64 ->pwd
/export/home/appserver/lib/amd64

bigapp-xeon-2(aroot):lib/amd64 ->ls -l nss
rw-rr- 1 root root 28936 Oct 9 10:20 libasnss.so
rw-rr- 1 root root 2668376 Oct 9 10:21 libnss3.so
rw-rr- 1 root root 638576 Oct 9 10:21 libnssckbi.so
rw-rr- 1 root root 418312 Oct 9 10:21 libnssdbm3.so
rw-rr- 1 root root 246816 Oct 9 10:21 libnssutil3.so

start
[#|2009-10-09T10:33:50.828-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting
Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build
b31f-fcs) ...|#]

[#|2009-10-09T10:33:51.610-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;Java
HotSpot(TM) 64-Bit Server VM;1.6.0_16;Sun
Microsystems Inc.;|CORE5076: Using [Java HotSpot(TM) 64-Bit Server VM, Version
1.6.0_16] from [Sun Microsystems Inc.]|#]

.......................................

[#|2009-10-09T10:34:01.682-0700|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=10;_ThreadName=main;_RequestID=3989c62d-e2f8-44d8-96f9-4bab8f61cd3b;|EJBLifeCycle:
Automatic timer migration component not enabled for DAS instance|#]

[#|2009-10-09T10:34:01.729-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Application
server startup complete.|#]

Domain started up successfully with 64 Bits JDK1.6.0_16 on X86

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6782] Do not bundle JavaDB Created: 15/Nov/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: mkarg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,782

 Description   

Java SE 6 comes bundles with Java DB.
GlassFish v3 Prelude comes bundled with Java DB.
From the administrator's view it makes no sense to have twice the binaries.
Would be great to share a single Java DB installation.
At least of Microsoft Windows this is easy: Split the Java DB installation out
of the Java SE / GF installer and make it it's own product. So Windows will know
that there is a single "central" Java DB installation. Then tell Java SE's /
GlassFish's installer that it is dependent of this central installation. If it
is not there, add it to the central place. If it already is there, but has an
older version, add the new version. If it is already there but has the same or
later version, do not add your own version. It sounds just so simple, so why not
doing it?



 Comments   
Comment by naman_mehta [ 25/May/10 ]

Please assign this to appropriate owner.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6573] Tweaks for pkg.summary / pkg.description: glassfish-* pkgs Created: 17/Oct/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Joe Di Pol Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 6,573

 Description   

Generally, packages that start with "glassfish-" should probably
have Summaries that start with "GlassFish" to provide some degree
of consistency and grouping in the Update Tool GUI when the Component
list is sorted by the summary.

Here are some specific suggestions...

glassfish-branding-gui
pkg.summary:
Existing: Administration Console theme created by Sun Microsystems Inc.
Proposed: GlassFish Sun Theme

pkg.description:
Remove boilerplate taken from glassfish-gui and just say:
"Extensions to the GlassFish Administration Console including the
Sun Microsystems theme"

felix:
pkg.summary:
Existing: Apache Felix
Proposed: Apache Felix for GlassFish

glassfish-branding
pkg.summary:
Existing: GlassFish Nucleus extensions created by Sun Microsystems Inc.
Proposed: GlassFish Nucleus Sun extensions

glassfish-grizzly
pkg.summary:
Existing: Grizzly NIO Framework
Proposed: GlassFish Grizzly NIO Framework

glassfish-hk2
pkg.summary:
Existing: HK2
Proposed: GlassFish Kernel

glassfish-corba-omgapi
pkg.summary:
Existing: OMG CORBA APIs for GlassFish
Proposed: GlassFish OMG CORBA APIs

glassfish-api:
pkg.description doesn't describe what's in pacakge. It
just has the GlassFish boiler plate.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 17/Oct/08 ]

...

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6306] hard-coded version for glassfish-corba-omgapi package Created: 25/Sep/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: janey Assignee: janey
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,306
Status Whiteboard:

gfv3-prelude-excluded


 Description   

The package, glassfish-corba-omgapi used to have the version in the name of the
jar file (e.g. glassfish-corba-omgapi-3.0.0-b001.jar) where 3.0.0 is the version
and b001 is the build. During IPS packaging, the version is retrieved from the
jar filename. This was the fix to IT 5910. Recently the version is removed
from glassfish-corba-omgapi so IPS packaging is broken for this package since
it's unable to retrieve the version.

For now, I'm hard-coding the version in a packaging file which is written in
python.



 Comments   
Comment by janey [ 25/Sep/08 ]

post-prelude work

Comment by janey [ 25/Sep/08 ]

update summary

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4540] Glassfish linux bundle doesn't come with asnss library compiled for amd64 Created: 29/Mar/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: lkishalmi Assignee: lkishalmi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 4,540

 Description   

This issue causes that the Application server cannot be started with Enterprise
profile on amd64 linuxes. A possible workaround is to use 32 bit JVM and install
the required 32 bit libraries under Linux, but what happens if an application
inside the appserver really needs a heap space over 3GB (AFAIK that's the
maximum heapsize can be addressable by 32 bit JVM on linux)



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by naman_mehta [ 25/May/10 ]

Please assign this to appropriate owner.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4395] Include Readme on how to start GF Created: 07/Mar/08  Updated: 06/Jan/11

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: v2.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: harpreet Assignee: dpatil
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,395
Status Whiteboard:

as911-na


 Description   

Include a Readme file in the distro that lists out steps to start the AS.



 Comments   
Comment by harpreet [ 07/Mar/08 ]

Filed issue for Eduardo - and approving it for 9.1.1

Comment by harpreet [ 02/Oct/08 ]

Not critical to v2.1. Moving to next release.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.





[GLASSFISH-6166] Add build number to javadb and felix IPS packages Created: 19/Sep/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: tcfujii Assignee: janey
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,166

 Description   

The felix and javadb IPS packages don't have a "build number" as part of their
names so it makes it very hard to determine which v3 build this came from:

pkg:/felix@1.0.4,0-0:20080830T023728Z
pkg:/felix@1.0.4,0-0:20080912T095249Z
pkg:/felix@1.0.4,0-0:20080820T134004Z

pkg:/javadb@10.2.2.1,0-0:20080830T025219Z
pkg:/javadb@10.2.2.1,0-0:20080820T134239Z
pkg:/javadb@10.2.2.1,0-0:20080913T095808Z
pkg:/javadb@10.2.2.1,0-0:20080906T095947Z

Would it be possible to add the build number in? Here's an example of the
glassfish-ejp IPS package for builds 19 through 21:

pkg:/glassfish-ejb@3.0,0-19:20080817T020328Z
pkg:/glassfish-ejb@3.0,0-20:20080820T134230Z
pkg:/glassfish-ejb@3.0,0-21:20080828T214650Z



 Comments   
Comment by tcfujii [ 19/Sep/08 ]

It looks like the corba packages are not including the build number as well
(started 9/16/2008). Could we add that back in, too?

Comment by marina vatkina [ 23/Sep/08 ]

Corba package doesn't change, I suspect others don't as well. Why do we need to
have separate packages? Can IPS be smart enough not to republish packages with
teh same number?

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5177] platform bundles have unnecessary files Created: 18/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: scatari Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,177
Status Whiteboard:

gfv3-prelude-included


 Description   

The following issues applie to V3 TP2 refresh distribution.

1). The installer bundles on unix platforms(self-extracting shell files) have "setup.exe" included them.
setup.exe is windows specific and is of no-use in non-windows platforms, hence should be removed.

2). Upon installation on unix platforms, windows specific binaries(*.bat) are installed under
<InstallDir>/glassfish/bin.

3). Upon installation on windows platform, unix specific binaries(asadmin, startserv, stopserv) are
present under <InstallDir>/glassfish/bin.

If packaging cannot be done per plaform, then files listed under 2) and 3) should be removed post-
installation.



 Comments   
Comment by kumara [ 19/Aug/08 ]

Add gfv3-prelude-include to status whiteboard

Comment by scatari [ 20/Aug/08 ]

Downgrading to a p4 as these files are harmless and does not affect the
functionality in anyway.

Comment by kumara [ 03/Sep/08 ]

v3 defect tracking

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2166] <BT6495864>Java DMK jars should be available in PE installer Created: 20/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gfbugbridge Assignee: ss144236
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,166

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6495864
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6495864
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description We have to make this happen.When I install PE, I don't get the jdmkrt.jar that is
part of JDMK. This used to be part of EE installation.
Now, it has to be a part of PE as well.

Note that this has to be handled as a separate zip file
and can not be put in one of our packages, as it is not
our code.

This is required for MS3 because without it, PE installer
won't have the "cluster profile", because DAS won't start
without this jar, when we create domain with cluster profile.

Kedar

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation I have added the jdmkrt.jar in the SUNWasu package. It has been agreed that we need to change the way the jdmk.jar is made available to the installer.We need :
1. A staging location for the jdmk jar files
2. A bootstrapping mechanism that will allow us to bootstrap a specific version ( specified in bootstrap.properties)
3. creation of jdmk.zip

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [2-High]In order to support the single binary
and cluster profile on PE installer,
this is a XXXXXX 2006-11-21 01:08:51 GMT

Priority changed from [2-High] to [3-Medium]
Lowering this to a P3 , so that this can be fixed later before XXXXXX 2007-01-17 12:21:57 GMT

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Suggested Fix Checking in SVR4PackageDefToFileList.xml;/m/jws/packager/packages/SUNWasu/SVR4PackageDefToFileList.xml,v <-- SVR4PackageDefToFileList.xml
new revision: 1.41; previous revision: 1.40
done

**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by gfbugbridge [ 24/Jan/07 ]

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6495864
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6495864
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description We have to make this happen.When I install PE, I don't get the jdmkrt.jar that is
part of JDMK. This used to be part of EE installation.
Now, it has to be a part of PE as well.

Note that this has to be handled as a separate zip file
and can not be put in one of our packages, as it is not
our code.

This is required for MS3 because without it, PE installer
won't have the "cluster profile", because DAS won't start
without this jar, when we create domain with cluster profile.

Kedar

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation I have added the jdmkrt.jar in the SUNWasu package. It has been agreed that we need to change the way the jdmk.jar is made available to the installer.We need :
1. A staging location for the jdmk jar files
2. A bootstrapping mechanism that will allow us to bootstrap a specific version ( specified in bootstrap.properties)
3. creation of jdmk.zip

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [2-High]In order to support the single binary
and cluster profile on PE installer,
this is a XXXXXX 2006-11-21 01:08:51 GMT

Priority changed from [2-High] to [3-Medium]
Lowering this to a P3 , so that this can be fixed later before XXXXXX 2007-01-17 12:21:57 GMT

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Suggested Fix Checking in SVR4PackageDefToFileList.xml;/m/jws/packager/packages/SUNWasu/SVR4PackageDefToFileList.xml,v <-- SVR4PackageDefToFileList.xml
new revision: 1.41; previous revision: 1.40
done

**********READ-ONLY Data from Bugtraq Ends********

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-16734] [Blocking] Unable to update a GF Server 3.0.1 full distribution to 3.0.1.1 from Support Repository - Package Violation Constraint Created: 25/May/11  Updated: 20/Jun/11

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Pineda Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP, Installation of glassfish-3.0.1-b22-unix.sh, Support Repository https://pkg.oracle.com/glassfish/v3/support, update to 3.0.1 patch 1 version, Firefox browser 3.6.17


Tags: 3_1_1-scrubbed

 Description   

The problem is seen on a community installation of GlassFish Server 3.0.1 and the attempt to Update it through the Oracle Support repository and to version Oracle GF Server 3.0.1 patch1. After installation, the system is configured as follows:

  • cd <GlassFish_Installation>
  • bin/pkg set-publisher -P -k $HOME/Oracle_Glassfish_Server_3_Support.key.pem\
    -c $HOME/Oracle_Glassfish_Server_3_Support.certificate.pem\
    -O https://pkg.oracle.com/glassfish/v3/support release.glassfish.oracle.com

During the update, the following error is reported:
C:\glassfishv3\bin>pkg install glassfish-full-incorporation@3.0.1.1 glassfish-enterprise-full-profile@3.0.1.1
Creating Plan -
pkg: The following package(s) violated constraints:
Package pkg:/mq-server@4.5,5.11 conflicts with constraint in installed p
kg:/glassfish-full-incorporation:
Pkg mq-server: Optional min_version: 4.4,5.11 max version: 4.4,5
.11 defined by: pkg:/glassfish-full-incorporation

the process stops the Update is not performed.

This problem is not seen when Updating from an Oracle GF server 3.0.1 distribution. Only with the community bits (glassfish-3.0.1-b22-unix.sh).



 Comments   
Comment by scatari [ 06/Jun/11 ]

Issue not in 3.1.1.

Comment by scatari [ 20/Jun/11 ]

Issue with upgrading 3.0.1 - 3.0.1.1 relatively old versions of GlassFish.





[GLASSFISH-16733] [Blocking] Unable to update a 3.0.1 community web profile installation to 3.0.1.1 using Support Repository Created: 25/May/11  Updated: 20/Jun/11

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1.1_b05
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Alex Pineda Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOS 10.6.7, Installation of glassfish-3.0.1-web-b22-unix.sh, Support Repository https://pkg.oracle.com/glassfish/v3/support, update to 3.0.1 patch 1 version, Firefox browser 3.6.17


Tags: 3_1_1-scrubbed

 Description   

The problem is seen on a community installation of GlassFish Server 3.0.1 and the attempt to Update it through the Oracle Support repository and to version Oracle GF Server 3.0.1 patch1.

On the 3.0.1 installation, the following packages versions are on the system:
NAME (PUBLISHER) VERSION STATE UFIX
felix 2.0.2-0 installed u---
glassfish-branding 3.0.1-22 installed u---
glassfish-branding-gui 3.0.1-22 installed u---
glassfish-common 3.0.1-22 installed u---
glassfish-corba-base 3.0.0-41 installed u---
glassfish-ejb-lite 3.0.1-22 installed u---
glassfish-enterprise-web-profile 3.0.1-22 installed u---
glassfish-grizzly 1.9.18-10 installed u---
glassfish-grizzly-full 1.9.18-10 installed u---
glassfish-gui 3.0.1-22 installed u---
glassfish-hk2 3.0.1-22 installed u---
glassfish-javahelp 2.0.2-0 installed u---
glassfish-jca 3.0.1-22 installed u---
glassfish-jcdi 3.0.1-22 installed u---
glassfish-jdbc 3.0.1-22 installed u---
glassfish-jpa 3.0.1-22 installed u---
glassfish-jsf 2.0.2-10 installed u---
glassfish-jta 3.0.1-22 installed u---
glassfish-jts 3.0.1-22 installed u---
glassfish-management 3.0.1-22 installed u---
glassfish-monitoring-scripting-client 3.0-0 installed u---
glassfish-nucleus 3.0.1-22 installed u---
glassfish-registration 3.0.1-22 installed u---
glassfish-scripting 3.0.1-22 installed u---
glassfish-upgrade 3.0.1-22 installed u---
glassfish-web 3.0.1-22 installed u---
glassfish-web-incorporation 3.0.1-22 installed u---
glassfish-web-profile 3.0.1-22 installed u---
javadb-client 10.5.3.0-1 installed u---
javadb-common 10.5.3.0-1 installed u---
javadb-core 10.5.3.0-1 installed u---
jersey 1.1.5-1.0 installed u---

The next step is to configure the system for the update as follows:

  • cd <GlassFish_Installation>
  • bin/pkg set-publisher -P -k $HOME/Oracle_Glassfish_Server_3_Support.key.pem\
    -c $HOME/Oracle_Glassfish_Server_3_Support.certificate.pem\
    -O https://pkg.oracle.com/glassfish/v3/support release.glassfish.oracle.com

The next step is to do the update as follows:

  • bin/pkg install glassfish-web-incorporation@3.0.1.1 glassfish-enterprise-web-profile@3.0.1.1

When I check the system, I see the packages updated to:
NAME (PUBLISHER) VERSION STATE UFIX
felix (stable.glassfish.org) 2.0.2-0 installed u---
glassfish-branding 3.1-43 installed ----
glassfish-branding-gui 3.1-43 installed ----
glassfish-common 3.0.1.1-1 installed u---
glassfish-corba-base (stable.glassfish.org) 3.0.0-41 installed u---
glassfish-ejb-lite 3.0.1.1-1 installed u---
glassfish-enterprise-web-profile 3.0.1.1-1 installed u---
glassfish-grizzly (stable.glassfish.org) 1.9.18-10 installed u---
glassfish-grizzly-full (stable.glassfish.org) 1.9.18-10 installed u---
glassfish-gui 3.0.1.1-1 installed u---
glassfish-hk2 3.0.1.1-1 installed u---
glassfish-javahelp (stable.glassfish.org) 2.0.2-0 installed u---
glassfish-jca 3.0.1.1-1 installed u---
glassfish-jcdi 3.0.1.1-1 installed u---
glassfish-jdbc 3.0.1.1-1 installed u---
glassfish-jpa 3.0.1.1-1 installed u---
glassfish-jsf 2.0.3-5 installed u---
glassfish-jta 3.0.1.1-1 installed u---
glassfish-jts 3.0.1.1-1 installed u---
glassfish-management 3.0.1.1-1 installed u---
glassfish-monitoring-scripting-client 3.1-43 installed ----
glassfish-nucleus 3.0.1.1-1 installed u---
glassfish-registration 3.0.1.1-1 installed u---
glassfish-scripting 3.0.1.1-1 installed u---
glassfish-upgrade 3.0.1.1-1 installed u---
glassfish-web 3.0.1.1-1 installed u---
glassfish-web-incorporation 3.0.1.1-1 installed u---
glassfish-web-profile (stable.glassfish.org) 3.0.1-22 installed u---
javadb-client (stable.glassfish.org) 10.5.3.0-1 installed u---
javadb-common (stable.glassfish.org) 10.5.3.0-1 installed u---
javadb-core (stable.glassfish.org) 10.5.3.0-1 installed u---
jersey (stable.glassfish.org) 1.1.5-1.0 installed u---
pkg (stable.glassfish.org) 1.122.2-53.2825 installed ----
pkg-java (stable.glassfish.org) 1.122-53.2825 installed ----
pkg-toolkit-incorporation (stable.glassfish.org) 2.3.4-53.2825 installed ----
python2.4-minimal (stable.glassfish.org) 2.4.5.0-53.2825 installed ----
updatetool (stable.glassfish.org) 2.3.4-53.2825 installed ----
wxpython2.8-minimal (stable.glassfish.org) 2.8.10.1-53.2825 installed ----

Note that 2 packages are updated to the latest version (3.1) which are:
NAME (PUBLISHER) VERSION STATE UFIX
glassfish-branding 3.1-43 installed ----
glassfish-branding-gui 3.1-43 installed ----

After I start the server and when I try to bring up the AdminConsole, the following exception is seen in the server.log file and the console does not come up on the browser:
[#|2011-05-25T15:48:37.080-0700|SEVERE|oracle-glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=23;_ThreadName=Thread-3;|com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [75] State [INSTALLED] [com.sun.glassfish.admingui.console-custom-branding-plugin(Admin Console Custom Plugin):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.fetch(LazyInhabitant.java:91)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:106)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at com.sun.enterprise.v3.server.ClassLoaderHierarchyImpl.createApplicationParentCL(ClassLoaderHierarchyImpl.java:197)
at org.glassfish.deployment.common.DeploymentContextImpl.createClassLoader(DeploymentContextImpl.java:192)
at org.glassfish.deployment.common.DeploymentContextImpl.createDeploymentClassLoader(DeploymentContextImpl.java:177)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:248)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:362)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:292)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle com.sun.glassfish.admingui.console-custom-branding-plugin [75]: package; (&(package=org.glassfish.api.admingui)(version>=3.1.0))
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1597)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:166)
... 11 more



 Comments   
Comment by Alex Pineda [ 25/May/11 ]

If I install Oracle Glassfish Server 3.0.1 version (ogs-3.0.1-web-b22-unix.sh*), the AdminConsole comes up without any problem and package update appears to be correct as it shows the following:

NAME (PUBLISHER) VERSION STATE UFIX
felix (release.glassfish.sun.com) 2.0.2-0 installed u---
glassfish-branding (release.glassfish.sun.com) 3.0.1-22 installed u---
glassfish-branding-gui (release.glassfish.sun.com) 3.0.1-22 installed u---
glassfish-common 3.0.1.1-1 installed u---
glassfish-corba-base (release.glassfish.sun.com) 3.0.0-41 installed u---
glassfish-ejb-lite 3.0.1.1-1 installed u---
glassfish-enterprise-web-profile 3.0.1.1-1 installed u---
glassfish-grizzly (release.glassfish.sun.com) 1.9.18-10 installed u---
glassfish-grizzly-full (release.glassfish.sun.com) 1.9.18-10 installed u---
glassfish-gui 3.0.1.1-1 installed u---
glassfish-hk2 3.0.1.1-1 installed u---
glassfish-javahelp (release.glassfish.sun.com) 2.0.2-0 installed u---
glassfish-jca 3.0.1.1-1 installed u---
glassfish-jcdi 3.0.1.1-1 installed u---
glassfish-jdbc 3.0.1.1-1 installed u---
glassfish-jpa 3.0.1.1-1 installed u---
glassfish-jsf 2.0.3-5 installed u---
glassfish-jta 3.0.1.1-1 installed u---
glassfish-jts 3.0.1.1-1 installed u---
glassfish-management 3.0.1.1-1 installed u---
glassfish-monitoring-scripting-client (release.glassfish.sun.com) 3.0-0 installed u---
glassfish-nucleus 3.0.1.1-1 installed u---
glassfish-registration 3.0.1.1-1 installed u---
glassfish-scripting 3.0.1.1-1 installed u---
glassfish-upgrade 3.0.1.1-1 installed u---
glassfish-web 3.0.1.1-1 installed u---
glassfish-web-incorporation 3.0.1.1-1 installed u---
glassfish-web-profile (release.glassfish.sun.com) 3.0.1-22 installed u---
javadb-client (release.glassfish.sun.com) 10.5.3.0-1 installed u---
javadb-common (release.glassfish.sun.com) 10.5.3.0-1 installed u---
javadb-core (release.glassfish.sun.com) 10.5.3.0-1 installed u---
jersey (release.glassfish.sun.com) 1.1.5-1.0 installed u---

Note that are no 3.1 version of the packages. This appears to imply that the issue is between an upgrade of community bits to customer bits.

Comment by scatari [ 06/Jun/11 ]

Doesn't apply to 3.1.1.

Comment by scatari [ 20/Jun/11 ]

Bug affects a much earlier version of GlassFish.





[GLASSFISH-21226] Java EE 6 API in the Maven repository has an incorrect method. Created: 08/Oct/14  Updated: 27/Feb/15

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: kazssym Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 7 (x64)
Java: JDK 8, Java(TM) SE Runtime Environment 1.8.0_11-b12
IDE: Netbeans IDE 8.0.1


Issue Links:
Relates
relates to GLASSFISH-11389 javax:javaee-api:6.0 and javax.jvaee-... Open

 Description   

I am not sure you are responsible to correct the error, but the Java EE 6 API registered in the Mave repository has an incorrect method in interface javax.enterprise.inject.spi.BeforeBeanDiscovery. It is specified in the API document to have the following method:

void addInterceptorBinding(java.lang.Class<? extends java.lang.annotation.Annotation> bindingType, java.lang.annotation.Annotation... bindingTypeDef)

But the one from the Mave repository has this one instead:

void addInterceptorBinding(Class<? extends Annotation> type)

This may cause false compilation errors in some programs. It should be updated to match the API document..



 Comments   
Comment by Romain Grécourt [ 08/Oct/14 ]

There is no "javadoc" artifact for the official EE6 API maven artifact: javax.javaee:javaee-api:6.0.
Can you please provide maven coordinates for these artifacts (include the so-called API document)?

Comment by kazssym [ 08/Oct/14 ]

The API document at http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeforeBeanDiscovery.html#addInterceptorBinding(java.lang.Class,%20java.lang.annotation.Annotation...) describes the former is correct and one of projects I have fails with the javaee-api 6.0 dependency. To make it builds successful, I must add another dependency on cdi-api 1.0-SP4 to override the interface definition in javaee-api 6.0. AFAIK, the Java EE 6 API includes the CDI 1.0 specification, doesn't it?

Comment by Romain Grécourt [ 09/Oct/14 ]

cdi-1.0 (javax.enterprise:cdi-api:1.0:jar) is what is included in the javaee6 api jar:

> javap -cp ./javaee-api-6.0.jar javax.enterprise.inject.spi.BeforeBeanDiscovery

public interface javax.enterprise.inject.spi.BeforeBeanDiscovery {
  public abstract void addQualifier(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addScope(java.lang.Class<? extends java.lang.annotation.Annotation>, boolean, boolean);
  public abstract void addStereotype(java.lang.Class<? extends java.lang.annotation.Annotation>, java.lang.annotation.Annotation...);
  public abstract void addInterceptorBinding(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addAnnotatedType(javax.enterprise.inject.spi.AnnotatedType<?>);
}

> javap -cp ./cdi-api-1.0.jar javax.enterprise.inject.spi.BeforeBeanDiscovery

public interface javax.enterprise.inject.spi.BeforeBeanDiscovery {
  public abstract void addQualifier(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addScope(java.lang.Class<? extends java.lang.annotation.Annotation>, boolean, boolean);
  public abstract void addStereotype(java.lang.Class<? extends java.lang.annotation.Annotation>, java.lang.annotation.Annotation...);
  public abstract void addInterceptorBinding(java.lang.Class<? extends java.lang.annotation.Annotation>);
  public abstract void addAnnotatedType(javax.enterprise.inject.spi.AnnotatedType<?>);
}

However, there is indeed a discrepancy between the official javadoc and the API artifact (javax.javaee:javaee-api:6.0:jar).
I will follow-up on that.

Comment by Romain Grécourt [ 27/Feb/15 ]

linking to GLASSFISH-11389 as this will require an update to the EE6 combined maven artifacts.





[GLASSFISH-779] <BT6409705>copy indexStandAlone.html as index.html in SUNWasu package Created: 26/Jun/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gfbugbridge Assignee: ss144236
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 779

 Description   

<Note> Comments changing the target release to 9.0 UR1 as suggested by Jerome.</Note><Note> Comments This does not affect file-based PE.</Note><Note> Description copy samples/indexStandAlone.html as samples/index.html in SUNWasu package.</Note><Note> Description The change needs to be included in both the mainline and fcs branch of 9.0.</Note><Note> Evaluation need to copy the indexStandAlone.html as index.html before creating the packages. This is currently being done by the file based installer. The native package based installation will not have the proper index.html.</Note><Note> Justification Priority changed from [] to [2-High]needs to be fixedvishwas.bhariXXX 2006-04-06 13:55:00 GMTinstaller perfoms the required operation and file based install are not impacted.jerome.dochezXXX 2006-04-14 21:01:27 GMT</Note><Note> Suggested Fix Index: publish.xml===================================================================RCS file: /m/jws/packager/publish.xml,vretrieving revision 1.151.2.1diff u -r1.151.2.1 publish.xml-- publish.xml 6 Apr 2006 13:19:41 -0000 1.151.2.1+++ publish.xml 6 Apr 2006 13:52:12 -0000@@ -1094,6 +1094,9 @@ todir="$

{glassfish.home}" overwrite="true" /> <copy file="${appserv.legalnotice}" todir="${glassfish.home}

" overwrite="true" />+ <echo message="Copying samples/indexStandAlone.html to samples/index.html"/>+ <copy file="$

{glassfish.home}/samples/indexStandAlone.html"+ tofile="${glassfish.home}

/samples/index.html" overwrite="true"/> </target></Note>



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Mon Sep 26 17:02:19 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.