Thank you Willem! I'm stick to the camel version in ServiceMix (until I have time to try just Camel + Karaf) which is using 2.10.4 now and moving to 2.10.6 I think in next revision, but it is good to know it is fixed!
Regards, Cristiano 2013/7/17 Willem jiang <willem.ji...@gmail.com> > Hi, > > I just checked the code of XsltUriResolver code in the trunk, it should be > resolved since Camel 2.11.x. > You may need to consider to upgrade the Camel version of it. > > -- > Willem Jiang > > Red Hat, Inc. > FuseSource is now part of Red Hat > Web: http://www.fusesource.com | http://www.redhat.com > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) > (English) > http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > > > > On Tuesday, July 16, 2013 at 8:53 PM, Cristiano Costantini wrote: > > > Hi all again, > > > > in the end I think I've detected an issue, I don't know ho to report it, > I > > don't even know if it is a Camel or ServiceMix/Karaf issue. > > I report here what it is about and please help me pointing me to report > it > > the right way. > > > > The full problem is: > > - If I deploy a route using beans.xml file, > > - in a ServiceMix 4.5.1 running under windows 7 > > - where I have an XSLT endpoint which point to a resource in the folder > > "src/main/resources/subfolder" i.e.: <to uri="xslt://subfolder/file.xsl" > /> > > > > the file "file.xsl" is not seen an the following error is throw: > > > > 2013-07-16 14:21:16,589 | ERROR | xtenderThread-12 | > ContextLoaderListener > > | 80 - org.springframework.osgi.extender - 1.2.1 | Application > > context refresh failed > > (OsgiBundleXmlApplicationContext(bundle=test-xslt-bundle, > > config=osgibundle:/META-INF/spring/*.xml)) > > org.apache.camel.RuntimeCamelException: > > org.apache.camel.FailedToCreateRouteException: Failed to create route > > cxfEntryRoute at: >>> Choice[[When[xpath{//*[local-name()='alert']} -> > > [To[xslt://subfolder/file.xsl]]], > > Otherwise[[To[log:messagesNotManaged?showAll=true], Stop]]] <<< in route: > > Route[[From[cxf:bean:cxfEntry]] -> [Choice[[When[xpath{... because of > > Failed to resolve endpoint: xslt://subfolder/file.xsl due to: > > java.io.FileNotFoundException: Cannot find resource in classpath for URI: > > subfolder\file.xsl > > at > > > org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1316)[96:org.apache.camel.camel-core:2.10.4] > > [...] > > Caused by: org.apache.camel.FailedToCreateRouteException: Failed to > create > > route cxfEntryRoute at: >>> Choice[[When[xpath{//*[local-name()='alert']} > > -> [To[xslt://subfolder/file.xsl]]], > > Otherwise[[To[log:messagesNotManaged?showAll=true], Stop]]] <<< in route: > > Route[[From[cxf:bean:cxfEntry]] -> [Choice[[When[xpath{... because of > > Failed to resolve endpoint: xslt://subfolder/file.xsl due to: > > java.io.FileNotFoundException: Cannot find resource in classpath for URI: > > subfolder\file.xsl > > at > > > org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:879)[96:org.apache.camel.camel-core:2.10.4] > > [...] > > Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to > > resolve endpoint: xslt://subfolder/file.xsl due to: > > java.io.FileNotFoundException: Cannot find resource in classpath for URI: > > subfolder\file.xsl > > at > > > org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:479)[96:org.apache.camel.camel-core:2.10.4] > > [...] > > Caused by: javax.xml.transform.TransformerException: > > java.io.FileNotFoundException: Cannot find resource in classpath for URI: > > subfolder\file.xsl > > at > > > org.apache.camel.builder.xml.XsltUriResolver.resolve(XsltUriResolver.java:83)[96:org.apache.camel.camel-core:2.10.4] > > [...] > > Caused by: java.io.FileNotFoundException: Cannot find resource in > classpath > > for URI: subfolder\file.xsl > > at > > > org.apache.camel.util.ResourceHelper.resolveMandatoryResourceAsInputStream(ResourceHelper.java:106)[96:org.apache.camel.camel-core:2.10.4] > > at > > > org.apache.camel.builder.xml.XsltUriResolver.resolve(XsltUriResolver.java:81)[96:org.apache.camel.camel-core:2.10.4] > > [...] > > > > > > > > > > Relevant clues: > > - the same problem does not happen on linux > > - if I don't use a "subfolder" i.e. <to uri="xslt://file.xsl" />, the > route > > works also on windows. > > - the error is throw when installing the bundle > > - the same problem is not present when running the route in a java > > application, only when deploying to ServiceMix > > - the same problem does not happen on the velocity component which has > > similar way to resolve velocity templates resources (i.e. a route with > <to > > uri="velocity://subfolder/template.vm" /> works on windows). > > > > Additional Clue: > > - if I use a bad resource name on velocity template, i see that velocity > > does not change the slash to backslash i.e. error due to bad name of file > > "subfolder/bad_resource_name.vm", > > > > 2013-07-16 14:42:46,567 | ERROR | ault-workqueue-2 | DefaultErrorHandler > > | 96 - org.apache.camel.camel-core - 2.10.4 | Failed delivery > > for (MessageId: ID-AOCC-WS2-50100-1373969104441-9-3 on ExchangeId: > > ID-AOCC-WS2-50100-1373969104441-9-4). Exhausted after delivery attempt: 1 > > caught: java.io.FileNotFoundException: Cannot find resource in classpath > > for URI: subfolder/bad_resource_name.vm > > java.io.FileNotFoundException: Cannot find resource in classpath for URI: > > vm/bad_resource_name.vm > > at > > > org.apache.camel.util.ResourceHelper.resolveMandatoryResourceAsInputStream(ResourceHelper.java:106)[96:org.apache.camel.camel-core:2.10.4] > > at > > > org.apache.camel.component.ResourceEndpoint.loadResource(ResourceEndpoint.java:94)[96:org.apache.camel.camel-core:2.10.4] > > at > > > org.apache.camel.component.ResourceEndpoint.getResourceAsInputStreamWithoutCache(ResourceEndpoint.java:83)[96:org.apache.camel.camel-core:2.10.4] > > [...] > > > > Quick solution: > > - (I will) put the xslt file resources directly under > "src/main/resources" > > so no use of slashes is required (but I can't follow the advice from > > Andreas to use good pacakge names...) > > > > > > Sorry, until I learn how to debug in Servicemix I can't investigate more > > than this... > > > > Cristiano > > > > > > > > 2013/7/16 Andreas Gies <andr...@wayofquality.de (mailto: > andr...@wayofquality.de)> > > > > > Hi > > > > > > I have used that instruction in the past. By now I find it easier to > > > configure the bundle plugin including a file "osgi.bnd" > > > which lives in the bundle root directory alongside the pom file. > > > > > > The bundle-plugin would be configured as: > > > > > > <plugin> > > > <groupId>org.apache.felix</groupId> > > > <artifactId>maven-bundle-plugin</artifactId> > > > <version>2.3.7</version> > > > <extensions>true</extensions> > > > <executions> > > > <execution> > > > <id>manifest</id> > > > <phase>process-classes</phase> > > > <goals> > > > <goal>manifest</goal> > > > </goals> > > > </execution> > > > </executions> > > > <configuration> > > > <supportedProjectTypes> > > > <supportedProjectType>jar</supportedProjectType> > > > <supportedProjectType>bundle</supportedProjectType> > > > <supportedProjectType>war</supportedProjectType> > > > </supportedProjectTypes> > > > <instructions> > > > <_include>-osgi.bnd</_include> > > > </instructions> > > > </configuration> > > > </plugin> > > > > > > > > > Note that this configuration also allows me to OSGIFY wars and jars if > I > > > need it. > > > > > > A typical osgi.bnd file would look like: > > > > > > Bundle-Version:\ > > > ${project.version} > > > > > > Bundle-SymbolicName:\ > > > ${bundle.symbolicName}; singleton:=true > > > > > > Export-Package: ${bundle.namespace} > > > > > > Import-Package: \ > > > * > > > > > > Private-Package: \ > > > ${bundle.namespace}.internal > > > > > > > > > The variables ${bundle.namespace} and ${bundle.symbolicName} always > > > resolve to my artifactId, which is in my bundles always > > > ${project.groupId} + "." + uniqueidentifier. > > > > > > > > > Having this kind of structure kind of gives you a natural order of > > > packages and exports. > > > > > > Have fun > > > Andreas > > > > > > > > > > > > > > > > > > > > > > > > Am 7/16/13(29) 9:48 AM schrieb "Cristiano Costantini" unter > > > <cristiano.costant...@gmail.com (mailto:cristiano.costant...@gmail.com > )>: > > > > > > > Thank you Andreas for the hints on how to layout the packages. > > > > > > > > (I'm just studying how to make it work and not yet started to refine > the > > > > code style, > > > > I will surely take care of your recommendation.) > > > > > > > > Could you confirm right way to export a resource in OSGi is to use > the > > > > <Export-Package> instruction? > > > > > > > > Thank you, > > > > > > > > Cristiano > > > > > > > > > > > > > > > > > > > > > > > > 2013/7/16 Andreas Gies <andr...@wayofquality.de (mailto: > andr...@wayofquality.de)> > > > > > > > > > Elaborating on Claus' answer. The XSLT processor tries to resolve > the > > > > > XSLT > > > > > "test/test.xsl". > > > > > In OSGI words, it has to resolve a package "test" which contains > the > > > > > resource test.xsl. > > > > > > > > > > Though exporting the package "test" would probably work, I would > > > > > strongly > > > > > recommend to have > > > > > better qualified package names to avoid name clashes in exports. > > > > > Especially generically named > > > > > packages like "test" or "sample" may very well lead into a world > of pain > > > > > (been there). > > > > > > > > > > Once you go about exporting packages, think what you want / need to > > > > > expose > > > > > to other bundles. > > > > > I always keep my internal stuff in a package ending in ".internal" > and > > > > > have configured my builds > > > > > not to export something that matches this pattern. > > > > > > > > > > Good luck > > > > > Andreas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 7/16/13(29) 9:29 AM schrieb "Claus Ibsen" unter > > > > > <claus.ib...@gmail.com (mailto:claus.ib...@gmail.com) > > > > > > : > > > > > > > > > > > > > > > > > > > > > If the xsl file is in the classpath of your own bundle, then you > need > > > > > > to export this package. Looks like you put it in a test package. > > > > > > > > > > > > On Tue, Jul 16, 2013 at 9:27 AM, Cristiano Costantini > > > > > > <cristiano.costant...@gmail.com (mailto: > cristiano.costant...@gmail.com)> wrote: > > > > > > > I must update my previous question: > > > > > > > velocity in facts works fine, it is just xslt which causing > issues! > > > > > > > > > > > > > > My test route is in fact: > > > > > > > <route id="testRoute"> > > > > > > > <from uri="timer://myTimer?period=5000" /> > > > > > > > <setBody> > > > > > > > <constant>Foo</constant> > > > > > > > </setBody> > > > > > > > <to uri="velocity://test/test.vm" /> > > > > > > > <to uri="xslt://test/test.xsl" /> > > > > > > > <to uri="log:foo" /> > > > > > > > </route> > > > > > > > > > > > > > > the velocity: endpoint works, it is the xslt: which fail... > > > > > > > I'm able to run it if I use the full path for just the XSL > file: > > > > > > > > > > > > > > <route id="testRoute"> > > > > > > > <from uri="timer://myTimer?period=5000" /> > > > > > > > <setBody> > > > > > > > <constant>Foo</constant> > > > > > > > </setBody> > > > > > > > <to uri="velocity://test/test.vm" /> > > > > > > > <to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > uri="xslt://file:///C:/dev/Sandbox/osgi-deploy-test/src/main/resources/ > > > > > > > te > > > > > > > st/test.xsl" > > > > > > > /> > > > > > > > <to uri="log:foo" /> > > > > > > > </route> > > > > > > > > > > > > > > Anyone has any suggestion on how to address this problem? > > > > > > > > > > > > > > My only suspect is that when I run from eclipse a simple java > class > > > > > > > with a > > > > > > > main(String[] args) method where I start a > > > > > > > ConfigurableApplicationContext) > > > > > > > where it works, and when I deploy on OSGi, I'm actually using > two > > > > > > > different > > > > > > > XSLT processors, but I'm not sure how to debug it... > > > > > > > > > > > > > > thank you again, > > > > > > > > > > > > > > Cristiano > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/7/16 Cristiano Costantini > > > > > > > <cristiano.costant...@gmail.com(mailto: > cristiano.costant...@gmail.com)> > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I just tried to deploy my camel routes into an OSGi > environment > > > > > > > > (ServiceMix). > > > > > > > > > > > > > > > > I've made a simple maven project with just resources (the > beans.xml, > > > > > > > > .xsl > > > > > > > > and .vm files), > > > > > > > > however the XSLT and Velocity endpoints cannot find the > associated > > > > > > > > files ( > > > > > > > > with exception "Failed to resolve endpoint: > xslt://testTransform.xsl > > > > > > > > due > > > > > > > > to: java.io.FileNotFoundException: Cannot find resource in > classpath > > > > > > > > for > > > > > > > > URI: testTransform.xsl"). > > > > > > > > > > > > > > > > If I run the route locally (in a simple java console > application) > > > > > > > > everything works fine. > > > > > > > > > > > > > > > > Anyone has experience on this type of deployment and can > give me > > > > > some > > > > > > > > hint? > > > > > > > > > > > > > > > > Thank you, > > > > > > > > Cristiano > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Claus Ibsen > > > > > > ----------------- > > > > > > Red Hat, Inc. > > > > > > Email: cib...@redhat.com (mailto:cib...@redhat.com) > > > > > > Twitter: davsclaus > > > > > > Blog: http://davsclaus.com > > > > > > Author of Camel in Action: http://www.manning.com/ibsen > > > > > > > > > > > > > > > > > >
