Hi
I have ear application, inside ear i have 4 web modules. What values i have to set for Classloader mode and WAR classloader policy? Currently it is giving exception ClassNotFound Exception with the values Classloader mode:PARENT_FIRST and WAR classloader policy:module.
Thanks in Advance.
could you elaborate on which class is not found, and on which WAR/JAR it is actually in, and then which one is looking for it.
The solution might end up moving the "missing" class to a separate JAR which the WARs will reference.
Related
I have an older Web-Application using Eclipse RAP 3.0 with Equinox OSGI-Container and Gemini Blueprint 1.0.2.
I can define my JDNI Values in server.xml
link them in context.xml and use them in my web.xml.
In my launch.ini i use the parent classloader fwk so the JNDI configuration is passed to the OSGI-Container.
My Application-Bundles can read those values for example in Bundle-Activator:
String xxx= InitialContext.doLookup("java:comp/env/xxx"); or
String xxx= new InitialContext().lookup("java:comp/env/xxx");
Some Bundle-Configuration is done via Gemini Blueprint xml files and SpringConfiguration Java classes.
<jee:jndi-lookup id="xxx" jndi-name="java:comp/env/xxx" />
This part is not working and i get following error
Error creating bean with name 'xxx': Invocation of init method failed;
nested exception is javax.naming.NameNotFoundException:
Name [java:comp/env/xxx] is not bound in this Context. Unable to find [java:comp].
I get the same Error when i use Spring-Java-Configuration which is invoked from gemini blueprint xml. Then statements like new InitialContext().lookup("java:comp/env/xxx") don't work and i get the same exception.
I think it has to to with the classloaders that are different for Bundle-Activator-Code and Gemini BlueprintExtender Thread but in can't figure it out how to solve this.
I found a Solution that i can use.
If i Move my JNDI-Lookups from xml into my Spring-Configuration-class then i can change the clasloader in init like this:
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
After that i my Lookups work fine.
i found that solution here
Can Spring Boot be used with OSGi? If not, any plans to have an OSGi Spring Boot?.
I have a servlet deployed to the WebSphere Liberty profile via an EAR file. The application entry in server.xml looks like this:
<application id="MyApp" name="MyApp" type="ear" location="MyApp.ear" />
The servlet needs to access a service provided by an OSGi bundle. I followed the example mentioned here. The OSGi bundle exports the package the Counter interface is in. Adding an "Import-Package" statement to the EAR's manifest (like an OSGi bundle would have) to resolve the reference to Counter resulted in a class-def exception. So I added the class directly to the EAR. Now InitialContext.lookup() does return a proxy object but typecasting it to the Counter interface results in a casting exception.
I suspect the casting exception is happening because the EAR has its own Counter.class. Is there some other way I should be resolving that reference? How can an EAR import a package from another OSGi bundle?
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.
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.
How can I load a spring beans which are in jar file say for eg. sample.jar with all the beans declared in that jar with sample-applicationContext.xml?
Now I am using some of the beans from this jar in my project so when I deploy my ear file this sample.jar is in lib folder. Now when I deploy this project to server(jboss -5) it is not injecting the bean i have referenced in my main project.
we dont have any web app in this ear so the way we are loading beans are using ClassPathXmlApplicationContext. Can somebody gave me an example of how to load those beans from sample.jar(lib folder) first and then load those are in the project, so when spring creates beans in the main project it will have beans from sample.jar and would inject them.
Thanks
Beans are looked-up on the classpath, so if they are annotated and your have the proper component scan, they should be discovered.
If they are not annotated, but only listed in the sample-applicationContext.xml, then you can <import resource="classpath:sample-applicationContext.xml" />