I am aware of that. It was a bit on purpose for the following reasons: * some of the jars that were distributed can not be because their license prohibits that * classloaders / jar conflicts problems
Let me further explain the second point. The JBI spec defines components that come with their own set of libraries, but components classloaders inherit all the libraries from the container classloader. To avoid clashes, the container should have a minimum set of libraries (which is obviously not really the case). A first step is to remove all unneeded libraries from the container classloader (this also have the benefit that the distribution is lighter). There are still possible conflicts with the jars that are needed by the container (xalan, xerces, etc...). If you use servicemix in embedded mode (static servicemix.xml configuration file), you should build your own distribution and include the necessary jars. If you use the lightweight container, the needed jars for the component you use should be embeded in your service units. Another thing i have thought about is to create two distributions, one with std JBI components (the way the current distribution is, but without the remaining optional libraries) and another one for embedding servicemix (all needed jars like those for std JBI components available, removing the deploy/install dirs) . Examples could also be splitted across the two distributions. This has however one drawback: new users may have difficulties to choose between both distributions and even if the first one is better in production (ability to deploy/undeploy things at runtime), the second one is easier for development / tests. Any ideas welcome. Guillaume Nodet On 6/1/06, Soumadeep <[EMAIL PROTECTED]> wrote:
Changed the subject :) Soumadeep -----Original Message----- From: Soumadeep [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 4:03 PM To: [email protected] Subject: RE: http-component and dynamic xsltResource Guillaume, The new snapshot 3.0 doesn't have many of the optional jars that were there in the earlier builds, which our application used in order to run. We have accordingly changed the code base to accommodate the change in the new lib files structure, our code base compiles but we get the following error when we try to run it. Any changes in the way SA and the SU are defined or the jbi.xml?? Thanks Soumadeep Apache ServiceMix ESB: 3.0-SNAPSHOT Loading Apache ServiceMix from file: servicemix.xml Caught: java.lang.NullPointerException java.lang.NullPointerException at sun.misc.URLClassPath$3.run(URLClassPath.java:316) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:313) at sun.misc.URLClassPath.getLoader(URLClassPath.java:290) at sun.misc.URLClassPath.findResource(URLClassPath.java:141) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at java.lang.ClassLoader.getResource(ClassLoader.java:977) at org.apache.xbean.server.classloader.MultiParentClassLoader.getResourc e(MultiParentClassLoader.java:156) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java :1159) at org.apache.commons.logging.LogFactory$3.run(LogFactory.java :627) at java.security.AccessController.doPrivileged(Native Method) at org.apache.commons.logging.LogFactory.getResourceAsStream(LogFactory. java:623) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:281) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java :395) at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser. <init>(DefaultXmlBeanDefinitionParser.java:155) at org.apache.xbean.spring.context.impl.XBeanXmlBeanDefinitionParser.<in it>(XBeanXmlBeanDefinitionParser.java:66) at org.apache.xbean.spring.context.impl.XBeanXmlBeanDefinitionReader.reg isterBeanDefinitions(XBeanXmlBeanDefinitionReader.java:77) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB eanDefinitions(XmlBeanDefinitionReader.java:223) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:173) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea nDefinitions(XmlBeanDefinitionReader.java:148) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:126) at org.springframework.beans.factory.support.AbstractBeanDefinitionReade r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:142) at org.springframework.context.support.AbstractXmlApplicationContext.loa dBeanDefinitions(AbstractXmlApplicationContext.java:113) at org.apache.xbean.spring.context.FileSystemXmlApplicationContext.loadB eanDefinitions(FileSystemXmlApplicationContext.java:161) at org.springframework.context.support.AbstractRefreshableApplicationCon text.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89) at org.springframework.context.support.AbstractApplicationContext.refres h(AbstractApplicationContext.java:269) at org.apache.xbean.spring.context.FileSystemXmlApplicationContext.<init >(FileSystemXmlApplicationContext.java:149) at org.apache.xbean.spring.context.FileSystemXmlApplicationContext.<init >(FileSystemXmlApplicationContext.java:100) at org.apache.servicemix.Main.main(Main.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchStandard(Launcher.java:410) at org.codehaus.classworlds.Launcher.launch(Launcher.java:344) at org.codehaus.classworlds.Launcher.main(Launcher.java:461)
