Hi Luciano, As you mentioned the ideal solution to this issue would be to fix the activeMQ dependency, but as you mentioned that there are other issues around this. I will be comfortable if we are able to get this done in a day or so.
Otherwise for 1.4 release I would like to go for a workaround to generate the build-dependency.xml using tuscany-maven-ant-generator for the build.xml. I will use TUSCANY-2707 to take care of this one. I can also raise a JIRA to point out the different versions of activeMQ dependencies, which can be taken care for the next release. On Wed, Dec 10, 2008 at 12:38 PM, Luciano Resende <[EMAIL PROTECTED]>wrote: > On Tue, Dec 9, 2008 at 2:49 AM, ant elder <[EMAIL PROTECTED]> wrote: > > Another fix could be to move up to one of the ActiveMQ 5.x jars which > don't > > include derby. > > > > I'm trying to move all activeMQ dependencies to 5.1.0 to see if this > solve the issue. While trying this, I noticed that we have different > versions of activeMQ dependencies across different projects (e.g from > 4.1.1 to 5.2.0)... is there any reason for having multiple versions of > the activeMQ depedency ? Would it be ok to move them all to a single > version such as 5.1.0 ? Or maybe to the latest 5.2.0 ? > > > ...ant > > > > On Tue, Dec 9, 2008 at 8:47 AM, Ramkumar R <[EMAIL PROTECTED]> > wrote: > >> > >> Hi Luciano, > >> Your investigation gives a good clue on the issue, thanks for that. > >> > >> I just tried a workaround to generate the build-dependency.xml using > >> tuscany-maven-ant-generator for > >> the build.xml to use while looking for the classpath instead of using > the > >> tuscany-sca-manifest.jar. > >> > >> This workaround seems to solve the issue. I believe we can make this > >> changes to resolve > >> this issue. > >> > > This would be a possible workaround, but I believe this would hide the > problem with the current sample, rather then really fixing the issue. > If we can't solve it by switching activeMQ versions, we could use > this, and try to get the issue fixed in a 1.4.1 release. > > >> On Tue, Dec 9, 2008 at 12:54 PM, Luciano Resende <[EMAIL PROTECTED]> > >> wrote: > >>> > >>> I think we should look into TUSCANY-2707 and understand the side > >>> effects of it, as this might be a block issue. It looks like the issue > >>> will happen whenever activeMQ and derby dependencies are together, and > >>> this will be always true when using the tuscany-all jar in a > >>> application that requires database access. > >>> > >>> Can someone working with JMS binding give a quick look on this issue ? > >>> What is the persistence story when using ActiveMQ, others might have > >>> seen this issue before... Any ideas on how to approach this issue > >>> would be welcome :) > >>> > >>> Below is what I'm seeing when running the BPEL sample from ant... > >>> > >>> [java] Exception in thread "main" java.lang.ExceptionInInitializerError > >>> [java] at > >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > >>> Method) > >>> [java] at > >>> > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > >>> [java] at > >>> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > >>> [java] at > >>> java.lang.reflect.Constructor.newInstance(Constructor.java:494) > >>> [java] at java.lang.Class.newInstance0(Class.java:350) > >>> [java] at java.lang.Class.newInstance(Class.java:303) > >>> [java] at > >>> > org.tranql.connector.jdbc.JDBCDriverMCF.setDriver(JDBCDriverMCF.java:145) > >>> [java] at > >>> org.apache.ode.il.dbutil.Database.initInternalDb(Database.java:198) > >>> [java] at > >>> org.apache.ode.il.dbutil.Database.initEmbeddedDb(Database.java:225) > >>> [java] at > >>> org.apache.ode.il.dbutil.Database.initDataSource(Database.java:144) > >>> [java] at org.apache.ode.il.dbutil.Database.start(Database.java:96) > >>> [java] at > >>> > org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.initPersistence(EmbeddedODEServer.java:137) > >>> [java] at > >>> > org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.init(EmbeddedODEServer.java:104) > >>> [java] at > >>> > org.apache.tuscany.sca.implementation.bpel.ode.provider.BPELImplementationProvider.start(BPELImplementationProvider.java:95) > >>> [java] at > >>> > org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:644) > >>> [java] at > >>> > org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:560) > >>> [java] at > >>> org.apache.tuscany.sca.node.impl.NodeImpl.start(NodeImpl.java:668) > >>> [java] at > >>> > org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:182) > >>> [java] at > >>> > org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.<init>(DefaultSCADomain.java:97) > >>> [java] at > >>> > org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:182) > >>> [java] at > >>> > org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:63) > >>> [java] at helloworld.BPELClient.main(BPELClient.java:33) > >>> [java] Caused by: java.lang.SecurityException: sealing violation: > >>> can't seal package org.apache.derby.iapi.services.locks: already > >>> loaded > >>> [java] at > >>> java.net.URLClassLoader.defineClass(URLClassLoader.java:235) > >>> [java] at > java.net.URLClassLoader.access$100(URLClassLoader.java:56) > >>> [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > >>> [java] at java.security.AccessController.doPrivileged(Native > Method) > >>> [java] at > java.net.URLClassLoader.findClass(URLClassLoader.java:188) > >>> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > >>> [java] at > >>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) > >>> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > >>> [java] at > >>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > >>> [java] at java.lang.Class.forName0(Native Method) > >>> [java] at java.lang.Class.forName(Class.java:164) > >>> [java] at > >>> > org.apache.derby.impl.services.monitor.BaseMonitor.getImplementations(Unknown > >>> Source) > >>> [java] at > >>> > org.apache.derby.impl.services.monitor.BaseMonitor.getDefaultImplementations(Unknown > >>> Source) > >>> [java] at > >>> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown > >>> Source) > >>> [java] at > >>> org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown > >>> Source) > >>> [java] at > >>> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown > >>> Source) > >>> [java] at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) > >>> [java] at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) > >>> [java] at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown > >>> Source) > >>> [java] ... 22 more > >>> [java] Java Result: 1 > >>> > >>> It looks like the problem is that derby code is available in multiple > >>> jars (derby and active mq) > >>> > >>> jar tvf ./lib/derby-10.3.1.4.jar > >>> 149 Wed Aug 01 06:51:56 PDT 2007 > >>> org/apache/derby/iapi/services/locks/CompatibilitySpace.class > >>> 333 Wed Aug 01 06:51:58 PDT 2007 > >>> org/apache/derby/iapi/services/locks/Latch.class > >>> 292 Wed Aug 01 06:51:58 PDT 2007 > >>> org/apache/derby/iapi/services/locks/Limit.class > >>> 1804 Wed Aug 01 06:51:56 PDT 2007 > >>> org/apache/derby/iapi/services/locks/LockFactory.class > >>> 351 Wed Aug 01 06:51:58 PDT 2007 > >>> org/apache/derby/iapi/services/locks/Lockable.class > >>> 975 Wed Aug 01 06:51:58 PDT 2007 > >>> org/apache/derby/iapi/services/locks/ShExLockable.class > >>> 590 Wed Aug 01 06:51:58 PDT 2007 > >>> org/apache/derby/iapi/services/locks/ShExQual.class > >>> > >>> jar tvf ./lib/apache-activemq-4.1.1.jar > >>> 0 Fri Jul 01 12:46:42 PDT 2005 > org/apache/derby/iapi/services/locks/ > >>> 271 Fri Jul 01 12:44:00 PDT 2005 > >>> org/apache/derby/iapi/services/locks/Latch.class > >>> 253 Fri Jul 01 12:44:00 PDT 2005 > >>> org/apache/derby/iapi/services/locks/Limit.class > >>> 1551 Fri Jul 01 12:44:00 PDT 2005 > >>> org/apache/derby/iapi/services/locks/LockFactory.class > >>> 351 Fri Jul 01 12:44:00 PDT 2005 > >>> org/apache/derby/iapi/services/locks/Lockable.class > >>> 975 Fri Jul 01 12:44:04 PDT 2005 > >>> org/apache/derby/iapi/services/locks/ShExLockable.class > >>> 590 Fri Jul 01 12:44:04 PDT 2005 > >>> org/apache/derby/iapi/services/locks/ShExQual.class > >>> > >>> > >>> On Mon, Dec 8, 2008 at 1:14 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > >>> > Dan Becker wrote: > >>> >> > >>> >> Ramkumar R wrote: > >>> >>> > >>> >>> The release artifacts for the Tuscany SCA for Java 1.4 release are > >>> >>> now > >>> >>> available, please review and vote to release. > >>> >>> > >>> >>> The artifacts are available for at: > >>> >>> http://people.apache.org/~ramkumar/tuscany/1.4RC1/<http://people.apache.org/%7Eramkumar/tuscany/1.4RC1/> > >>> >>> > >>> >>> This includes the signed binary, source distributions and eclipse > >>> >>> update > >>> >>> site and RAT report. > >>> >>> > >>> >>> Here's my +1 > >>> >>> > >>> >> > >>> >> Hi Ram, > >>> >> > >>> >> I'm withholding my vote for now. I see various problems with the > store > >>> >> tutorial. Namely when I add the 1.4 manifest to my classpath and run > >>> >> the > >>> >> store domain with: > >>> >> e:\t\tuscany-sca-1.4\tutorials\store\domain>java -jar > >>> >> ../../../modules/tuscany-node-launcher-1.4.jar domain > >>> >> > >>> >> The domain appears to start. However, when I point my browser to > >>> >> Browse to > >>> >> http://localhost:9990/ui/cloud/, I see an endless parade of > validation > >>> >> errors. Something like this: > >>> >> > >>> >> WARNING: XMLSchema validation problem in: > >>> >> jar:file:/e:/t/tuscany-sca-1.4/tutoria > >>> >> > >>> >> > >>> >> > ls/store/domain/../catalog-ejb/target/tutorial-catalog-ejb.jar!/META-INF/sca-con > >>> >> tribution.xml, line: 22, column: 4 > >>> >> cvc-complex-type.4: Attribute 'namespace' must appear on element > >>> >> 'export.java'. > >>> >> Dec 8, 2008 1:22:50 PM > >>> >> org.apache.tuscany.sca.contribution.processor.ValidatingX > >>> >> MLStreamReader$1 error > >>> >> WARNING: XMLSchema validation problem in: > >>> >> jar:file:/e:/t/tuscany-sca-1.4/tutoria > >>> >> > >>> >> > >>> >> > ls/store/domain/../catalog-ejb/target/tutorial-catalog-ejb.jar!/META-INF/sca-con > >>> >> tribution.xml, line: 23, column: 4 > >>> >> cvc-complex-type.2.4.a: Invalid content was found starting with > >>> >> element > >>> >> 'deploya > >>> >> ble'. One of '{"http://www.osoa.org/xmlns/sca/1.0":export, > >>> >> WC[##other:"http://ww > >>> >> w.osoa.org/xmlns/sca/1.0"]}' is expected. > >>> >> > >>> >> This is on Windows XP with IBM JDK 6 (build > >>> >> pwi3260sr2-20080818_01(SR2). > >>> > > >>> >> > >>> > If we need a respin to fix this, I would like to pull in r723908 > >>> > which unfortunately did not make it into the 1.4 branch until after > >>> > RC1 was produced. > >>> > > >>> > Simon > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> Luciano Resende > >>> Apache Tuscany, Apache PhotArk > >>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> > >>> http://lresende.blogspot.com/ > >> > >> > >> > >> -- > >> Thanks & Regards, > >> Ramkumar Ramalingam > > > > > > > > -- > Luciano Resende > Apache Tuscany, Apache PhotArk > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> > http://lresende.blogspot.com/ > -- Thanks & Regards, Ramkumar Ramalingam
