[GLASSFISH-19342] Regression: NPE and IllegalArgumentException from modularity on server startup in ejb devtests Created: 13/Nov/12  Updated: 15/Nov/12  Resolved: 15/Nov/12

Status: Closed
Project: glassfish
Component/s: configuration
Affects Version/s: 4.0_b62_ms6
Fix Version/s: 4.0_b63

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: Masoud Kalali
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

EJB devtests have intermittent failures - see #1601 and #1592 under http://hudson-sca.us.oracle.com/job/ejb-devtests-trunk where domain fails to start with

java.lang.IllegalArgumentException: wrong number of arguments
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.config.modularity.ConfigModularityUtils.getOwner(ConfigModularityUtils.java:338)

followed by

MultiException stack 1 of 3
java.lang.NullPointerException
at java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:656)
at org.jvnet.hk2.config.Dom.unwrap(Dom.java:387)
at com.sun.enterprise.config.modularity.parser.ConfigurationPopulator.run(ConfigurationPopulator.java:82)
at com.sun.enterprise.config.modularity.parser.ConfigurationParser.parseAndSetConfigBean(ConfigurationParser.java:121)



 Comments   
Comment by Masoud Kalali [ 15/Nov/12 ]

Fixed at rev.56988





[GLASSFISH-19304] JAXRS failure with Default JAXBContext Created: 08/Nov/12  Updated: 16/Nov/12  Resolved: 16/Nov/12

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b62_ms6
Fix Version/s: 4.0_b63

Type: Bug Priority: Critical
Reporter: sherryshen Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

REL 5 and JDK1.7.0_03


Tags: 40-regression

 Description   

JAXRS failure with Default JAXBContext

glassfish-4.0-b62.zip
appserver-sqe/pe/ejb/moxy/jaxrs3
e.g.
Failed to get data from jaxrs, e.g.
[java] Got Ex
[java] java.io.FileNotFoundException: http://localhost:8080/jaxrs3-jaxbri/rest/customers/1

The same test passed on glassfish-4.0-b61.zip

The client output is similar to previous failure on b49
http://java.net/jira/browse/GLASSFISH-18813
which provided test steps.



 Comments   
Comment by sherryshen [ 16/Nov/12 ]

Verified the fix on glassfish-4.0-b63.zip

From the email discussion,
[1] The root cause is a regression in Jersey.
http://java.net/jira/browse/JERSEY-1579

[2] The problem is introduced with
Jersey version upgrade 2.0-m09->2.0-m09-1 on Nov. 1, 2012 in b62.

[3] Jersery 2.0-m09-1 is reverted in b63.

[4] From Jason, admin dev tests reported the failure,
main/nucleus/tests/admin.
Will update QL tests to exercise GET, POST, and DELETE so that
we can, hopefully, catch this kind of thing more quickly.

[5] Jason committed a change to the QL tests that
should catch that kind of thing in the future.

[6] Jakub set up 3 more hudson jobs to test Jersey snapshot with GF4 trunk.
http://sysifos-sol.cz.oracle.com/hudson/view/Jersey%202/view/GF%20Integration/





[GLASSFISH-19288] Deploying an ear with an ejb jar with a Session bean that specializes another causes AmbiguousDependencyException Created: 05/Nov/12  Updated: 28/Mar/13  Resolved: 28/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b53
Fix Version/s: 4.0_b63

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: req-weld-fix

 Description   

Define a specializing ejb like below, place it in a jar in the root directory of an ear. This causes an AmbiguousDependencyException when the injection point is:
@Inject
SessionSpecializationService sessionSpecializationService;

@Local
public interface SessionSpecializationService {}

@Stateless
public class SessionSpecializationServiceImplementation implements SessionSpecializationService {}

@Stateless
@Specializes
public class MockSessionSpecializationService extends SessionSpecializationServiceImplementation {}



 Comments   
Comment by jjsnyder83 [ 12/Nov/12 ]

The previous change was incorrect. I have reverted the change.
Committed revision 56969.

Comment by jjsnyder83 [ 12/Nov/12 ]

There seems to be a bug in Weld causing this.

Comment by tlcksnyder [ 28/Mar/13 ]

Resolved as of Weld 2.0.0.Beta6.





[GLASSFISH-19270] <method-intf> with * for method-name in addition to style 1 for all methods causes all methods to use the method-intf tx attribute Created: 31/Oct/12  Updated: 08/Nov/12  Resolved: 08/Nov/12

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b60
Fix Version/s: 4.0_b63

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This DD results in all methods having tx attribute NotSupported:

<container-transaction>
<method>
<ejb-name>FooEJB_CMT</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>FooEJB_CMT</ejb-name>
<method-intf>Timer</method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>



 Comments   
Comment by marina vatkina [ 08/Nov/12 ]

Fixed MethodDescriptor.equals method to make sure MDs with wild-card method-name do not compare equal if one has the method-intf element set and another doesn't

Sending dol/src/main/java/com/sun/enterprise/deployment/MethodDescriptor.java
Transmitting file data .
Committed revision 56929.





[GLASSFISH-19133] [javax.ejb] javax.ejb.embeddable.EJBContainer to implement java.lang.AutoCloseable Created: 09/Oct/12  Updated: 09/Nov/12  Resolved: 09/Nov/12

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

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ejb_3_2

 Description   

To be able to use Java SE 7 feature, javax.ejb.embeddable.EJBContainer should implement java.lang.AutoCloseable



 Comments   
Comment by marina vatkina [ 09/Nov/12 ]

Sending src/main/java/javax/ejb/embeddable/EJBContainer.java
Transmitting file data .
Committed revision 56955.





[GLASSFISH-19098] [PERF] Intermittently cannot start new domain Created: 21/Sep/12  Updated: 03/Dec/12  Resolved: 20/Nov/12

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b55
Fix Version/s: 4.0_b63

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Masoud Kalali
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log     File server.log_2012-09-21T15-36-16    
Tags: PSRBUG

 Description   

About 25% of our tests are failing because we are unable to start a domain immediately after creating it.

We execute these two commands in a script:
asadmin create-domain --adminport 4848 test_instance
asadmin start-domain test_instance

The start-domain appears to succeed (it doesn't not produce any error output), but the server is not up. In the server log, it also appears to have started, but then there are exceptions:

[#|2012-09-21T15:34:43.300-0700|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|GlassFish Server Open Source Edition 4.0 (55) startup time : Felix (35,390ms), startup services(6,296ms), total(41,686ms)|#]

[#|2012-09-21T15:34:45.259-0700|INFO|44.0|com.sun.enterprise.config.modularity.ConfigModularityUtils|_ThreadID=1;_ThreadName=main;|The provided path is not valid: server[server]
java.lang.IllegalArgumentException: wrong number of arguments
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.config.modularity.ConfigModularityUtils.getOwner(ConfigModularityUtils.java:330)
And then the server log shows that the server exits.

There must be some race condition here, because if we wait, we can always start the server find (and if we just execute another start-domain command, the server also starts fine). Something that the ConfigModularityUtils needs has not finished being create/installed by the time start-domain returns.

I am attaching the full server.log files (server.log_<timestamp> from the first startup, and server.log from the subsequent startup).



 Comments   
Comment by Masoud Kalali [ 22/Sep/12 ]

Scott, it seems to be caused by config modularity. I wil investigate and get back to you soon.

Comment by Masoud Kalali [ 24/Sep/12 ]

Can you possibly attach the domain.xml of the test server that causes the failure? that is if you are using a custom domain.xml or you are changing something from the defaults.

Comment by Masoud Kalali [ 20/Nov/12 ]

Fixed





Integrate CDI 1.1 (GLASSFISH-19191)

[GLASSFISH-19016] Implement support for transaction scope Created: 17/Aug/12  Updated: 13/Nov/12  Resolved: 13/Nov/12

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

Type: Sub-task Priority: Major
Reporter: Nigel Deakin Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JTA_SPEC-7 TransactionScoped annotation for CDI ... Closed
blocks GLASSFISH-19004 Implement injection of JMSContext obj... Resolved
Tags: ee7cdi, jms-2-implementation

 Description   

This issue covers the implementation of a built-in transaction scope for use by the injectable JMSContext implementation.



 Comments   
Comment by tlcksnyder [ 19/Oct/12 ]

New TransactionScope:https://issues.jboss.org/browse/CDI-121
8/17/2012: This annotation will be defined in the JTA area.
The implementation should be provided as a portable extension by the application server and made available to all applications.
I need to discuss this with Paul Parkinson so that we can schedule the work.

Declarative transactions on managed beans, Transaction JTA IssueInterceptor:https://issues.jboss.org/browse/CDI-27
After speaking with Paul Parkinson most, and quite likely all, of this work will be done in the JTA area of GlassFish. CDI may have to help implement the interceptors.
See Linda's blog entry:https://blogs.oracle.com/ldemichiel/entry/transactional_interceptors
Some Jave EE platform discussions (http://java.net/projects/javaee-spec/lists/jsr342-experts/archive)

New JMS annotation-handling...talk to Nigel

Comment by jjsnyder83 [ 13/Nov/12 ]

Committed revision 56977.

Comment by jjsnyder83 [ 13/Nov/12 ]

Error in previous revision. Fixed in revision 56979.





[GLASSFISH-18883] EJB 3.2 Relaxed default @Local/@Remote rules Created: 10/Jul/12  Updated: 09/Nov/12  Resolved: 09/Nov/12

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

Type: New Feature Priority: Critical
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ejb_3_2

 Description   

See changes to 4.9.7 Session Bean's Business Interface



 Comments   
Comment by shreedhar_ganapathy [ 11/Oct/12 ]

Now assigned to Srini for further eval and assignment

Comment by marina vatkina [ 09/Nov/12 ]

See test ejb32/intfces - the code didn't limit the number of interfaces





[GLASSFISH-16106] change-master-broker command does not map all the JMX error codes to corresponding error messages Created: 28/Feb/11  Updated: 08/Nov/12  Resolved: 08/Nov/12

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

Type: Bug Priority: Major
Reporter: Satish Kumar Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3-1-exclude, 3_1-exclude, 3_1-next, 3_1_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

The change-master-broker command currently does not map all the JMX codes returned by MQ to corresponding error messages. The following error messages are returned by imq change-masterbroker implimentation:

Please note that the returned errorCode string from MQ JMX interface changeMasterBroker call also contains
the statusCode in string form (like "OK", "BAD_REQUEST", ..).

"The MQ JMX changeMasterBroker operation can return following status

a) OK
The operation has returned successfully. It is guaranteed that both the old master broker
and the new master broker have switched its master broker to the new master broker.
Any broker that is not running or network partitioned with the master broker when this command is running,
would need to be restarted with explicit new master broker configuration.

b) BAD_REQUEST, NOT_ALLOWED, UNAVAILABLE, PRECONDITION_FAILED
When these status are returned, the current master broker configuration in
the cluster is not affected.

c) An error status other than a) and b)
The cluster should be shutdown and configured with the new master broker as the
master broker then restarts. "

Except OK statusCode, all other status in string form is contained in the returned errorCode String.



 Comments   
Comment by David Zhao [ 08/Nov/12 ]

Revision: 56906





[GLASSFISH-11721] GF does not allow all required passwords to be passed to managed MQ broker Created: 24/Mar/10  Updated: 12/Nov/12  Resolved: 12/Nov/12

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

Type: Improvement Priority: Major
Reporter: Satish Kumar Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,721
Tags: ee7ri_cleanup_deferred, jms4candidate

 Description   

A MQ password file allows you to specify

o keystore password (imq.keystore.password)
o LDAP repository password (imq.user_repository.ldap.password)
o JDBC database password (imq.persist.jdbc.password)
o imqcmd password (imq.imqcmd.password)
o broker bridge service manager administrator password
(imq.bridge.admin.password)

This is normally done by passing a password file to the
broker. However Glassfish also passes in a password file on the
command line, which overrides any password file configured in the
broker properties. Currently, GF does not provide users the option to configure
and use the above mentioned properties. We need a way to enable this in GF.



 Comments   
Comment by Nigel Deakin [ 07/May/10 ]

Following changes to MQ 4.5, Glassfish no longer needs to use a password file to
pass passwords to the managed broker. Updating issue summary accordingly.

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 Tom Mueller [ 18/Oct/12 ]

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 issue 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 Simon Meng [ 12/Nov/12 ]

Currently, user can set the mq required passwords via GF jms-service properties. GF call setBrokerProps method to pass these properties to jmsra. jmsra can get the required passwords from broker properties.
GF support password aliases process. That means when setting jms-service properties, user can use plain text or password aliases as propterty value.





Generated at Sat May 30 17:04:13 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.