That's great news! Looking forward to the neat jena modules! I assume this will also get around the big duplication in our jena and jena-tdb bundles.
Cheers, Reto On Thu, Sep 19, 2013 at 11:36 AM, Minto van der Sluis <[email protected]> wrote: > Hi Andy, > > Upgrading to the latest and greatest Jena versions fixed my problems. > > Dunno if you still want to see my query? Both simple and complex queries > works nicely again. > > Thanks for pointing me to this new release. > > Regards, > > Minto > > Op 18-9-2013 21:13, Andy Seaborne schreef: > > Minto, > > > > What's the query that provokes this? > > > > This looks like JENA-471 which is fixed in 2.11.0 (which was released > > today!) > > > > Andy > > > > > > > > > > On 18/09/13 14:14, Minto van der Sluis wrote: > >> Hi Andy, > >> > >> It's a local change with: > >> > >> jena-core 2.10.1 > >> jena-arq 2.10.1 > >> jena-tdb 0.10.1 > >> jena-iri 0.9.6 > >> > >> These changes are with lean OSGI wrappers around the jena jar files. One > >> wrapper per jar using the Apache ServiceMix style of wrapping. > >> > >> Looking at Jena sources I was thinking that it might be related to > >> dynamic class loading (using classloader forName). During my quest of > >> finding out which classes are binding loaded dynamically I stubles > >> across https://issues.apache.org/jira/browse/JENA-328. This issues > seems > >> to be related to my initial problem (DataTypeFactory class cast > >> exception). > >> > >> Still I like to invest some more time in the ServiceMix style wrappers > >> since it looks cleaner and less bulky than what Clerezza currently has. > >> > >> Currently I am looking into which classes have all been loaded (using > >> https://code.google.com/p/tamiflex/ ). Unfortunately it doesn't tell > >> which classes could NOT be loaded. > >> > >> Regards, > >> > >> MInto > >> > >> Op 18-9-2013 12:00, Andy Seaborne schreef: > >>> Minto, > >>> > >>> What are the versions here because when I look at the Clerezza pom I > >>> see TDB 0.10.0 + ARQ 2.10.0 but the stacktrace does not align at > >>> OpVars line 197. I can't ATM see a version where it does throw > >>> ARQInternalErrorException (although, from memory, there was bug > >>> somewhere round here quite some time ago). > >>> > >>> Andy > >>> > >>> On 17/09/13 13:54, Minto van der Sluis wrote: > >>>> Thanks Rupert for you detailed insight. > >>>> > >>>> But I am wondering if 2 bundles A and B both embed the same class C. > >>>> Then my understanding of OSGI is that A.C and B.C are not compatible > >>>> because both are loaded by different class loaders. Couldn't this be > >>>> solved by having A and B import C and adding a bundle D to export C. > >>>> This is exactly what I am trying to achieve by making the Clerezza > >>>> jena > >>>> based ext bundles leaner. > >>>> > >>>> Thus far I managed to create lean bundles the Apache ServiceMix way > >>>> for > >>>> the following Jena components: > >>>> > >>>> jena-core > >>>> jena-arq > >>>> jena-iri > >>>> jena-tdb > >>>> > >>>> Using these in my environment enables me to start Karaf en store > >>>> XML/RDF > >>>> in a tdb triple store. A few additional tests showed that both simple > >>>> queries and retrieving all triples in a graph worked well. So far so > >>>> good. > >>>> > >>>> Unfortunately trying a more complex query resulted in a jena > >>>> ARQInternalErrorException. See the stacktrace below. Unfortunately the > >>>> exception and the jena source code leaves me clueless about the exact > >>>> cause. I suspect it is caused by dynamically loading classes not > >>>> available to the jena-arq bundle. I could add them if only I knew what > >>>> is missing. > >>>> > >>>> Anyone a clue? I think about cross-posting part of this on the jena > >>>> mailing list as well. > >>>> > >>>> Regards, > >>>> > >>>> Minto > >>>> > >>>> Stacktrace: > >>>> ========= > >>>> 2013-09-17 14:34:41,142 | ERROR | l Console Thread | > >>>> AnnotationStoreServiceImpl | > >>>> .impl.AnnotationStoreServiceImpl 310 > >>>> | 206 - astore-engine-impl - 0.7.1.35 | failure > >>>> com.hp.hpl.jena.sparql.ARQInternalErrorException > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVars$OpVarsPattern.visit(OpVars.java:197) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:86) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48) > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43) > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:33) > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:70) > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:62) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.AlgebraQuad$Pusher.visit(AlgebraQuad.java:93) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.before(OpWalker.java:64) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:84) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:110) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visitN(OpWalker.java:113) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:78) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpSequence.visit(OpSequence.java:75) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:85) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:85) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:166) > >>>> > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.op.OpSlice.visit(OpSlice.java:50) > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43) > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:38) > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.Transformer.applyTransformation(Transformer.java:156) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:149) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:138) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:132) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.Transformer.transform(Transformer.java:57) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.Transformer.transformSkipService(Transformer.java:87) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.algebra.AlgebraQuad.quadize(AlgebraQuad.java:56) > >>>> > >>>> at > >>>> com.hp.hpl.jena.sparql.algebra.Algebra.toQuadForm(Algebra.java:89) > >>>> at > >>>> > com.hp.hpl.jena.tdb.solver.QueryEngineTDB.modifyOp(QueryEngineTDB.java:92) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.engine.QueryEngineBase.createPlan(QueryEngineBase.java:94) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.engine.QueryEngineBase.getPlan(QueryEngineBase.java:87) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.tdb.solver.QueryEngineTDB$QueryEngineFactoryTDB.create(QueryEngineTDB.java:174) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.getPlan(QueryExecutionBase.java:554) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.startQueryIterator(QueryExecutionBase.java:498) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execResultSet(QueryExecutionBase.java:539) > >>>> > >>>> > >>>> at > >>>> > com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execSelect(QueryExecutionBase.java:197) > >>>> > >>>> > >>>> at > >>>> > org.apache.clerezza.rdf.jena.tdb.storage.BaseTdbTcProvider.executeSparqlQuery(BaseTdbTcProvider.java:52) > >>>> > >>>> > >>>> at > >>>> > org.apache.clerezza.rdf.jena.tdb.storage.SingleTdbDatasetTcProvider.executeSparqlQuery(SingleTdbDatasetTcProvider.java:81) > >>>> > >>>> > >>>> at > >>>> > org.apache.clerezza.rdf.core.access.TcManager.executeSparqlQuery(TcManager.java:324) > >>>> > >>>> > >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > >>>> Method)[:1.7.0_17] > >>>> at > >>>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17] > >>>> > >>>> > >>>> at > >>>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17] > >>>> > >>>> > >>>> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17] > >>>> at > >>>> > org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)[10:org.apache.aries.proxy.impl:1.0.1] > >>>> > >>>> > >>>> at > >>>> > org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)[10:org.apache.aries.proxy.impl:1.0.1] > >>>> > >>>> > >>>> at > >>>> > org.apache.clerezza.rdf.core.access.$TcManager1609931491.executeSparqlQuery(Unknown > >>>> > >>>> > >>>> Source)[180:org.apache.clerezza.rdf.core:0.14.0.SNAPSHOT] > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.storage.clerezza.ClerezzaStorageProvider.query(ClerezzaStorageProvider.java:245)[208:astore-storage-clerezza:0.7.1.35] > >>>> > >>>> > >>>> at Proxy389e09fd_5ff3_480f_9651_e555d38ae923.query(Unknown > >>>> Source)[:] > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.impl.managers.StorageManager.query(StorageManager.java:172)[206:astore-engine-impl:0.7.1.35] > >>>> > >>>> > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.impl.managers.StorageManager.namedQuery(StorageManager.java:156)[206:astore-engine-impl:0.7.1.35] > >>>> > >>>> > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.impl.AnnotationStoreServiceImpl.internalNamedQuery(AnnotationStoreServiceImpl.java:293)[206:astore-engine-impl:0.7.1.35] > >>>> > >>>> > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.impl.AnnotationStoreServiceImpl.namedQuery(AnnotationStoreServiceImpl.java:163)[206:astore-engine-impl:0.7.1.35] > >>>> > >>>> > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.impl.AnnotationStoreServiceImpl.namedQuery(AnnotationStoreServiceImpl.java:153)[206:astore-engine-impl:0.7.1.35] > >>>> > >>>> > >>>> at Proxyd9d54baf_dd67_46cc_8a1a_858502a9f987.namedQuery(Unknown > >>>> Source)[:] > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.core.commands.NamedQueryAnnotationCommand.executeCommand(NamedQueryAnnotationCommand.java:87)[207:astore-engine-commands:0.7.1.35] > >>>> > >>>> > >>>> at > >>>> > nl.overheid.stelsel.digimelding.astore.core.commands.NamedQueryAnnotationCommand.doExecute(NamedQueryAnnotationCommand.java:48)[207:astore-engine-commands:0.7.1.35] > >>>> > >>>> > >>>> at > >>>> > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at > >>>> > org.apache.karaf.shell.console.jline.Console.run(Console.java:173)[14:org.apache.karaf.shell.console:2.3.2] > >>>> > >>>> > >>>> at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] > >>>> > >>>> > >>>> Op 17-9-2013 9:49, Rupert Westenthaler schreef: > >>>>> Hi Minto, Reto, > >>>>> > >>>>> IMO this is most likely not caused by incompatible version. > >>>>> > >>>>> All XML related framework do use the context ClassLoader to > >>>>> instantiate implementations of interfaces. The problem here is that > >>>>> OSGI does not have any control over this ClassLoader. Meaning that > >>>>> the > >>>>> Context Classloader is NOT the bundle ClassLoader. As long a the > >>>>> context ClassLoader does not provide XML related stuff this is not a > >>>>> problem as in such cases all such frameworks fall back to the > >>>>> "normal" > >>>>> classloader. But if you run an embedded OSGI environment or your OSGI > >>>>> environment runs within some Web-/Application container you will end > >>>>> up in situations where the implementations loaded via the > >>>>> ContextClassloader are no longer compatible with the Interfaces > >>>>> loaded > >>>>> via the Bundle ClassLoader. > >>>>> > >>>>> In such cases the implementation (e.g. the > >>>>> "org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl") does not > >>>>> implement the interface (e.g. javax.xml.datatype.DatatypeFactory) > >>>>> even > >>>>> if there would be compatible versions of the API. > >>>>> > >>>>> When I was working on the o.a.stanbol.commons.solr modules I > >>>>> needed to > >>>>> solve a lot of those problems. The best solution is to use the XML > >>>>> implementations provided by the JVM. To achieve this you need to add > >>>>> requires packages to the framework fragment. This is the only > >>>>> possibility to ensure that the context ClassLoader will provide > >>>>> compatible (the exact same) classes as the Bundle ClassLoader. > >>>>> > >>>>> If this is not possible (e.g. because the JVM does not provide > >>>>> required packages) you will need to follow up such exceptions and > >>>>> replace the ContextClassLoader with the BundleClassLoader with code > >>>>> fragments like > >>>>> > >>>>> ClassLoader classLoader = updateContextClassLoader(); > >>>>> try { > >>>>> //your code > >>>>> } finally { > >>>>> Thread.currentThread().setContextClassLoader(classLoader); > >>>>> } > >>>>> > >>>>> private ClassLoader updateContextClassLoader() { > >>>>> ClassLoader classLoader = > >>>>> Thread.currentThread().getContextClassLoader(); > >>>>> > >>>>> > Thread.currentThread().setContextClassLoader(CoreContainer.class.getClassLoader()); > >>>>> > >>>>> return classLoader; > >>>>> } > >>>>> > >>>>> However note that this is also not a perfect solution. Just search > >>>>> for > >>>>> "OSGI Context ClassLoader" and you will find a lot more information > >>>>> about this mess > >>>>> > >>>>> best > >>>>> Rupert > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Sep 16, 2013 at 4:03 PM, Reto Bachmann-Gmür > >>>>> <[email protected]> wrote: > >>>>>> Having something leaner would be very much appreciated. Not sure > >>>>>> what's > >>>>>> causing the huge amount of dependencies. > >>>>>> > >>>>>> Cheers, > >>>>>> Reto > >>>>>> > >>>>>> > >>>>>> On Mon, Sep 16, 2013 at 3:55 PM, Minto van der Sluis <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Hmm, didn't work out as planned. > >>>>>>> > >>>>>>> Looking at the ext.* bundles I noticed something else. Why is the > >>>>>>> wrapped bundle about 9M is since when the wrapped jar file only is > >>>>>>> about > >>>>>>> 0.6M. Seems like too many dependencies are embedded inside. Is this > >>>>>>> really needed? Looking inside the generated bundled I see stuff > >>>>>>> that is > >>>>>>> wrapped elsewhere. > >>>>>>> > >>>>>>> Can't we be more like ServiceMix for ext.* bundles? See > >>>>>>> http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/ > >>>>>>> > >>>>>>> I will give it a try. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Minto > >>>>>>> > >>>>>>> > >>>>>>> Op 12-9-2013 8:21, Minto van der Sluis schreef: > >>>>>>>> Then I will give it a try later today when meeting season is over. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Minto > >>>>>>>> > >>>>>>>> Op 12-9-2013 7:16, Reto Bachmann-Gmür schreef: > >>>>>>>>> On Wed, Sep 11, 2013 at 6:15 PM, Minto van der Sluis > >>>>>>>>> <[email protected]> > >>>>>>> wrote: > >>>>>>>>>> Hi Folks, > >>>>>>>>>> > >>>>>>>>>> Anyone a clue how to solve the following error? > >>>>>>>>>> > >>>>>>>>>> ... > >>>>>>>>>> Caused by: java.lang.ClassCastException: > >>>>>>>>>> org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be > >>>>>>>>>> cast to > >>>>>>>>>> javax.xml.datatype.DatatypeFactory > >>>>>>>>>> at javax.xml.datatype.DatatypeFactory.newInstance(Unknown > >>>>>>>>>> Source)[:2.2.0] > >>>>>>>>>> at > >>>>>>>>>> > com.hp.hpl.jena.tdb.store.DateTimeNode.<clinit>(DateTimeNode.java:83) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> It appear there are 3 bundles in my environment containing that > >>>>>>>>>> class: > >>>>>>>>>> > >>>>>>>>>> karaf@root>osgi:find-class DatatypeFactoryImpl > >>>>>>>>>> > >>>>>>>>>> Apache ServiceMix :: Bundles :: saaj-impl (145) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>> > com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.class > >>>>>>> > >>>>>>> > >>>>>>>>>> Apache ServiceMix :: Bundles :: xercesImpl (146) > >>>>>>>>>> org/apache/xerces/jaxp/datatype/DatatypeFactoryImpl.class > >>>>>>>>>> > >>>>>>>>>> Clerezza Ext - Jena TDB OSGi Bundle (199) > >>>>>>>>>> org/apache/xerces/jaxp/datatype/DatatypeFactoryImpl.class > >>>>>>>>>> > >>>>>>>>>> The strange this is that everything worked well until I > >>>>>>>>>> upgraded Karaf > >>>>>>>>>> (2.3.0 --> 2.3.2) and CXF (2.7.3 --> 2.7.6). Downgrading Karaf > >>>>>>>>>> again is > >>>>>>>>>> not an option since I need a fix in the latest version. > >>>>>>>>>> Downgrading CXF > >>>>>>>>>> again yields the same result. > >>>>>>>>>> > >>>>>>>>>> Is it an option for ext:org.apache.jena.tdb bundle to use and > >>>>>>>>>> external > >>>>>>>>>> xerces bundle (from ServiceMix) instead of embedding xerces > >>>>>>>>>> inside this > >>>>>>>>>> clerezza bundle? > >>>>>>>>>> > >>>>>>>>> If this works (i.e. the servicemix bundle exports all xerces > >>>>>>>>> packages > >>>>>>>>> needed by jena) this sound like the perfect solution. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Reto > >>>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> ir. ing. Minto van der Sluis > >>>>>>> Software innovator / renovator > >>>>>>> Xup BV > >>>>>>> > >>>>>>> Mobiel: +31 (0) 626 014541 > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > > > -- > ir. ing. Minto van der Sluis > Software innovator / renovator > Xup BV > > Mobiel: +31 (0) 626 014541 > >
