I'm trying to get load time working in a Tomcat server defined inside STS.
I've added the load time weaver to the application context:
context:load-time-weaver/>
(I've tried as well)
context:load-time-weaver weaver-class="org.springframework.instrument.classloading.ReflectiveLoadTimeWeaver"/>
The project contains the required jars (spring-aop.jar, aspectjweaver.jar) and the instrument jar has been copied to the tomcat/lib (spring-instrument-tomcat-4.0.2.RELEASE.jar).
The context.xml inside the Servers project contains:
<Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/>
(I've tried in the tomcat/conf/context.xml and in the META-INF/context.xml as well)
When I start the server I get the error "java.lang.IllegalStateException: No LoadTimeWeaver available"
Stepping in AspectJWeavingEnabler:enableAspectJWeaving, the method that throws the exception, the bean class loader has been correctly instantiated to TomcatInstrumentableClassLoader, but the LoadTimeWeaver is null. I believe the LoadTimeWeaver should have been injected by the application context "context:load-time-weaver". The instantiated TomcatInstrumentableClassLoader seems to suggest that both the spring-instrument-tomcat-4.0.2.RELEASE.jar and the loaderClass entry in the context.xml have been correctly picked up.
Related
Intro :
My app contains 2 datasource, i used tomcat context.xml to configure them and it's working fine,
but now i need to launch the app as a spring-boot application,
one of datasource which is declared in hibernate.cfg.xml file doesn't seem to be loaded properly
What i tried:
i created a bean for the second data source which is in hibernat.cfg.xml file (same as i did for the first datasource) in a class annotated #configuration but i got this error:
Error parsing JNDI name [java:/comp/env/jdbc/mySecondDB]
i tried also to modify the jndi value to : java:comp/env/jdbc/mySecondDB
but it's not working
how i can load this 2nd datasource from the hibernate.cfg.xml file ?
Current application works fine in tc-server/Tomcat and Jboss, but when deployed in Websphere (12), I get
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'applicationAspect' defined in
ServletContext resource [/WEB-INF/spring/app-context.xml]: No matching factory method found: factory method 'aspectOf()'
and its merely a bean I defined in the context for the aspect
<bean id="applicationAspect" class="com.my.app.myaspects" factory-method="aspectOf" />
This is all happens when I import and deploy the war file in Weblogic Oracle Enterprise pack for Eclipse.
I didn't change class-loader. just add a class path in in weblogic.xml for JPA purpose
Here I really want to understand why WebLogic behave so differently on Spring aspect, is it because I was deploying in a war file? I doubted.
I get a typical error, because the spring context could not be found:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsingXML document from class path resource nested exception is java.io.FileNotFoundException: class path resource cannot be opened because it does not exist
The class creating the spring context is instantiated in a "strange" way. There's a java process, creating a groovy classloader and adding the required classpath entries (including the jar with the spring context). Using this classloader a groovy script will be executed, which in turn executes a java class creating a spring bean in the static init block. Unfortunately this fails with the above exception.
If the initial java process is called with -cp jarContainingContext it works. The jar containing the spring context, also contains the java class creating the spring context. Thus I'm sure that the jar is in the classpath.
Is it possible the the groovy classloader is different from the one of spring (if there's a seperate one)?
java MyClass -> Creates groovy classloader with all required classpath entries -> runscript -> groovy script -> running java class from a library also containing the spring context -> tries to create the bean within the static initializer -> failure
This whole chain sounds quite strange, it is but I can't really change it. I simply cannot understand where the problem is. Because the java class creating the spring context will be found by the groovy classloader but not the springContext within the same jar. It seems like there are 2 seperate classpaths.
The problem are really the classloaders. SpringBatch has a bug and might use the system classloader. Thus a classloader hell is created.
We issued a pull request to fix the issue.
I am trying to export a spring bean as service using Spring's application context, I need to have them exported as "prototype" scope, but this is not possible due to OSGi Service registry caching the service as singleton.
Doing some research I came upon a post suggesting to use "session" scope to get around this issue. I am following this tutorial to get this working, but I am stuck with an issue that has to do with class loader not finding an interface.
Here's how I am declaring the bean
<osgi:service id="SimulationExporter" ref="simulationService" interface="org.geppetto.core.simulation.ISimulation"/>
<bean id="simulationService" scope="session" class="org.geppetto.simulation.SimulationService">
<aop:scoped-proxy proxy-target-class="false"/>
</bean>
When exporting the bean to another bundle, I get the following error
Caused by: java.lang.IllegalArgumentException: interface org.springframework.aop.scope.ScopedObject is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:484)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:713)
at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:117)
The bundle importing the service bean has the dependency org.springframework.aop-3.0.0.RELEASE , and this has also being copied to the virgo repository. Any ideas why would the class loader not find that interface that it needs for scope "session"?
Does your MANIFEST.MF include import packages for aop.scope?
If you are using Apache Felix to generate it try adding something like this:
<Import-Package>org.aopalliance.aop,org.springframework.aop,org.springframework.aop.scope,org.springframework.aop.framework,*</Import-Package>
Inside my library FooLibrary.jar Spring instantiates class com.example.FooImpl which has a property bars. I have lots of Bar instances also instantiated by Spring. A set of bars is autowired into FooImpl like this:
#Component
public class FooImpl {
#Inject
private Set<Bar> bars;
In a standalone application, Spring instantiates the Bar instances, instantiates the FooImpl instances, and then autowires FooImpl.bars with the set of Bars. It works.
Now I'm running the same Spring configuration in a webapp inside Tomcat. FooLibrary.jar is inside WEB-INF/lib, and everything continues to work as outlined above.
The problem is that the web app automatically compiles somes classes using JavaCompiler, which can't find its dependencies for dynamically compiling unless I place that library on the startup Tomcat path. The minute I add FooLibrary.jar to the Tomcat classpath (e.g. in in the launch configuration of Tomcat inside Eclipse, or I presume startup.sh or setclasspath.bat if running Tomcat standalone), autowire stops working.
That is, when my webapp starts up, Spring creates all the Bar instances, then instantiates FooImpl, but never autowires the set of Bars into FooImpl.bars. Any idea why?
(Does it have something to do with the Spring ContextLoaderListener being started from the webapp classloader, but the FooImpl and Bar instances coming from the Tomcat classloader, I wonder?)
Autowiring can fail due to incompatible types (e.g. classes loaded in multiple classloaders).
Since you already place the JAR in tomcat's boot classpath, it must be visible to the webapp as well without you having to place the JAR in WEB-INF/lib.
You can make the dependency scope provided to not have Maven place it in WEB-INF/lib.