Trying my hand at CDI for the first time. I'm using Glassfish v3. When I deploy my app, I get the following failure:
java.io.IOException:
com.sun.enterprise.admin.cli.remote.RemoteFailureException:
Exception while loading the app :
org.glassfish.deployment.common.DeploymentException:
java.lang.IncompatibleClassChangeError:
com.example.arizona.client.ArizonaService
and
com.example.arizona.client.ArizonaService$App
disagree on InnerClasses attribute
at
com.fuhrer.idea.glassfish.server.GlassfishServer3.doParseResponse(GlassfishServer3.java:28)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.parseResponse(GlassfishServer3Base.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.invoke(GlassfishServer3Base.java:127)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.handleDeployment(GlassfishServer3Base.java:78)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$2.run(JavaeeServerInstance.java:131)
I should mention that I'm not even actually using injection, or any other CDI features yet. This is just trying to get the dependencies straightened out.
I've had the same issue, but with Weld in Tomcat. Problem for me was caused by changing an inner class definition to a normal class. Resulted, in my case, in having the old innerclass still in the classes directory but with a new parent class.
Cleaning the classes directory worked for me.
Nearly a year later I'm sorry to say that I never solved this, and for various reasons moved on to another stack altogether: Tomcat, Wicket and Wicket-CDI, all of which have worked great for me.
Related
I'm trying to upgrade my applications from Liberty 18.0.0.1 to 18.0.0.2 but they all are now failing on:
java.lang.NoClassDefFoundError: javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter
...
stacktrace
the problem seems to be with ldapRegistry-3.0 - once that feature is enabled all jax-rs requests are failing. Once I remove ldapRegistry the code works fine, but I need this feature for my applications...
I've even built small example to demonstrate it, with single RestEndpoint /v1/api/employee : Sample project server config
Is this a bug, can I report it somewhere? or am I doing something wrong here?
Here is the server dump
Thank you
This seems to be caused by a subtle split package classloading conflict. I was able to reproduce this issue with Liberty 18.0.0.2 and the underlying exception looks something like this:
java.lang.NoSuchMethodException: javax.xml.bind.annotation.W3CDomHandler.createUnmarshaller(javax.xml.bind.ValidationEventHandler)
In this case it seems that javax.xml.bind.annotation.W3CDomHandler was loaded from classloader A, and javax.xml.bind.ValidationEventHandler was loaded twice -- once from classloader A and once from classloader B. The error we get here is caused by the JVM looking for javax.xml.bind.annotation.W3CDomHandler.createUnmarshaller(javax.xml.bind.ValidationEventHandler) where both classes are from classloader A, but instead it looks for a createUnmarshaller(ValidationEventHandler) method where ValidationEventHandler comes from classloader B.
This bug will be resolved in the next version of Liberty (18.0.0.3)
I am following the tutorials on http://appfuse.org/display/APF/Tutorials and I am confused on the "Register a personDao bean definition" section.
If it is necessary to register dao beans in the applicationContext.xml (or in applicationContext-dao.xml as I have seen it in an older version of an AppFuse application that I've been working with)... why is it not necessary to also register the userDao bean in the same way?
I have an alternate motive for asking this question as well...
I've been trying to port an application from an older version of the AppFuse framework (same application I mentioned above). But when I attempt to navigate to any page other than the ones that come with the original code, I get "Page not found" errors. Which is why I have gone back to the tutorials... I really want to get a handle on this since I am taking over someone else's code and they are no longer available for comment.
In addition, when adding the personDao to applicationContext.xml, IDEA complains "Required properties missing: 'sessionFactory'". When adding the line: , it then complains "Cannot resolve bean 'sessionFactory'"
It isn't necessary to register the userDao bean because it's already been done for you. The applicationContext-dao.xml file is included in the appfuse-hibernate (or appfuse-jpa) JAR file and it's imported into tests and in web.xml.
In it, it has the following:
<!-- Activates scanning of #Repository -->
<context:component-scan base-package="org.appfuse.dao"/>
You can see the file online at http://source.appfuse.org/browse/~br=release-3.5.0/appfuse/data/hibernate/src/main/resources/applicationContext-dao.xml?r=7486012b603604294be9384475b3750865c93bb6
I've faced an issue with configuring RabbitMQ with Spring Boot.
I need to override host value for my application. I use JavaConfig approach. I use auto configuration feature as well.
So I put spring.rabbitmq.host=myhost.com property into application.properties but RabbitMQ ConnectionFactory still created with localhost value.
UPDATE1: Seems like my embedded Tomcat instance doesn't pick up updates in property files. I've added some custom property and Spring can't resolve the placeholder for it.
I run my application in IntellijIdea 14 as a common java app.
All class changes are picked up by IntellijIdea&Tomcat but all resources folder content is not.
Is this IntellijIdea 14 related issue?
Thanks in advance.
If you do that from test-case, be sure to use:
#ContextConfiguration(initializers = ConfigFileApplicationContextInitializer.class)
For the test class.
I think the name of the initializer should say for itself.
Issue was resolved. There was issue with IntellijIdea 14 & 13 Gradle project setup/files compatibility. So Re-Import of the project is a solution.
I'm trying to partially mock a class from a signed Jar file (actually, the target class is in the Eclipse API).
Is there any way to do that with Mockito? I tried out several workarounds, but the result is always something like this:
org.mockito.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException-->null
...
Caused by: java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.SecurityException:
class "org.eclipse.jdt.launching.AbstractJavaLaunchConfigurationDelegate$$
FastClassByMockitoWithCGLIB$$6e308a80"'s
signer information does not match signer information of other classes
in the same package
...
A Bit of Googling showed me that PowerMock might help me, but I would like to avoid introducing a new dependency for my project.
Thanks in advance!
I believe CGLIB had been tweaked to support signed packages, but there might be some issues.
Could you make a simple project, that demonstrate the problem and open an issue on the mockito project ?
Are you running the mocks inside OSGI ?
Brice
i have a strange problem. I have an ICEFaces(1.8.2) + Facelets application im working on and every time i make a change to it and deploy i must restart Glassfish(2.1.1) else i get a "java.lang.ClassCastException" on my entities. The error message is :
java.lang.ClassCastException: za.co.africanpulse.rms.frontend.domain.Menuheader cannot be cast to za.co.africanpulse.rms.frontend.domain.Menuheader
If i restart Glassfish as said above all is ok... but this is getting kinda irratating. I dont quite know what exactly you would like me to post so that my problem is easier identified / understood. Anyways any help will be most appreciated.
Many many thanks
You should probably open an issue with the GlassFish project: https://glassfish.dev.java.net/servlets/ProjectIssues.
StackOverflow isn't really designed to be a bug reporting/analysis tool.
That said... someone might have run into this and you could 'Get Lucky'...
Edit 1:
For example, this query: http://www.google.com/search?q=glassfish+icefaces+facelet+classcastexception
Netted this hit: http://seamframework.org/Community/HelpOnSeam220ICEfaces181AndGlassfish21
which looks like it may be useful.
When the web.xml servlet version is below 2.5 and jsf is still at 1.1 specified in the faces-config.xml then strange persistence related issues will arise. In my case entities could not be cast to themselves..???
After changing servlet version and jsf version i could successfully inject EntityManagers into my DAOs...