We Keep Coding

JCA Connector Classloading

in my Scenario, i try to use JCA Adapters to connect to an external storage - just to try this feature of J2EE.
I use JBoss EAP 7 and its packed implementation ironjacamar.
i deploy an adapter.rar, which contains an adapter.jar (this contains the Connection and ConnectionFactory Interfaces and all implementations) and META-INF/ironjacamar.xml.
I then deploy a app.war file, containing a Bean with an annotated field:
#RequestScoped
public class Bean {
...
#Resource(lookup = "java:/eis/StorageConnectionFactory")
private StorageConnectionFactory connectionFactory;
}
The war also contains the adapter.jar as library - as it needs to know of all the classes at runtime (NoClassDefFound etc.)
To my amazement, the Connector itself seems to work - as is get the Exception:
java.lang.IllegalArgumentException: Can not set conn.StorageConnectionFactoryImpl field Bean.connectionFactory to conn.HsmConnectionFactoryImp
and on ommitting the interfaces even:
#Resource(lookup = "java:/eis/StorageConnectionFactory")
private StorageConnectionFactoryImpl connectionFactory;
still
java.lang.IllegalArgumentException: Can not set conn.StorageConnectionFactoryImpl field Bean.connectionFactory to conn.HsmConnectionFactoryImp
I see that the Problem is, that the adapter.rar does nto share the same classloader as the app.war and both contain the corresponding classes, leading to a sort of ClassCastException - how do i solve this issue correctly?

It seems you haven't configure resource adapter properly.
See the below guide, it will help you to configure:
https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/configuration-guide/#configuring_jca_subsystem

Jaxb cycle (infinite loop) marshalling error - MOXy and Spring OXM

I get a JAXB marshalling error (cycle infinite loop) - posted at end of this question.
I know it's due to a 2 way object reference and I have used EclipseLink MOXy JAXB marshaller in a test case to resolve this specifying ID and IDREF and specified the JAXB provider using a jaxb.properties file containing
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
However the production code uses Spring OXM and I cannot see how to achieve a similar result using this.
I have added a jaxb.properties file but it isn't being used - I know this because I add an empty file as a test and it doesn't complain (like it did on the prototype test case).
How do I specify the JAXB marshaller to use?
It appears to be using:
org.eclipse.persistence.oxm.XMLMarshaller
whereas my working test case uses :
org.eclipse.persistence.jaxb.JAXBMarshaller
Exception:
javax.xml.bind.MarshalException
- with linked exception:
[Exception [EclipseLink-25037] (Eclipse Persistence Services -
2.6.1.v20150916-55dc7c3):
org.eclipse.persistence.exceptions.XMLMarshalException
Exception Description: A cycle is detected in the object graph. This will
cause an infinite loop:
at org.eclipse.persistence.jaxb.JAXBMarshaller.marshal
(JAXBMarshaller.java:487)

OK - to resolve this I specified (in the Spring OXM file)
<xml-inverse-reference mapped-by="myObject"
<xml-element xml-idref="true"
I only added the xml-idref="true" relationship

No bean named but bean is defined

I'm working on an update version of grail-oauth-plugin that support last spring-oauth
My plugin version works good and I have implemented a workin oauth2 server.
But now I want to add a custom-grant defined like this
def doWithSpring = {
myTokenGranter(MyTokenGranter)
xmlns oauth:"http://www.springframework.org/schema/security/oauth2"
oauth.'authorization-server'( /* ... many definitions here ... */){
/* ... many definitions here ... */
oauth.'custom-grant'('token-granter-ref': "myTokenGranter")
}
}
But I get an exception telling me:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'myTokenGranter'
But the bean myTokenGranter is defined as you can see. And If I remove the custom-grant definition the project starts and I can access the myTokenGranter bean.
Looking to a fullstack trace I see that the exception occur in the spring oatuh2 server bean definition parse AuthorizationServerBeanDefinitionParser.java in the line where it try to find my bean
parserContext.getRegistry().getBeanDefinition(customGranterRef);
where customGranterRef = "myTokenGranter"
so I suspect there is a bug in Spring Ouath or in Grails BeanBuilder that does not let my "myTokenGranter" to be visible in the server parser. Or making some error in grails bean definition DSL.
Thank you for your interest.
Debugging the app more deeply I have found that the problem probably is in how grails BeanBuilder work in translating namespaced spring DSL.
If I debug the point where my bean is checked (in AuthorizationServerBeanDefinitionParser.java)
at row
parserContext.getRegistry().getBeanDefinition(customGranterRef);
if I check che result of
parserContext.getRegistry().getBeanDefinitionNames()
it show me only this beans
[org.springframework.context.annotation.internalConfigurationAnnotationProcessor
org.springframework.context.annotation.internalAutowiredAnnotationProcessor
org.springframework.context.annotation.internalRequiredAnnotationProcessor
org.springframework.context.annotation.internalCommonAnnotationProcessor
org.springframework.context.annotation.internalPersistenceAnnotationProcessor
org.springframework.aop.config.internalAutoProxyCreator
org.springframework.transaction.annotation.AnnotationTransactionAttributeSource#0
org.springframework.transaction.interceptor.TransactionInterceptor#0
org.springframework.transaction.config.internalTransactionAdvisor
oauth2TokenGranter
oauth2AuthorizationCodeServices
oauth2AuthorizationRequestManager]
And not all other decleared beans...
The problem exist even if I move the ouath server declaration inside resources.xml, keeping my custom token granter bean declaration inside resources.groovy.
But the problem solves if I move the custom token bean declaration inside resources.xml.

I don't really know how the BeanBuilder DSL works, but it seems like the problem is there if there is a problem (your example works just fine in XML). Can you do it in two steps, so the bean definition for myTokenGranter is definitely available when the OAuth2 namepsace is handled?

Solved hacking Spring Security Oauth
see this commit

#RequestMapping with "params" on same URL in different classes cause "IllegalStateException: Cannot map handler" in JUnit with SpringJUnit4ClassRunner

I perform refactoring and split controller into 2 controllers with:
#RequestMapping(value = "/graph.htm", method = RequestMethod.POST, params="first")
in first controller and:
#RequestMapping(value = "/graph.htm", method = RequestMethod.POST, params="second")
in second controller so these annotations lie in different files. When I build and use project all is fine (I put input HTML tag in my forms with different names: first and second).
But when I try to run JUnit controller test:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = { "classpath:test-context.xml" })
I get trace:
Caused by: java.lang.IllegalStateException: Cannot map handler 'firstController'
to URL path [/graph.htm]: There is already handler
of type [class com.web.controller.SecondController] mapped.
at org.springframework.web.servlet.handler.AbstractUrlHandlerMapping.registerHandler(AbstractUrlHandlerMapping.java:294)
at org.springframework.web.servlet.handler.AbstractUrlHandlerMapping.registerHandler(AbstractUrlHandlerMapping.java:266)
at org.springframework.web.servlet.handler.AbstractDetectingUrlHandlerMapping.detectHandlers(AbstractDetectingUrlHandlerMapping.java:82)
at org.springframework.web.servlet.handler.AbstractDetectingUrlHandlerMapping.initApplicationContext(AbstractDetectingUrlHandlerMapping.java:58)
at org.springframework.context.support.ApplicationObjectSupport.initApplicationContext(ApplicationObjectSupport.java:119)
at org.springframework.web.context.support.WebApplicationObjectSupport.initApplicationContext(WebApplicationObjectSupport.java:72)
at org.springframework.context.support.ApplicationObjectSupport.setApplicationContext(ApplicationObjectSupport.java:73)
at org.springframework.context.support.ApplicationContextAwareProcessor.invokeAwareInterfaces(ApplicationContextAwareProcessor.java:117)
at org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:92)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:399)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1479)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:524)
When I comment out this:
#RequestMapping(value = "/graph.htm", method = RequestMethod.POST, params="second")
in second controller individual test for first controller successfully completed.
To resolve this issue I may use different URLs (value in #RequestMapping) but I don't understand why request mapping resolved for params in my production build of application and fail with SpringJUnit4ClassRunner.
Any help welcome!
PS. I use Spring 3.2.
PPS. I found mostly same issue Can I have the same mapping value with different param in a different Spring controller? but according to answers my production build also must fail?! But I run production build successfully!!
Also refer to:
#RequestMapping with 2 params in render method
Spring MVC 3: same #RequestMapping in different controllers, with centralised XML URL mapping (hybrid xml/annotations approach)
*PPS.
I check official docs for 3.2:
http://static.springsource.org/spring/docs/3.2.x/javadoc-api/org/springframework/web/bind/annotation/RequestMapping.html#params%28%29
In a Servlet environment, parameter mappings are considered as restrictions
that are enforced at the type level. The primary path mapping (i.e. the
specified URI value) still has to uniquely identify the target handler, with
parameter mappings simply expressing preconditions for invoking the handler.
So seems I perform illegal coding practice...

This is what I understand when reading the official doc quoted in your question :
In a Servlet environment, parameter mappings are considered as restrictions
that are enforced at the type level. The primary path mapping (i.e. the
specified URI value) still has to uniquely identify the target handler within the class, with
parameter mappings simply expressing preconditions for invoking the handler.
I added the words "within the class".
And please note the enforced at type level. As I understand, it means that : in a servlet env. declaring the params at method level is quite the same as declaring the params at type level (at least if you only have only one method in your class).
Finally, if you take care to this sentence (same source):
When used at the type level, all method-level mappings inherit this parameter restriction (i.e. the type-level restriction gets checked before the handler method is even resolved).
I think all of this summarize why your are not doing illegal coding.
Regarding unit tests:
What is also important here are the words "In a Servlet environment. Obviously, when running unit tests : your not in a Servlet environment and that's probably why it is failing.

My neighbour colleague help me with debugging issue.
We compare production and test environment and found difference in context XML configuration.
Previous test configuration which fail:
<bean name="handlerMapping"
class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"/>
<bean name="handlerAdapter"
class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"/>
New and working test context configuration:
<bean name="handlerMapping"
class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping"/>
<bean name="handlerAdapter"
class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter"/>
Different spring classes use different mapping schema. Old uses per classes, newer uses per methods!!

Unable to get Spring's DataIntegrityViolationException after update to Hibernate Validator 4

I can't understand why I'm not getting a DataIntegrityViolationException any more after upgrading from Hibernate Validator 3.X to 4.X.
Somehow Spring is not able to wrap the persistence layer exceptions anymore.
Nothing has changed except the Validator dependency but the test validating that DataIntegrityViolationException is thrown in case of validation violation doesn't pass anymore.
I now get a javax.validation.ConstraintViolationException instead.
Everything is still in place, including of course the
but translation doesn't happen anymore.
help welcome!

According to JPA-2.0 specification, JSR-303 validation is automatically triggered before persisting an entity if JSR-303 validator implementation (i.e. Hibernate Validator 4.x) is present in the classpath.
So, your entity is rejected by Hibernate Validator and don't get into the database, thus database integrity constraint is not violated and DataIntegrityViolationException is not thrown, and you get JSR-303's ConstraintViolationException instead.
You can disable this default behaviour by adding
<validation-mode>NONE</validation-mode>
to your persistence.xml.

It blows my mind, but you're kind of right.
If I turn off validation I still get the 'validation', and instead of getting the DataIntegrityViolationException root cause PropertyValueException, I get org.hibernate.exception.ConstraintViolationException, not even the expected javax.validation.ConstraintViolationException
So it looks like there's 2 kinds of validation enabled by Hibernate Validator. What you seem to indicate is that the one enabled by default by the new Bean Validation is 'pre database'.
But anyway, with or without <validation-mode>NONE</validation-mode>, my logs always shows the queries. Could be that they don't make it to the database because of Hibernate logging, but I'm kind of lost about what is happening really.
What's the difference between the validation without <validation-mode>NONE</validation-mode> and the validation with. Haven't found anything about that in the doc AFAIK.