<< Back to previous view

[GLASSFISH-19363] GF fails to start on jdk8 Created: 22/Nov/12  Updated: 22/Nov/12  Resolved: 22/Nov/12

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b63
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Sanjeeb Sahoo

 Description   

ss141213@Sahoo:~/software/fmw$ ~/software/jdk1.8.0/bin/java -jar /space/ss141213/WS/gf/v3/appserver/distributions/glassfish/target/stage/glassfish3/glassfish/modules/glassfish.jar
Launching GlassFish on Felix platform
ERROR: Error parsing system bundle export statement: org.osgi.framework; version=1.6.0, org.osgi.framework.launch; version=1.0.0, org.osgi.framework.wiring; version=1.0.0, org.osgi.framework.startlevel; version=1.0.0, org.osgi.framework.hooks.bundle; version=1.0.0, org.osgi.framework.hooks.resolver; version=1.0.0, org.osgi.framework.hooks.service; version=1.1.0, org.osgi.framework.hooks.weaving; version=1.0.0, org.osgi.service.packageadmin; version=1.2.0, org.osgi.service.startlevel; version=1.1.0, org.osgi.service.url; version=1.0.0, org.osgi.util.tracker; version=1.5.0, , org.glassfish.embeddable;org.glassfish.embeddable.spi;version=3.1.1 (org.osgi.framework.BundleException: Exported package names cannot be zero length.)
org.osgi.framework.BundleException: Exported package names cannot be zero length.
at org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:729)
at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:191)
at org.apache.felix.framework.ExtensionManager.<init>(ExtensionManager.java:220)
at org.apache.felix.framework.Felix.<init>(Felix.java:374)
at org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiFrameworkLauncher.launchOSGiFrameWork(OSGiFrameworkLauncher.java:77)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:129)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
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:474)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)



 Comments   
Comment by Sanjeeb Sahoo [ 22/Nov/12 04:22 AM ]

svn #57082





[GLASSFISH-19362] system property created for other config will be set for DAS even though it shouldn't. Created: 21/Nov/12  Updated: 30/Nov/12  Resolved: 22/Nov/12

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1.2, 3.1.2.2
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File EnumProperties.war    
Tags:
Participants: Anissa Lam and Tom Mueller

 Description   

When a system property is create for other config, it is being set for the DAS as well, although domain.xml is updated correctly.

Step to reproduce:
%asadmin start-domain
%asadmin deploy EnumProperties
%asadmin create-instance --node localhost-domain1 test
%asadmin start-instance test
%asadmin create-system-properties --target test-config ATEST=atest-value

you will see that domain.xml is updated correctly. ATEST is only showing up under <test-config>
however, if you launch http://localhost:8080/EnumProperties
you will see that ATEST is showing up too when it shouldn't.

I see that in CombinedJavaConfigSystemPropertyListener.java, once it detected that the target is a config, it calls addToConfig
else if (proxy instanceof Config) { return addToConfig(sp); }

but addToConfig() doesn't test which config this is applying, and just call System.setProperty()

private NotProcessed addToConfig(SystemProperty sp) { if (!serverHas(sp) && !clusterHas(sp)) System.setProperty(sp.getName(), sp.getValue()); //if server or cluster overrides it anyway, this should be a noop return null; //processed }

I think that maybe the issue.



 Comments   
Comment by Tom Mueller [ 22/Nov/12 03:45 AM ]

Fixed on the trunk in revision 57081.

This change fixes the CombinedJavaConfigSystemPropertyListener so that it only updates Java system property if the SystemProperty is for the current server/config/cluster.

Comment by Tom Mueller [ 30/Nov/12 06:27 PM ]

Backported to 3.1.2-SUSTAINING branch (revision 8351).





[GLASSFISH-19361] create-system-properties cannot handle the case where the property name already exists. Created: 21/Nov/12  Updated: 30/Nov/12  Resolved: 22/Nov/12

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1.2, 3.1.2.2
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File EnumProperties.war    
Tags:
Participants: Anissa Lam and Tom Mueller

 Description   

I found this issue when trying to look at another issue where using REST to modify system property of a config failed.
When a user calls create-system-properties, but a property with that name already exists, it reports successful. Not sure if thats by design. However, any user application deployed to the server referencing that config will see that the property is gone, ie calling System.getProperties() will not return that property at all.

Here is the steps to reproduce. I am using DAS, but the same behavior is observed for any instance.
The war file EnumProperties is attached.

%asadmin start-domain
%asadmin deploy EnumProperties
%asadmin create-system-properties --target server-config AAA=aaa:BBB=bbb
launch the app by going to http://localhost:8080/EnumProperties, you can see the 2 properties.
now do
%asadmin create-system-properties --target server-config AAA=new-value
The command returns saying executed successfully.
domain.xml is updated with the new value, but run EnumProperties again, and you can see that only BBB is showing up.

If create-system-properties is working as expected, ie, it means modifying a property value if the property already exists, then System.getProperties() should return this property.

If create-system-properties is only for creating new property, then it should return error and not update domain.xml with this new value.



 Comments   
Comment by Tom Mueller [ 21/Nov/12 03:29 PM ]

The create-system-properties manual page says, "If any system properties were previously defined, they are updated with the new values."

So the bug here is that System.getProperties is not returning the value after the update.

Comment by Tom Mueller [ 21/Nov/12 07:29 PM ]

The root cause of this problem is that config bean change events are being delivered out of order to ConfigListener objects. When a system property is to be updated by create-system-properties, the command first removes the old property and then adds a new one. There is a comment in the code saying that SystemProperty.setValue doesn't work, so this is the reason for the delete and then add. However, the CombinedJavaConfigSystemPropertyListener class (the ConfigListener) receives the change events in the opposite order, i.e., the add is first followed by the delete. Thus, the result on the Java system properties is that the value is deleted.

Comment by Anissa Lam [ 22/Nov/12 12:48 AM ]

The REST code has been fixed to delete only those property that user has removed instead of deleting all existing properties, before calling create-system-properties.
It also goes through commands to do the delete so that replication works correctly.

Comment by Tom Mueller [ 22/Nov/12 03:44 AM ]

Fixed in revision 57081.

This fixes the create-system-properties command so that it only updates an existing property rather than deleting it and then adding it. This produces the correct behavior for the Java system properties.

Comment by Tom Mueller [ 30/Nov/12 06:27 PM ]

Backported to 3.1.2-SUSTAINING branch (revision 8351).





[GLASSFISH-19360] Update handling of JMS connection factory resource configuration metadata to match latest spec Created: 20/Nov/12  Updated: 28/Nov/12  Resolved: 28/Nov/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.0_b64_EE7MS2

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation
Participants: Nigel Deakin and Simon Meng

 Description   

Since GLASSFISH-18900 was implemented the <jms-connection-factory> element (defined in the Java EE 7 schema) and the JMSConnectionFactoryDefinition annotation (defined in MQ) have changed.

The url and connectionTimeout elements have been removed from the JMSConnectionFactoryDefinition annotation

The connectionTimeout element has been removed from the <jms-connection-factory> element.

GlassFish's support for <jms-connection-factory> and JMSConnectionFactoryDefinition needs to be updated accordingly.



 Comments   
Comment by Nigel Deakin [ 20/Nov/12 10:18 AM ]

This needs to be done before MQ sprint 7 can be integrated into GlassFish.

Comment by Simon Meng [ 28/Nov/12 05:55 AM ]

Fixed at revision 57184.





[GLASSFISH-19356] [PERF] Increase in Memory Footprint for GF Full Profile Created: 19/Nov/12  Updated: 26/Nov/12  Resolved: 26/Nov/12

Status: Resolved
Project: glassfish
Component/s: performance
Affects Version/s: None
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Major
Reporter: vijay_oracle Assignee: Bhakti Mehta
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish SVN revision 57021


File Attachments: Zip Archive patch-for-perf.zip     Zip Archive patch-part2.zip    
Tags:
Participants: Bhakti Mehta, Scott Oaks and vijay_oracle

 Description   

The below stated commit has resulted in the module com.sun.xml.bind getting resolved at startup while earlier it was in NEW state. This change has caused a good (> 10 MB) increase in Memory consumed by GF at startup as per performance jobs running on our system. I also see an increase of about 0.2-0.3 seconds in startup time post this change.

Revision 57021 by bhaktimehta:
Minor fixes
1.Performance fixes for JAXBContext, Marshaller and Unmarshaller
2.Store the subject for the command in JobManager
3.list-jobs gets the user from the Subject
4.Fixed list-jobs to get information of completed jobs
Tests ran Ql



 Comments   
Comment by Scott Oaks [ 19/Nov/12 10:25 PM ]

Good catch Vijay.

Bhakti, can you adjust the module so it doesn't need to be started until needed?

Comment by Bhakti Mehta [ 19/Nov/12 10:55 PM ]

Looking into it Scott, Vijay.

Comment by Bhakti Mehta [ 20/Nov/12 12:07 AM ]

Fix is in progress will work with Scott to verify and commit .

Comment by Bhakti Mehta [ 20/Nov/12 01:26 AM ]

Initial attempt to fix . Please can you copy over the jars to modules folder of gf

Comment by Bhakti Mehta [ 20/Nov/12 11:29 PM ]

Second attempt to fix it...

Comment by Bhakti Mehta [ 26/Nov/12 09:05 PM ]

svn rev 57119





[GLASSFISH-19277] validate-multicast command is part of incorrect module Created: 02/Nov/12  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b60
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Joe Fialli
Resolution: Fixed Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19343 validate-multicast man page needs to ... Sub-task Resolved Mike Fitch  
Tags:
Participants: Joe Fialli, Sanjeeb Sahoo and Tom Mueller

 Description   

This command which is a cluster/multi-instance related command is currently part of admin-cli.jar.



 Comments   
Comment by Tom Mueller [ 02/Nov/12 01:41 PM ]

Joe, we need to have this fixed for an upcoming release. Can you get to this in the next couple of weeks? If not, please let me know. Thanks.

I would recommend moving this command to the cluster-cli.jar module (nucleus/cluster/cli).

Comment by Joe Fialli [ 02/Nov/12 02:08 PM ]

Evaluating.

Comment by Joe Fialli [ 02/Nov/12 02:29 PM ]

ValidateMulticastCommand.java is not located in admin-cli.jar, it is in gms-adapter.jar.
Here is listing:

% jar tvf gms-adapter.jar
<deleted>
5575 Tue Nov 22 15:25:26 EST 2011 org/glassfish/gms/admin/validate-multicast.1
2427 Mon Oct 29 08:15:02 EDT 2012 org/glassfish/gms/admin/ValidateMulticastCommand.class
<deleted>

The source code lives in all/main/nucleus/cluster/gms-adapter/src/main/java/org/glassfish/gms/admin/ValidateMulticastCommand.java

Given that this CLI command is a wrapper around code from shoal-gms-impl.jar that implement validate multicast,
I believe this is a reasonable location for the code. If no one objects, I recommend closing this issue as not a bug.

Comment by Tom Mueller [ 09/Nov/12 06:02 PM ]

Sorry for the mistake about this being in admin-cli.jar.

The problem is that validate-multicast is showing up in the list-commands output for a skinned command that is not "asadmin". The reason for this is that gms-adapter.jar is included the classpath for admin-cli.jar in the pom.xml file.

The problem with gms-adapter.jar is that includes code that runs in the server as well as this local command which runs in the asadmin command. Local commands should be separated out into their own JAR file. cluster-cli.jar is one of those JAR files (it now resides in lib/asadmin rather than in modules). A similar solution is needed for validate-multicast.

Comment by Joe Fialli [ 13/Nov/12 08:08 PM ]

Outstanding documentation subtask:

After moving ValidateMulticastCommand.java from nucleus/cluster/gms-adapter to nucleus/cluster/cli,
it was noted that validate-multicast.1 man page needs to be moved from artifactid cluster-gms-adapter-manpage to cluster-cli-manpage. Additionally the package name changed from org.glassfish.gms.admin to com.sun.enterprise.admin.cli.cluster. (the man page file name incorporates the package name of the command.)

Comment by Joe Fialli [ 11/Feb/13 06:16 PM ]

The engineering part of task is completed and checked in. Only the documentation subtask is outstanding.

Comment by Joe Fialli [ 11/Feb/13 07:48 PM ]

Only the doc subtask is outstanding. This fix has already been checked in.





[GLASSFISH-19053] Implement new predefined JNDI name java:comp/InstanceName Created: 05/Sep/12  Updated: 15/Nov/12  Resolved: 15/Nov/12

Status: Closed
Project: glassfish
Component/s: naming
Affects Version/s: 4.0
Fix Version/s: 4.0_b64_EE7MS2

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: guojun.shan
Resolution: Won't Fix Votes: 0
Remaining Estimate: 2 weeks, 6 days, 19 hours
Time Spent: 5 hours
Original Estimate: 3 weeks

Tags: ee7platspec jms-2-implementation
Participants: guojun.shan, Nigel Deakin, shreedhar_ganapathy and Tom Mueller

 Description   

In the draft Java EE 7 platform spec, section EE 5.16 "Application Server Instance Name" states that:

A component may access the name of the application server instance in which it is executing using the pre-defined JNDI name java:comp/InstanceName. This name is represented by a String object. If the application has been deployed into a clustered application server, this name identifies the application server instance within the cluster. If the application server is not clustered, it is the empty string.

This issue requests the implementation of this feature.



 Comments   
Comment by Nigel Deakin [ 05/Sep/12 02:40 PM ]

This issue blocks MQ-193

Comment by shreedhar_ganapathy [ 18/Oct/12 06:02 PM ]

Assigning to Guojun to look into implementing this based on Ed Bratt's request.
The implementation is required for JMS integration work to progress.

Comment by guojun.shan [ 19/Oct/12 02:20 AM ]

sorry, I haven't found this part in the latest jsr342:
http://jcp.org/en/jsr/detail?id=342

Comment by Nigel Deakin [ 19/Oct/12 10:50 AM ]

The latest draft of Java EE 7 is at
http://java.net/projects/javaee-spec/downloads/download/JavaEE_Platform_Spec_EDR2_candidate.pdf

(This is a draft of the "second early draft" and will be superseded by the official "second early draft" when it is released)

Nigel

Comment by Tom Mueller [ 19/Oct/12 07:48 PM ]

Targeting for 4.0 release because these are Java EE 7 RI/SDK related.

Comment by guojun.shan [ 24/Oct/12 03:20 AM ]

I think 3 weeks is ok.that should include review and adding dev tests. progress of review is hard to be estimated. and current naming dev test is still broken in 4.0.

Comment by guojun.shan [ 25/Oct/12 09:15 AM ]

how can I get current application server instance name in Glassfish?

Comment by Nigel Deakin [ 25/Oct/12 03:45 PM ]

If you're asking me, I don't know. That's a question for the GlassFish team.

Comment by guojun.shan [ 02/Nov/12 06:19 AM ]

I think there are some discusstions in developers about the instance name.
can you re-define the requirement if needed?
we're blocked now.

Comment by Nigel Deakin [ 14/Nov/12 02:07 PM ]

This issue is superseded by GLASSFISH-19347 and is no longer required.





[GLASSFISH-17366] Log lines consume a lot of time. Created: 28/Sep/11  Updated: 22/Oct/12  Resolved: 22/Oct/12

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b64_EE7MS2

Type: Improvement Priority: Major
Reporter: thomas.giger Assignee: jjsnyder83
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Tags: weld-integration
Participants: jjsnyder83, Sivakumar Thyagarajan, thomas.giger and Tom Mueller

 Description   

We have an application that consists of a couple of CDI bean modules. I noticed that the time to redeploy could be reduced singnificantly by removing some trace lines in the weld-integration.jar (in my case from 54 to 19 seconds)

The lines are:
BeanDeploymentArchiveImpl.java

  • getBeanClasses()
    • logger.log(FINER, "set TCL for " + this.id + " to " + this.moduleClassLoaderForBDA);

and
DeplyomentAcrhiveImpl.java

  • getBeanDeploymentArchives(boolean printDebug) {
    • if (printDebug) logger.log(FINE, "DeploymentImpl::getBDAs. " +
      "Returning \n" + beanDeploymentArchives);

It seemed strange to me. May be you can have a look into this.



 Comments   
Comment by Sivakumar Thyagarajan [ 15/Oct/12 01:24 PM ]

Will investigate and fix this in 4.0. Exact build TBD.

Comment by Tom Mueller [ 17/Oct/12 08:19 PM ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

Comment by jjsnyder83 [ 22/Oct/12 08:55 PM ]

Added checks on the log level so Strings aren't built unnecessarily.

Committed revision 56679





[GLASSFISH-13870] some directories are not ignored properly Created: 07/Oct/10  Updated: 22/Jan/13  Resolved: 22/Jan/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 3.1
Fix Version/s: 4.0_b64_EE7MS2

Type: Bug Priority: Minor
Reporter: vince kraemer Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,870
Tags:
Participants: Romain Grécourt, Tom Mueller and vince kraemer

 Description   

I noticed that if I do 'svn diff' after 'mvn install' some 'target' directories appear in the this of changed files.
see this patch for an example:
https://glassfish.dev.java.net/nonav/issues/showattachment.cgi/5094/13277.diff

It isn't a big deal. It is just a 'usability thing'.



 Comments   
Comment by Tom Mueller [ 24/Dec/12 07:36 PM ]

The current list includes these files:

$ svn status
? appserver/appclient/client/acc-standalone-l10n/target
? appserver/appclient/client/acc-l10n/target
? appserver/tests/hk2/isolation/web/iso1/target
? appserver/tests/hk2/isolation/web/iso2/target
? appserver/common/stats77-l10n/target

Assigning this to the build_system component to have these files fixed. The RE team sets the ignore flag regularly for new modules that are created, but these must have been missed.

Comment by Romain Grécourt [ 22/Jan/13 12:35 PM ]

the reported unversionned directory are ignored.





Generated at Fri Apr 18 10:04:20 UTC 2014 using JIRA 4.0.2#472.