[GLASSFISH-12564] Cannot set null string property on Object Message Created: 07/Jul/10  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: jms
Affects Version/s: v3.0.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: exabrial Assignee: Nigel Deakin
Resolution: Unresolved Votes: 1
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 MQ-165 Cannot set null message property Open
Issuezilla Id: 12,564
Tags: 3_1-exclude

 Description   

glassfish v3.0.1
sun jdk 1.6.0_20
windows xp 32bit

The JMS Message interface javadoc states that null is valid value for a string
property on a message.

If you invoke this code in a stateless ejb, you receive the stack trace below

Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(destination);
ObjectMessage message = session.createObjectMessage();
message.setObject(new Object());
message.setStringProperty("aStringProperty", null);

Caused by: java.lang.NullPointerException
at
com.sun.messaging.jms.ra.DirectPacket._checkAndSetProperty(DirectPacket.java:157
9)
at
com.sun.messaging.jms.ra.DirectPacket.setStringProperty(DirectPacket.java:1390)



 Comments   
Comment by Satish Kumar [ 06/Oct/10 ]

Setting target milestone and reassigning this to Nigel ..

Comment by Nigel Deakin [ 11/Oct/10 ]

Updating target milestone to M5 to confirm that this is already fixed.

Comment by Nigel Deakin [ 12/Oct/10 ]

Oops, ignore previous comment added to the wrong issue in error. Setting target
milestone back to M7.

Comment by Nigel Deakin [ 12/Oct/10 ]

In GlassFish 3.1 the error is

SEVERE: Error processing message
javax.jms.MessageFormatException: [C4040]: Invalid ObjectProperty type for
property aStringProperty
at
com.sun.messaging.jmq.jmsclient.MessageImpl.checkAndSetProperty(MessageImpl.java:818)
at
com.sun.messaging.jmq.jmsclient.MessageImpl.setStringProperty(MessageImpl.java:2041)

Comment by Nigel Deakin [ 12/Oct/10 ]

(previous stack trace was for LOCAL brokers),

And in GlassFish 3.1 the stack trace is

Caused by: java.lang.NullPointerException
at
com.sun.messaging.jms.ra.DirectPacket._checkAndSetProperty(DirectPacket.java:1581)
at
com.sun.messaging.jms.ra.DirectPacket.setStringProperty(DirectPacket.java:1392)

which matches what the submitted reported.

Comment by Nigel Deakin [ 12/Oct/10 ]

I've read the JMS 1.1 specification and the JavaDoc for javax.jms.Message, and
have not seen anything which suggests setting a String property can be set to
null. (Feel free to argue).

The behaviour when using a LOCAL broker is correct, which is to throw a
MessageFormatException.

The behaviour when using a EMBEDDED broker is incorrect. A NullPointerException
should not be thrown; a MessageFormatException should be thrown instead. I will
make this change.

Comment by Nigel Deakin [ 12/Oct/10 ]

The exception that is thrown when an embedded broker is used has been changed to:

javax.jms.MessageFormatException: MQJMSRA_DM4001:
setStringProperty():name=aStringProperty:value=null:Bad property value: null

Comment by Nigel Deakin [ 18/Oct/10 ]

Section 3.12 of the JMS spec "Provider Implementations of JMS Message
Interfaces" states:

"The JMS message interfaces provide write/set methods for setting object
values in a message body and message properties. All of these methods must
be implemented to copy their input objects into the message. The value of an
input object is allowed to be null and will return null when accessed."

Reopening this issue and setting target milestone to M7.

Comment by Nigel Deakin [ 26/Oct/10 ]

This does seem a valid complaint, though as it's a spec misinterpretation rather
than a bug, and MQ has almost certainly had this behaviour for many years,
fixing it can't be considered a priority for 3.1.

I'm leaving this as a P3 priority, but deferring it until 3.2 (MQ 4.6).

Comment by vladchuk [ 11/Dec/11 ]

Why is this not being addressed in 3.1.2? It seems that 3.2 has been abandoned (superseded by 4.0) and 4.0 is far away.
Please consider fixing it in 3.1.2.

Comment by exabrial [ 09/Jan/12 ]

any chance this could be fixed in 3.1.2? I can't imagine this is a difficult fix.

Comment by Nigel Deakin [ 03/May/12 ]

I've logged MQ-165 and made this issue dependent on it.

Comment by Nigel Deakin [ 15/Feb/13 ]

In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly.





[GLASSFISH-10775] JMSJCA application cannot access singleton objects created by JMSRA Created: 03/Nov/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: PC


Attachments: Zip Archive EnterpriseApplicationJMSJCA-ejb.zip     Zip Archive EnterpriseApplicationJMSJCA-war.zip     File sun-jms-adapter.rar    
Issuezilla Id: 10,775
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

It appears that a deployed application using the JMSJCA RA cannot access
singleton objects created by the JMSRA system RA.

This can be seen if you deploy an application that uses JMSJCA to connect to an
embedded MQ broker using MQ's direct mode client rather than the longstanding
TCP mode client.

If you do this, the application fails because it thinks that the embedded broker
is not running. This is because the singleton class used for the two to connect
is being loaded by different class loaders, leading to their being two instances
of this singleton object.

This is a regression from Glassfish 2.1.1, in which JMSJCA+direct mode works
just fine.

I have written a simple EJB application to demonstrate the issue.

1. Deploy the attached JMSJCA resource adapter.

Please deploy using --libraries
$GLASSFISH/glassfish/lib/install/applications/jmsra/imqjmsra.jar,$GLASSFISH/glassfish/lib/install/applications/jmsra/imqbroker.jar
where $GLASSFISH is the root of your glassfish installation (the top-level
directory containing glassfish and mq)

2. Deploy the attached EnterpriseApplicationJMSJCA-ejb.zip

This is a Stateless session bean with one business method, doCase(int x). Call
this with x=1 to execute the test case. It does this:
Connection connection1 =
enterpriseApplicationJMSJCAConnectionFactory.createConnection();
Session session1 = connection1.createSession(false, Session.AUTO_ACKNOWLEDGE);

MessageProducer messageProducer =
session1.createProducer(enterpriseApplicationJMSJCAQueue);
messageProducer.send(createJMSMessageForjmsTestQueue(session1, "Hello"));

connection1.close();

where the connection factory and destination are defined in sun-resources.xml

3. Deploy the attached EnterpriseApplicationJMSJCA-war.zip

This is a simple servlet which invokes the session bean.

4. Start the embedded broker

Make sure the JMSRA is has been lazily started by invoking "asadmin jms-ping"

5. Run the test case

To run the test case, install the RA and use Netbeans to deploy both
applications (Netbeans should create the required resources).

Then use a web browser to goto
http://localhost:8080/EnterpriseApplicationJMSJCA-war/TestServlet?param=1

Look at the server log. This will show the errors:

WARNING: [I500]: Caught JVM Exception: java.lang.RuntimeException: Direct broker
not initialized for this client runtime.
WARNING: [C4003]: Error occurred on connection creation [mq://localhost/direct].

  • cause: javax.jms.JMSException: Direct broker not initialized for this client
    runtime.

5. More information

I believe the reason for this error is that I am getting duplicate classes
com.sun.messaging.jmq.jmsclient.runtime.impl.ClientRuntimeImpl and
com.sun.messaging.jmq.jmsclient.runtime.impl.ClientRuntime
which mean I get duplicate copies of each class's singleton instance.

These classes can be found in the following jars:

$GLASSFISH/mq/lib/imq.jar
$GLASSFISH/glassfish/lib/install/applications/jmsra/imqjmsra.jar

(though I got the same error even if I removed the relevant classes from
imqjmsra.jar and copied imq.jar into $GLASSFISH/glassfish/lib/install/applications)

One instance is created when JMSRA is started and is loaded by EJBClassLoader.

The other instance is created when the application is run, and is loaded by
com.sun.enterprise.v3.server.AppLibClassLoaderServiceImpl$URLClassFinder

6. Workaround attemts

I had several attemots at working round this issue:

6A: I left sun-jms-adapter deployed using the --libraries option and added the
same jars to "classpath-suffix". This made no difference, the tests still failed
with the duplicate class problem. (I did the same for classpath-prefix).

6B: I then removed the --libraries option and repeated the test. Now the test
failed with a class not found error: sun-jms-adapter could not find the MQ
client classes, despite the jars being included in in the jars added by
classpath-suffix.

6C: If I simply add the jars to domains/domain1/lib everything passes fine.
Obviously this is not a solution, but it shows how this is a classpath/class
loader issue.



 Comments   
Comment by Nigel Deakin [ 04/Nov/09 ]

Created an attachment (id=3754)
sun-jms-adapter.rar

Comment by Nigel Deakin [ 04/Nov/09 ]

Created an attachment (id=3755)
EnterpriseApplicationJMSJCA-ejb.zip

Comment by Nigel Deakin [ 04/Nov/09 ]

Created an attachment (id=3756)
EnterpriseApplicationJMSJCA-war.zip

Comment by jthoennes [ 04/Nov/09 ]

...

Comment by Jagadish [ 06/Nov/09 ]

After evaluating the issue by having discussions over email, we do not see an
issue with GlassFish's connector classloading behavior.

Following changes can be made in the resource-adapter so as to achieve the
requirement of sharing same class across resource-adapters.

1) Generate a library so that it can be shared across resource-adapters.
2) Use Installed libraries support provided in V3.
ie., deploy the .rar with --libraries support or
via EXTENSION_LIST in MANIFEST.MF of .rar
3) Use EXTENSION_LIST in MANIFEST.MF or jmsra to refer the the library that need
to be shared.

I have provided installed libraries support (EXTENSION_LIST) for system-resource
adapters now ( issue 10861 ).

Transferring to Nigel for further investigation.

For a sample, refer the following tests under :
https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/connector/v3

<ant dir="installed-libraries" target="all-ext"/>
<ant dir="installed-libraries" target="all--libraries"/>
<ant dir="installed-libraries-embedded" target="all"/>
<ant dir="installed-libraries-embedded" target="all-ext"/>

Refer :
https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/connector/README.txt
for general instructions.

Comment by Nigel Deakin [ 10/Nov/09 ]

Adding v3_exclude

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 Nigel Deakin [ 04/Oct/10 ]

Setting keyword 3.1-exclude.

Although this is a genuine issue, it doesn't need to be fixed for 3.1 because
the use of JMSJCA with direct mode was never formally supported (though it would
work with Glassfish 3 if it weren't for this issue), and since JMSJCA is in
sustaining mode this can't be considered a priority.

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-15558] Caching JMS session in a session bean causes errors when invoked by a MDB when under load Created: 13/Jan/11  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b37
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ServerLog.odt     Zip Archive TransactionTests.zip    
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

This issue was originally reported by a user on the GlassFish developer list. Here is the thread:
http://www.java.net/forum/topic/glassfish/glassfish/jms-and-transaction-issue

The issue can be summarised as follows: a MDB consumes a message from an inbound queue, updates a database then invokes a session bean which sends a message to an outbound queue. If 40 messages are placed on the inbound queue then we see a variety of messages in the server log (see that thread), including this one:

625+0000|SEVERE|glassfish3.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=36;_ThreadName=Thread-1;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:950872495901869318 and onePhase:false due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation COMMIT_TRANSACTION(46) (XAFlag=0x0:TMNOFLAGS) on a transaction in state COMPLETE(4).|#]

The error occurs ONLY if the session bean caches its JMS connection, session and producer in a field of the bean. This is valid, though it is contrary to the conventional practice which is to create the connection, use it, and close the connection every time the session bean is invoked. If these objects are not cached then this bug is NOT seen. This bug therefore has a workaround.

The issue can be reproduced using JMS only (i.e. not using a database), though to see exactly the same errors as the user reported it is necessary to force the use of two-phase commits.

A simple NetBeans application is attached which demonstrates the issue. This consists of a Enterprise Application "TransactionTests" which is composed of a ejb application "TransactionTests-ejb" and a web application "TransactionTests-war".

Steps to reproduce:

1. Install the latest version of GlassFish 3.1 (I used build 37)
2. Before starting GlassFish, edit domain.xml to set the JVM option -Dimq.jmsra.isSameRMAllowed=false . This is needed to force two-phase transactions to be used. (If this is not done the application will still fail but you will get different errors).
3. Use NetBeans to build the application (which is an ear cotaining an ejb and a web app) and deploy it in GlassFish.
4. Visit http://localhost:8080/TransactionTests-war/ and click on "Run MDB Test 1". This causes a servlet to send 40 messages to the inbound queue.
5. Inspect the server log for errors



 Comments   
Comment by Nigel Deakin [ 13/Jan/11 ]

The attached file ServerLog.odt is an extract from the server log, which includes logging in DirectXAResource and in the application.

Note particularly Thread 36 (highlighted in green) and Thread 51 (highlighted in red). This suggests that the session bean instance used by thread 36 was reused by thread 51 after the business method returned but before the MDB returned and the transaction was committed. This meant that the same JMS session object was being used by two threads at the same time, which caused the error.

(Full disclosure: to create this logging a modified version of MQ was used with all use to System.out() in DirectXAResource changed to use JDK logging. This was necessary to ensure that such log messages were reported using the correct thread)

Comment by Nigel Deakin [ 14/Jan/11 ]

This behaviour is also seen in GlassFish 2.1.1, so this is not a regression. There's also a workaround (and the workaround is generally considered better practice than the problem case). So this bug doesn't need to be fixed now, so setting the 3_1-exclude tag.

Comment by Nigel Deakin [ 14/Jan/11 ]

Have created documentation bug
http://java.net/jira/browse/GLASSFISH-15579
to record this in the release note for 3.1.

Comment by Paul Davies [ 14/Jan/11 ]

For the GlassFish 3.1 release notes add the following information:

A stateless session bean should not save JMS connections or sessions in fields of the bean. Applications that do so may encounter errors.

To avoid this issue, if a stateless session bean's business method requires the use of a JMS connection and session then the business method should create the JMS connection and session, use it to send or receive messages, and then close the connection and session before returning. This is GlassFish issue 15558.

Comment by theodor.richard [ 14/Jan/11 ]

I'm the user who initially reported this issue on the mailing list. A problem with not caching the connection is that the maximum number of connections is reached quickly. I'm seeing the following exceptions in the log when sending 50 messages in a for loop, i.e. the method that acquires and releases the JMS connection is invoked 50 times in a row:

com.sun.messaging.jms.JMSException: MQRA:DCF:allocation failure:createConnection:Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.

My max connection pool size has the default size of 32.

Comment by Nigel Deakin [ 17/Jan/11 ]

@theodor.richard: If you believe that managed connections are not being returned correctly to the pool (and this isn't because your pool simply isn't big enough), then please log this as a separate issue or raise it on the user list. Please keep this issue for discussions of the effect of caching the connection, session and producer.

Comment by Nigel Deakin [ 25/Jan/11 ]

Analysis of the test case shows that the cause of the problem is that the container is reusing the session bean instance (and hence the connection's XAResource instance) after the business method has returned but before the transaction has been committed.

It is legal for the container to reuse the stateless session bean instance before the transaction has been committed: the EJB spec, section 4.7 "Stateless Session Beans" states that "the container may interleave requests from multiple transactions to the same instance".

However doing so causes errors in the JMSRA resource adapter, because it is designed on the basis that the same XAResource instance is used for start, end, prepare and commit and that the instance will not be reused until the transaction is committed or rolled back.

That is a breach of the JCA 1.5 spec, which states in section 7.3.2.1 "Implementation" that "A transaction manager can use any XAResource instance (if it refers to the proper resource manager instance) to initiate transaction completion. The XAResource instance used during the transaction completion process need not be the one initially enlisted with the transaction manager for this transaction"

This has been logged as internal (bugs.sun.com) bug 7014537.

Comment by jthoennes [ 14/Apr/11 ]

Hello Nigel,

as we heavily use that kind of scenario, I would like to ask whether this issue will be fixed for 3.1.1
without raising a service request.

A quick answer is highly appreciated.

Thanks, Jörg

Comment by Nigel Deakin [ 14/Apr/11 ]

This is currently scheduled for 3.2, though, as always, I can't make commitments as to the contents of future releases.

If you have a support licence and this issue is causing a problem them please contact your support representative (and let me know you've done so) since this would definitely affect the priority we give to fixing it.

Nigel

Comment by jthoennes [ 14/Apr/11 ]

In reply to comment #9:
> If you have a support licence and this issue is causing a problem them please
> contact your support representative (and let me know you've done so) since this
> would definitely affect the priority we give to fixing it.

Thanks, Nigel. Yes, we have a support contract. What do you need if I file a service request on My Oracle Support (MOS).
Do you have access to the service requests submitted?

Cheers, Jörg

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Nazrul [ 21/Apr/11 ]

It would be good to take a look at this issue for 3.1.1

Comment by Nigel Deakin [ 03/May/11 ]

@jthoennes - Yes, please file an issue with Oracle support as you suggest. There is a separate engineering team to resolve customer issues, so raising it with support increases the resources available to address this issue.

Comment by Nigel Deakin [ 03/May/11 ]

I have reviewed this bug for 3.1.1 and decided not to fix it in that version for the following reasons:

  • This bug is in older versions of GlassFish (including GlassFish 2.1.1) and so is not a regression
  • There is a workaround (see earlier comment)
  • The fix would require significant changes to the XAResource implementation classes in the JMSRA resource adapter. In addition to the work involved it would require a lot of testing to be sure that it does not introduce a regression. 3.2 will have much more testing than 3.1.1 and so, given that this is an old bug which has a workaround, I would like to defer fixing this bug until 3.2 so it can be properly tested.

Removing the 3_1_1-review tag.

@jthoennes - note that if you raise this issue with Oracle support this will still be reviewed by Oracle sustaining.

Comment by jthoennes [ 27/May/11 ]

Filed Oracle Service Request "SR 3-3705874175: Resolve GLASSFISH-15558 for Glassfish 3.1.1" for this issue.

Comment by marina vatkina [ 16/Nov/11 ]

Re EJB container behavior: In our current implementation, bean instances are returned to pool at the end of method invocation. If we were to to delay it till the termination of tx, we would need more instances because transaction can last much longer than a single method invocation.

Comment by Nigel Deakin [ 14/Dec/11 ]

Adding 3_1_2-exclude tag. Excluding from 3.1.2 for the same reason it was excluded from 3.1.1 (see my comment above).





[GLASSFISH-15424] [BigApps] [STRESS] ~17 occurences of "EOFException" warnings coming from JMS Created: 03/Jan/11  Updated: 19/Sep/14  Due: 18/Jan/11

Status: Reopened
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b34
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: varunrupela Assignee: Nigel Deakin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File eof-issue.log     File server.log-instance101-24x1-gf-b37    
Issue Links:
Dependency
blocks GLASSFISH-15423 [STRESS] [BigApps] [Umbrella-Issue] 2... Closed
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes

 Description   

See parent issue 15423 for details of the BigApps run that causes this issue to appear in the server logs. A server log that shows the issue has been attached.



 Comments   
Comment by Satish Kumar [ 04/Jan/11 ]

This is a bug in MQ. See http://java.net/jira/browse/MQ-72 for the corresponding MQ issue. Amy Kang is currently working on it and based on her feedback, a fix for this issue will be a part of the next MQ integration ...

Comment by varunrupela [ 04/Jan/11 ]

Satish,

This is a different issue from the MQ-72 issue. The log is attached to the issue. We need to check on the cause for the log.

Comment by Satish Kumar [ 04/Jan/11 ]

As I had mentioned in my earlier comment, I suspect this issue may be caused due to http://java.net/jira/browse/MQ-72.

Lowering the priority of this issue to Minor as discussed with Varun. We will need to have a re-look at this once MQ-72 is fixed and then decide if any further action is required here or if we can close this issue.

Comment by Satish Kumar [ 05/Jan/11 ]

Bumping-up the priority to Major based on Nazrul's feedback.

We plan to leave this issue open until the fix for MQ 72 has been integrated and the stress tests have been run again and observe if the exceptions are reappearing in the new test run.

Comment by Nazrul [ 10/Jan/11 ]

Please confirm if MQ-72 resolved this problem.

Comment by varunrupela [ 12/Jan/11 ]

The issue continues to exist in build 37.

Comment by varunrupela [ 13/Jan/11 ]

Added one of the instance's server log after a 24x1 run of the same scenario.

Comment by Satish Kumar [ 13/Jan/11 ]

Assigning this issue to Nigel as per our discussion this evening...

Comment by Nigel Deakin [ 14/Jan/11 ]

These messages

[#|2011-01-13T11:14:06.600+0530|WARNING|glassfish3.1|javax.jms|_ThreadID=29;_ThreadName=Thread-1;|[I500]: Caught JVM Exception: java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes.|#]

are warning messages. No errors or other messages were seen and there are no reports of the application behaving unexpectedly other than these messages.

Other users have reported receiving these messages periodically in earlier versions of MQ. There is a discussion here:
http://markmail.org/message/hh2ejjuxp5mo6njp#query:+page:1+mid:rumu3mg7unqbgm25+state:results
to which MQ team members responded.

This warning message is logged by the MQ client thread that is reading messages from a socket connected to the broker. (Note that even though the broker is embedded, since the broker is clustered, the client uses TCP to connect to the broker). The exception suggests that the client had received a "zero-length packet" from the broker. This message is often seen when the broker has failed, though this is not the case here. In that email discussion the MQ technical lead speculates that it is "probably a side effect of destination limits or TTL" and suggests that if there are no other problems the messages can be ignored.

Note that after this exception has been logged the client will attempt to recover the connection and carry on. This appears to have been the case here since no further messages were logged.

This is just a warning message, and is logged as such. Arguably GlassFish should never log warnings, but to suppress it might cause useful information to be lost if there are other problems. So it is proposed to close this bug as "not being a bug".

Comment by varunrupela [ 17/Jan/11 ]

Based on the analysis, the issue can be waived for GF 3.1. The issue should remain open as it appears in GF build 37 and as the MQ team will fix it in the long-term. It is useful to keep this issue open as opposed to creating a new one, since it contains quite some information around the bug.

Comment by Nigel Deakin [ 17/Jan/11 ]

Adding 3_1-exclude 3_1-release-notes tags. Note that this issue now only concerns the EOFExceptions and no other messages.

The release note should mention that very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored.

Comment by varunrupela [ 18/Jan/11 ]

set the target release

Comment by easarina [ 18/Jan/11 ]

Was used b38 01/14. richAccess + SSL stress test on Win 2008 machines. Saw multiple "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" warnings in server.log files. Was used jdk 1.6.0_23, 64 bit.

Comment by Nigel Deakin [ 19/Jan/11 ]

Updated summary to make it clear that it relates to warning messages, not exceptions.

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes. Is a release note still necessary?

Comment by Nigel Deakin [ 25/Mar/11 ]

Please add the following text (which I gave in my comment on 17 Jan) to the release note:

Issue 15424: Very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored.

Nigel

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by Nigel Deakin [ 14/Dec/11 ]

Excluding from 3.1.2 for the same reason it was excluded from 3.1.1. It should continue to be mentioned in the release note.

Comment by Rebecca Parks [ 24/Jan/12 ]

If it's in the 3.1.1 Release Notes, it's carried over to 3.1.2 unless it's fixed in 3.1.2. There's no need to flag it for 3.1.2.

Comment by Nigel Deakin [ 15/Feb/13 ]

In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly.





[GLASSFISH-17298] Support weblogic *-jms.xml in GlassFish Created: 14/Sep/11  Updated: 13/Feb/13

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

Type: Bug Priority: Major
Reporter: sonialiu Assignee: Nigel Deakin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Attachments: File echoMDB.ear     Text File server.log    
Tags: 3_1_2-exclude

 Description   

report the bug for backward compatibility requirement for future BG product

The current version of GlassFish doesn't support weblogic *-jms.xml.
I tried to deploy the attached weblogic jms test application echoMDB.ear to GlassFish v3.1.1 and got the following error:
"Error occurred during deployment: Exception while loading the app : EJB Container initialization error. Please see server.log for more details."

In the server.log it displayed the following exceptions:
[#|2011-09-14T14:29:50.593-0700|SEVERE|glassfish3.1.1|javax.enterprise.resource.jms.com.sun.enterprise.connectors.jms.system|_ThreadID=17;_ThreadName=Thread-2;|Missing Destination JNDI Name|#]

[#|2011-09-14T14:29:50.593-0700|SEVERE|glassfish3.1.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=17;_ThreadName=Thread-2;|MDB00017: [EchoMDB]: Exception in creating message-driven bean container: [com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Error in Runtime DD: missing destination JNDI name]|#]

[#|2011-09-14T14:29:50.593-0700|SEVERE|glassfish3.1.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=17;_ThreadName=Thread-2;|com.sun.appserv.connectors.internal.api.ConnectorRuntimeException
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Error in Runtime DD: missing destination JNDI name
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.updateMDBRuntimeInfo(ActiveJmsResourceAdapter.java:1855)
at com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.setup(ConnectorMessageBeanClient.java:186)
at com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:205)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:121)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
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.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:184)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2011-09-14T14:29:50.593-0700|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=17;_ThreadName=Thread-2;|Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:242)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
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.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:184)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Error in Runtime DD: missing destination JNDI name
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.updateMDBRuntimeInfo(ActiveJmsResourceAdapter.java:1855)
at com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.setup(ConnectorMessageBeanClient.java:186)
at com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:205)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:121)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
... 55 more

#]

---------------------------------------------------------
I unjar-ed the echoMDB.ear and found that there is a descriptor file named echoMDB-jms.xml which weblogic server uses to define jndi-name, etc., for the application. Seems GlassFish ignored it during deployment.
Here is the snapshot of the echoMDB-jms.xml
<?xml version="1.0" encoding="UTF-8"?>

<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/90">
<connection-factory name="ConnectionFactory"/>
<queue name="EchoQueue">
<sub-deployment-name>EchoQueue</sub-deployment-name>
<jndi-name>jms.echo.queue</jndi-name>
</queue>
<topic name="EchoTopic">
<sub-deployment-name>EchoQueue</sub-deployment-name>
</topic>
</weblogic-jms>
– attached server.log and echoMDB.ear



 Comments   
Comment by Hong Zhang [ 15/Sep/11 ]

Right, the weblogic-jms.xml is not supported today. Assign to Nigel for future planning for project BG.

Comment by sonialiu [ 21/Sep/11 ]

changed version to 4.0





[GLASSFISH-5214] Destination not serializable Created: 25/Jun/08  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.1

Type: Bug Priority: Minor
Reporter: cplaetzinger Assignee: Nigel Deakin
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 5,214
Status Whiteboard:

as911-na


 Description   

Hello,

i try to bind JMS destination into JNDI. This will throw the following exception:

java.io.NotSerializableException: com.sun.messaging.jmq.jmsservice.Destination
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
	at com.sun.enterprise.naming.NamingUtils.makeCopyOfObject(NamingUtils.java:64)
	at
com.sun.enterprise.naming.LocalSerialContextProviderImpl.bind(LocalSerialContextProviderImpl.java:89)
	at com.sun.enterprise.naming.SerialContext.bind(SerialContext.java:461)
	at javax.naming.InitialContext.bind(InitialContext.java:400)
	at
com.macd.research.temporaryqueues.MessageRegistrar.onMessage(MessageRegistrar.java:65)
	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.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
	at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
	at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
	at
com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1111)
	at
com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:74)
	at
com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:179)
	at $Proxy58.onMessage(Unknown Source)
	at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:258)
	at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76)
	at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)

Example code:

	public void onMessage(Message incomingMessage) {
		InitialContext ic;
		try {
			ic = new InitialContext();
			String jndiName = "macd/research/ReplyDestination";
			Destination replyDestination = incomingMessage.getJMSReplyTo();
			if (replyDestination instanceof Serializable) {
				System.out.println("Destination is serializable!");
			} else {
				System.out.println("Destination is NOT serializable!");
			}
			ic.bind(jndiName + "Test", replyDestination);
		} catch (NamingException e) {
			// ignore for testing
		} catch (JMSException e) {
			// ignore for testing
		}
	}

But the instanceof operation returns true. So the bind() method tries to
serialize the given object which cause mentioned exception. This happens if JMS
service type is set to "embedded". If i switch the type to "local" everything
works fine. In my opinion there is something wrong . The instanceof operation
should return false if the object is not serializable.



 Comments   
Comment by Sivakumar Thyagarajan [ 23/Jul/08 ]

Requesting Satish to investigate and fix.

Comment by chrjohn [ 23/Jul/08 ]
      • Issue 5214 has been confirmed by votes. ***
Comment by harpreet [ 04/Sep/08 ]

Marking target milestone as 9.1.1.

Comment by Satish Kumar [ 24/Sep/08 ]

Investigating the issue...

Comment by harpreet [ 20/Oct/08 ]

Please scrub issue and see if it is critical to v2.1.

Comment by Satish Kumar [ 29/Oct/08 ]

Downgrading the priority since the problem only exists in the EMBEDDED mode.
This appears to be an issue with the MQ. Will target a fix for the next version
of MQ (4.4).

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 David Zhao [ 14/Feb/12 ]

The reason is that although com.sun.messaging.jms.ra.TemporaryQueue is serializable, but it references com.sun.messaging.jmq.jmsservice.Destination which is not serializable.

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 David Zhao [ 29/May/12 ]

Nigel,

com.sun.messaging.jms.ra.TemporaryQueue is serializable which is extended from com.sun.messaging.jmq.jmsclient.resources.ClientResources.AdministeredObject, but it indirectly references com.sun.messaging.jmq.jmsservice.Destination (from within its parent class of com.sun.messaging.jms.ra.TemporaryDestination) which is not serializable.





Generated at Tue Mar 31 05:30:21 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.