Issue Details (XML | Word | Printable)

Key: GLASSFISH-18476
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Mitesh Meswani
Reporter: rgirsten
Votes: 0
Watchers: 0
Operations

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

Deployment Fails If EclipseLink Cache Coordination Is Configured

Created: 07/Mar/12 09:24 AM   Updated: 09/Feb/13 02:34 AM
Component/s: entity-persistence
Affects Version/s: 3.1.2
Fix Version/s: 4.0.1

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive demo_cache_coordination_gf_jms_new.zip (57 kB) 07/Mar/12 09:24 AM - rgirsten


Tags:
Participants: Hong Zhang, Mitesh Meswani, rgirsten and ymajoros


 Description  « Hide

Glassfish 3.1.2 introduced early validation of JPA persistence units on DAS.
For this reason DAS creates and entity manager during deployment which will fail with EclipseLink Cache Coordination configured because the required resources are missing on the DAS server.

For JMSTopicTransportManager this would be the TopicConnectionFactory and Topic.
For RMITransportManager this would be java system properties that I usually setup for each individual server instance and read in a session customizer to build the rmi url for the current server instance.

Workaround:
In both cases the problem can be worked around by checking whether the resources are available in a session customizer.
Cache Coordination should be switched off if the resources, e.g. the TopicConnectionFactory is not available.

public class JMSSessionCustomizerGF312 implements SessionCustomizer {

@Override
public void customize(Session session) throws Exception {
session.getLog().write("############################## SESSION CUSTOMIZER ##############################");
Server server = (Server) session;
RemoteCommandManager commandMgr = (RemoteCommandManager) server
.getCommandManager();
JMSTopicTransportManager transportManager = (JMSTopicTransportManager) commandMgr
.getTransportManager();
String connectionFactoryName = transportManager.getTopicConnectionFactoryName();
try { TopicConnectionFactory connectionFactory = (TopicConnectionFactory) new InitialContext().lookup(connectionFactoryName); }
catch(Exception ex) { session.getLog().write("Lookup of TopicConnectionFactory \"" + connectionFactoryName + "\" failed."); server.setCommandManager(null); server.setShouldPropagateChanges(false); }
session.getLog().flush();

if (server.isConnected()) { server.getCommandManager().initialize(); } else { server.login(); }
}
}

I have uploaded an example that can be used to reproduce the problem and it does also include the workaround.

To reproduce the problem configure the following in project.properties:
eclipselink.transport.protocol=jms-el22

To work around the problem configure the following in project.properties:
eclipselink.transport.protocol=jms-gf312



Mitesh Meswani added a comment - 09/Feb/13 02:34 AM

Not targeting for RI


Hong Zhang added a comment - 06/Dec/12 07:42 PM

Assign to Mitesh for evaluation as it's related to entity persistence.


rgirsten added a comment - 06/Dec/12 01:33 PM

I have added a test case to the bug which allows to reproduce the problem. For sure the deployment should work if the resources required for cache coordination are available from the DAS instance. The deployment will fail if this resources are not available.


ymajoros added a comment - 06/Dec/12 09:25 AM

FYI, we have working jms cache coordination on GF 3.1.2.2 and did nothing special for that to work. It worked in GF 3.1, too; we just upgraded.