Glassfish v.3, Broadleaf 1.5 and Spring JNDI failure in JMX
Posted: Thu Feb 16, 2012 4:55 pm
Hi,
It has already been in this forum once, but as the problem hasn't disappeared I thought I put some lines about this here. So basically the problem revolves around the iniatlization of AnnotationJmxAttributeSource class from the bl-framework-applicationContext.xml configuration file and the appName parameter there.
I'll put the code here also for reference:
The problem I have been struggling was that although the env-entry in web.xml has been defined in the Glassfish, during the deployment the forementioned .xml intialization completely ignored it. I did spend quite a significant amount of time debugging in broadleaf and spring framework and reached a couple of conclusions, I'm going to write down here, even if it is only for reference to others struggling with this. And my conclusion is:
Now comes the part where I was unwilling to dig into the workings of the Spring framework, but was able to confirm by changing the constructor code in AnnotationJmxAttributeClass and adding there
When this code is being run during the deployment it is actually getting the correct value from the web.xml. I'm not sure if it is the shortcoming in the Spring framework or Glassfish container code, but currently I did an ugly hack for myself, which actually does the lookup in constructor instead of the correct initialization from the Spring config.
Any ideas on how to decently fix this are of course welcome. I apologize for not being more thorough learing the Spring framework right now and not proposing a solution myself
.
It has already been in this forum once, but as the problem hasn't disappeared I thought I put some lines about this here. So basically the problem revolves around the iniatlization of AnnotationJmxAttributeSource class from the bl-framework-applicationContext.xml configuration file and the appName parameter there.
I'll put the code here also for reference:
Code: Select all
<bean id="blAttributeSource" class="org.broadleafcommerce.profile.jmx.AnnotationJmxAttributeSource">
<constructor-arg>
<bean class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>java:/comp/env/appName</value>
</property>
<property name="defaultObject" value="broadleaf"/>
</bean>
</constructor-arg>
</bean>
The problem I have been struggling was that although the env-entry in web.xml has been defined in the Glassfish, during the deployment the forementioned .xml intialization completely ignored it. I did spend quite a significant amount of time debugging in broadleaf and spring framework and reached a couple of conclusions, I'm going to write down here, even if it is only for reference to others struggling with this. And my conclusion is:
Spring lookup during the application deployment and initalization is failing in the java:comp/env/appName entry for non understandable reason. The context is initialized by Spring and I didn't notice anything strange there (seemed to be quite generic new InitialContext() with some env proprerties), but it claims the environment entry is missing and just initializes with the default value.
Now comes the part where I was unwilling to dig into the workings of the Spring framework, but was able to confirm by changing the constructor code in AnnotationJmxAttributeClass and adding there
Code: Select all
InitialContext ic = new InitialContext();
String appNameLocal = ic.lookup("java:comp/env/appName");
When this code is being run during the deployment it is actually getting the correct value from the web.xml. I'm not sure if it is the shortcoming in the Spring framework or Glassfish container code, but currently I did an ugly hack for myself, which actually does the lookup in constructor instead of the correct initialization from the Spring config.
Any ideas on how to decently fix this are of course welcome. I apologize for not being more thorough learing the Spring framework right now and not proposing a solution myself
.