The title is inspecific, sorry, but I don't know what's really wrong ...
Ok, so I have working springboot app (version 2.0.4.RELEASE), weblogic 12.2.1.1. When running standalone, it's OK. But when executed under weblogic, beanvalidation silently ignores all validation issues. The typical weblogic cause for this is, that it ignores libraries which apps wants, and using it's own instead resulting in unexpected and unreliable app behavior. And yes, when debugging, bean validation code does not match with what is being declared in pom.xml. So I added
<package-name>org.hibernate.validator.*</package-name>
<package-name>javax.validation.*</package-name>
as prefer-application-packages, but now I'm getting
org.eclipse.persistence.jpa.PersistenceProvider cannot be cast to javax.persistence.spi.PersistenceProvider
which was described here: Weblogic 10.3.3 trying to load org.eclipse.persistence.jpa.PersistenceProvider instead of configured Hibernate Provider but I cannot get it to work. Any help please? I understand, that this means that weblogic is probably ruining foundations of springboot app, I'd like to fix it, however it kinda works, except for beanvalidation. So complete fix is probably not that necessary, and maybe someone does have an idea how to differently pretty-please weblogic to turn bean validation on?
I'd really like to share more, but that thing does not log any issue at all. It just dont validate beans, and the same code (except for weblogic tooling) does work properly, when weblogic is avoided.
There must be following in weblogic.xml
...
<prefer-application-resources>
<resource-name>META-INF/services/javax.persistence.spi.PersistenceProvider</resource-name>
...
</prefer-application-resources>
...
Related
I haven't been able to figure out what I'm missing here.
I've installed Tomcat and can spin it up fine. (Glassfish too, in my efforts, but I had removed it when I took the screenshot.)
So now I want to hook my project up to the Tomcat instance so I can have Netbeans deploy it for me automatically.
I right-click on my project, go down to Properties. In Project Properties I select 'Run' and go to the drop down to select my server. Only, there's no servers.
Why is it not showing up here? Am I going about this all wrong?
Thanks in advance for any help!
Other potentially useful notes:
* Using Gradle (for my first time)
* Using Spring Boot (for my first time)
* On Windows 10 (don't hate me, I don't love it either)
I was chasing the wrong problem. Spring-boot provides an embedded server so I had no need to install and provide my own.
My real problem was that I had dependencies declared for jpa, postgresql, etc. that I hadn't configured in application.properties. When I tried to run, I'd get an error saying "a problem occurred starting process /path/to/my/jdk/java.exe". I couldn't figure what was going on and, looking around, I saw the issue mentioned in my question about the server.
The solution was to simply comment out the dependencies in my build.gradle until I was ready for them. After I got my PostgreSQL DB set up and added the configureation to application.properties, I was able to un-comment them and it's working great.
I am trying to run my spring boot application (via Run As -> Spring Boot Application) in a tomcat8 container on STS and I am receiving these errors:
Caused by: java.lang.IllegalStateException: Expected method not found: java.lang.NoSuchMethodException: org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedContext.addApplicationListener(org.apache.catalina.deploy.ApplicationListener)
at org.springframework.util.ClassUtils.getMethod(ClassUtils.java:627)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.addListener(TomcatWebSocketContainerCustomizer.java:85)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.access$100(TomcatWebSocketContainerCustomizer.java:36)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer$1.customize(TomcatWebSocketContainerCustomizer.java:50)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.configureContext(TomcatEmbeddedServletContainerFactory.java:355)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.prepareContext(TomcatEmbeddedServletContainerFactory.java:184)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.getEmbeddedServletContainer(TomcatEmbeddedServletContainerFactory.java:154)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.createEmbeddedServletContainer(EmbeddedWebApplicationContext.java:157)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.onRefresh(EmbeddedWebApplicationContext.java:130)
... 7 more
I have searched around for this quite a bit and have found little to guide me in figuring out what the problem is. After going through the spring boot code in the debugger I see that the object named "instance" referenced in the TomcatWebSocketContainerCustomizer.addListener() uses reflection to retrieve a handle to it. This object is associated with the tomcat 7.0.53 jar ($HOME/.m2/repository/org/apache/tomcat/tomcat-catalina/7.0.53/tomcat-catalina-7.0.53.jar). I do not see this in any of my maven dependencies and have tried several techniques to force it to tomcat 8.0.20, nothing seems to work.
After banging my head for a while I started looking at the run configuration for the project in STS (via Run As -> Run Configurations). I found that the Source tab shows tomcat 7.0.53 above version 8.0.20 along with several dependencies that aren't referenced in maven. I am at a loss on where these values come from and not sure how to edit it. For some reason when I try to manually delete these legacy jar files STS doesn't allow me to delete any of them.
Does anyone have an idea of where these dependencies may be coming from and how I can remove them?
They do reference my $HOME/.m2/path/to/tomcat-catalina/<version> dir, so I could simply remove them from my .m2 and theoretically it may work but I'd rather not do this if I don't have to.
I am using spring boot 1.2.x and all of them have this problem.
thanks.
I've got two ideas that you might try.
1) It is possible, that this may be manifestation of this bug in STS 3.6.4: https://issuetracker.springsource.com/browse/STS-4085
The depencies you aren't expecting to see may be coming from the maven 'test' scope. (The bug explicitly mentions 'srt/test' but the same happens with jar dependencies). You can verify whether this bug is the cause by using the regular "Run As Java Application" on your main class.
If that works, then it is almost certainly this bug. If it also fails with a similar error then its something else... then try:
2) You must be getting the unwanted tomcat version from somewhere, probably indirectly as dependency of something else.
Try using the m2e 'dependency hierarchy' to find where it came from like so:
open pom.xml
Click the 'Dependency Hierarchy' tab.
Type 'tomcat' in the 'Filter' box.
I finally figured it out.
In my $WORKSPACE/.metadata/.plugins/org.eclipse.m2e.core/workspacestate.properties it lists all poms, jars and wars from my workspace build with the maven plugin. I noticed that a pom in the file points to the exact version tomcat that is being loaded in my spring boot project. Once I deleted these projects from my STS I can successfully launch the spring boot app :-)
When I re-import the maven projects back to STS the error occurs again, then disappears when I remove them.
These projects have no connection to the project that I am trying to launch. Therefore I think the bug is in m2e.
I'll file a bug and update this post when it is complete.
thanks #Kris for working through it with me.
I'm trying to implement a finagle server that works with an existing Spring 3.1 MVC project.
I'm able to instantiate the server properly, and it works well - response to messages promptly, doesn't seem to have any trouble living in the Servlet environment.
If I shut down the server during the normal lifetime of the servlet, things go well. However, if I attempt to shut down during the time the app or web context is shutting down (and I've done this in a lot of different places, I get an AspectJ error:
Jun 22, 2012 12:08:55 PM org.aspectj.weaver.tools.Jdk14Trace error
SEVERE: scala/collection/JavaConverters$AsScala
org.aspectj.weaver.BCException: Whilst processing type
'Lscala/collection/JavaConverters$AsScala;' - cannot cast the outer
type to a reference type. Signature=Lscala/collection/JavaConverters;
toString()=scala.collection.JavaConverters when processing type
mungers when weaving
at org.aspectj.weaver.AbstractReferenceTypeDelegate.g
etFormalTypeParametersFromOuterClass(AbstractRefer
enceTypeDelegate.java:110) at
org.aspectj.weaver.bcel.BcelObjectType.ensureGener
icSignatureUnpacked(BcelObjectType.java:765)
It doesn't help that I don't really know the first thing about how AOP works with Spring.
There are a couple of existing bugs listed for problems with Scala and AspectJ, but I don't think either one is germane. This one was was fixed in AspectJ 1.6.7, and I am using 1.6.9.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339300
I'm wondering if it's possible that this bug is not actually a duplicate, because I think this is what I am seeing:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337064
Can anyone give me some guidance on what is going on here?
Is the right thing to do to simply create an aop.xml that instructs AspectJ to leve all the Scala code alone?
Mark
I am currently working on a portlet that is using the commons-collections jar file and am getting a NoSuchMethodError. To resolve this issue I need to change the classloader of my WAR file from PARENT_FIRST to PARENT_LAST (in the application.xml file).
However, when I do this my portlet will not launch and when I log into the console it displays the message "The portlet is temporarily disabled". If I change the classloader back to PARENT_FIRST then it will launch again but then I get the NoSuchMethodError.
Does anybody have any suggestions on how to fix this issue ?
I am not sure how, but today I started getting error messages in the logs when I was getting "The portlet is temporarily disabled". I was getting a java.lang.LinkageError which was down to the fact that I had the servlet-api-2.5.jar and a jaxb jar which was conflicting with webshpere j2ee.jar. Once I removed these dependencies and set the classloader to PARENT_LAST, it seems to work properly. It seems that a lot of people face similar issues. The link below is also useful http://forum.springsource.org/showthread.php?33663-dispatcher-servlet-quot-not-a-servlet-class-quot-in-websphere
#MTH,
please try adding commons-collections as a shared library. See here for an example on how others have used shared library support [1]. That will give you the steps, just do it for the jars that you need to override/replace from WAS's classloader
[1] http://portals.apache.org/jetspeed-2/deployguide/deploying-jetspeed-to-websphere.html#section_4_2
thanks,
dims
You haven't provided any logs... but still, one of the most important things to look out for when setting your application to run PARENT_LAST is that your application isn't bundled with any system-level classes that may conflict with the ones provided by WebSphere Portal. For example, classes that pertain to the Portlet specification or the JavaEE specification.
I just upgraded to Spring 3, and attempted to run some JUnits to make sure everything was copacetic. It wasn't. I got a SAXParseException when loading the context... it complained:
Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans-2.0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .
My suspicion is that it couldn't access the XSD due to proxy configuration. Is there a way to make it stop trying so hard to validate it and just run the darn thing? :)
In all seriousness, though, I didn't have a problem when I was running under Spring 2, so I suspect that Spring 2 didn't bother to try to validate, but Spring 3 does. I was hoping there was a way to bypass that functionality.
One further clue... Since I couldn't run the JUnits, I went ahead and fired up the server (this is a web app), and everything seemed to go swimmingly. So that makes me think that Spring is just fine with my context files as they are.
Edit The same error occurs when using instead the Spring 3.0 schemas
It could be because you are using xsd of spring 2. You could try using http://www.springframework.org/schema/beans/spring-beans-3.0.xsd.
As it turns out, my problem was a result of re-bundling the spring jars into a single jar. Just using the separate jars worked fine for me.