Broaleaf 5.2 ROOT.war issue with Filters - broadleaf-commerce

I am trying to deploy Broadleaf demo site version 5.2.0 on external tomcat 8.5.16 with MYSQL as DB and standalone external Solr server running on port 8983.
I am able to access the admin application.
When I try deploying the ROOT.war, I get error
12-Aug-2017 16:33:52.733 SEVERE [localhost-startStop-1]
org.apache.catalina.core.StandardContext.filterStart Exception starting
filter [blDeviceResolverRequestFilter]
javax.naming.NameNotFoundException: Name [blDeviceResolver] is not bound
in this Context. Unable to find [blDeviceResolver].
I tried creating a bean so that it autowires correctly in
BroadleafDeviceResolverRequestFilter as
#Bean(name="blDeviceResolver")
public DeviceResolver getDeviceResolver() {
return new LiteDeviceResolver();
}
But the error is still the same and I am unable to run the demo application.

So the issues was that class BroadleafDeviceResolverRequestFilter was using
#Resource
private DeviceResolver deviceResolver;
But #Resource annotation is generic and means different things to Tomcat and Spring (Reference: Spring Boot WAR deployed in Tomcat 7 tries to perform weird automatic #Resource lookup)
I replaced #Resource with #Autowired and added a bean to com.community.core.config.CoreConfig
#Bean(name="blDeviceResolver")
public DeviceResolver getDeviceResolver() {
return new LiteDeviceResolver();
}
and my issue was resolved.

Related

enableTransaction not working with J2ee Container

I get below error when I consume message in a Jboss ejb container
2022-05-18 22:37:24,699 ERROR [org.jboss.resource.adapter.jms.inflow.JmsActivation] Unable to reconnect org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#8315a9(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter#10a62f0 destination=queues/Subscriber.global.globalvirtual.e2e.cmdm.changepub.Virtual destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=java:/ACTIVEMQJMSNONXAProviderAsync user=ldcp.cmdm pass= )
javax.jms.JMSException: Please enable transactions on PulsarConnectionFactory with enableTransaction=true
After getting this error - I set enableTransaction=true and started getting different error
javax.jms.JMSException: not supported
at com.datastax.oss.pulsar.jms.PulsarConnection.createConnectionConsumer(PulsarConnection.java:685)
the error is in createConnectionConsumer.
This is the method called by the JBoss container.
This method is currently not implemented
https://github.com/datastax/pulsar-jms/blob/96606d0f22a1af8fdde0c5eff0f5dde086d9862c/pulsar-jms/src/main/java/com/datastax/oss/pulsar/jms/PulsarConnection.java#L685
the implementation should be quite straighforward.
There are integration tests for Payara and Apache TomEE but JBoss is still not covered.
Please open an issue on github.

Unable to connect to container created by TestContainers in a SpringTest

I'm using TestContainers to test a service class that will use mongodb. But Spring cannot connect to the mongodb created by the test container even I configured the DynamicPropertySource. It will just try to connect to my local mongo db instance.
Annotations for test class:
#Testcontainers
#SpringBootTest
#TestMethodOrder(MethodOrderer.OrderAnnotation::class)
Configuration
#Autowired lateinit var taskService: PersistentTaskService
companion object {
#Container
val mongoDbContainer: MongoDBContainer = MongoDBContainer("mongo:5.0.3")
#DynamicPropertySource
fun setUpProp(registry: DynamicPropertyRegistry) {
registry.add("spring.data.mongodb.uri", mongoDbContainer::getReplicaSetUrl)
}
}
How can I tell Spring to connect to the test container?
All right, I found out why.
The configuration above has no problem. The reason why Spring is still connecting to my local database is that the MongoDB configuration is hardcoded as a bean (in src/main).
I just removed the bean and opted for a configuration file instead.

Deltaspike service layer catching PersistenceException unexpected behavior

I have a java ee 8 web app using deltaspike using core, data and jsf modules.
I also added cdi bean (RegisterService using #trasactional) which calls a UserRepository
public void createNewUser(User newUser){
try{
userRepository.save(newUser)
}catch(PersistenceException ex){
throw new RegisterException("Error", ex); //it never falls at this point
}
}
When service layer calls repository I’m catching a PersistenceException and rethrowing a service layer exception but the repository never throws PersistenceException even if the primary ID is duplicated (I just can see the stacktrace in console output), of course I’m running into a contraint exception to try to execute the expected flow
I’m using a deltaspike exception handler but I have not added a #handler for PersistenceException
Does somebody knows what could be happening here?
this is a reproducible example: https://github.com/gdiazs/javaee8-fullstack
Since there is no tables in DB it will throw an PersitenceException.
I ran this example in 2 laptops.
Mine: OSx 10.14.6
JDK: Open JDK Zulu 1.8
eclipse and also maven terminal execution
Work: OSx 10.14.6 (it works as I expect good here)
JDK: Oracle 1.8
Intellij and also maven terminal execution
So now I`m really confused, no idea why is working just in one.

Hazelcast not injecting spring dependencies

I'm using hazelcast 3.8.5 as the store for jcache.
It appears hazelcast is not injecting SpringAware dependencies into the CacheLoader.
I took a peek at AbstractCacheRecordStore and it seems like only Hazelcast InstanceAware dependencies are injected, not SpringAware + Autowired
I'm setting up the cluster managedContext programatically like:
config.setManagedContext(springManagedContext);
Update
A work around I've found is put the ApplicationContext into the UserContext of hazelcast. Make the CacheLoader implement HazelcastInstanceAware. Pull the context out of there and finish autowiring the CacheLoader. Not ideal, but it works.
Created https://github.com/hazelcast/hazelcast/issues/11384
Only work around is getting spring app context out of hazelcast user context.

RMI Calls to secured EJB3 method fails

I have following configurations in my ejb-jar.xml;
<assembly-descriptor>
<security-role>
<role-name>userRole</role-name>
</security-role>
<method-permission>
<role-name>userRole</role-name>
<method>
<ejb-name>MyBean</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
</assembly-descriptor>
And I have configured following in my jboss.xml as security domain (default domain with additional user I have added as follows;
....
<security-domain>java:/jaas/JBossWS</security-domain>
...
User Properties Files Have Following;
SSOUSER=123456
User Roles Files have Following;
SSOUSER=userRole
I have written folliwing code in my client to connect to JNP;
Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
environment.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
environment.put(Context.PROVIDER_URL, "jnp://127.0.0.1:1099"); // remote machine IP
environment.put(Context.SECURITY_PRINCIPAL, "SSOUSER"); // User Context
environment.put(Context.SECURITY_CREDENTIALS, "123456");
And getting following error on jBoss console while trying to access the bean method (lookup works OK, as soon as I try to call method I get following);
16:43:42,987 ERROR [RoleBasedAuthorizationInterceptor] Insufficient permissions, principal=null, requiredRoles=[userRole], principalRoles=[]
Is there anything missing in my configurations?
Thanks
--
Sjunejo
After searching for quite long I found following which helped;
https://community.jboss.org/message/251308
Th change I have made are as follows;
Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
environment.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
environment.put(Context.PROVIDER_URL, "jnp://127.0.0.1:1099"); // remote machine IP
environment.put(Context.SECURITY_PRINCIPAL, "SSOUSER"); // User Context
environment.put(Context.SECURITY_CREDENTIALS, "123456");
Everything remain unchanged, I was using the incorrect INTIAL_CONTEXT_FACTORY i.e 'org.jnp.interfaces.NamingContextFactory', when I switched to 'org.jboss.security.jndi.JndiLoginInitialContextFactory', I got the PRINCIPAL in my EJB from SessionContext

Resources