You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2008/12/09 08:24:07 UTC

[1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

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 <na...@apache.org> 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/
>>>
>>> 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://lresende.blogspot.com/

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by Ramkumar R <ra...@gmail.com>.
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 <lu...@gmail.com>wrote:

> On Tue, Dec 9, 2008 at 2:49 AM, ant elder <an...@gmail.com> 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 <ra...@gmail.com>
> 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 <lu...@gmail.com>
> >> 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 <na...@apache.org> 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

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by Ramkumar R <ra...@gmail.com>.
Thanks Luciano for taking care of this one.

On Wed, Dec 10, 2008 at 2:21 PM, Luciano Resende <lu...@gmail.com>wrote:

> I have locally moved all ActiveMQ dependencies to 5.1.0  and with
> that, the BPEL helloworld sample works fine. I can give a quick try to
> have 5.2.0 and commit the changes in the morning my time...
>
> On Wed, Dec 10, 2008 at 12:43 AM, ant elder <an...@gmail.com> wrote:
> >
> >
> > On Wed, Dec 10, 2008 at 7:08 AM, Luciano Resende <lu...@gmail.com>
> > wrote:
> >> On Tue, Dec 9, 2008 at 2:49 AM, ant elder <an...@gmail.com> 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 ?
> >>
> >
> > Whether or not it happens for 1.4 I don't know of any reason we couldn't
> > move up to a consistent use of 5.2.0. I think the mixture just happened
> over
> > time as people used which ever was current. There is an issue using SCA
> > callbacks with JMS temporary destinations with AMQ 4.1.1 which is fixed
> in
> > 5.x so moving up would avoid any issues with that.
> >
> >   ...ant
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by Luciano Resende <lu...@gmail.com>.
I have locally moved all ActiveMQ dependencies to 5.1.0  and with
that, the BPEL helloworld sample works fine. I can give a quick try to
have 5.2.0 and commit the changes in the morning my time...

On Wed, Dec 10, 2008 at 12:43 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Wed, Dec 10, 2008 at 7:08 AM, Luciano Resende <lu...@gmail.com>
> wrote:
>> On Tue, Dec 9, 2008 at 2:49 AM, ant elder <an...@gmail.com> 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 ?
>>
>
> Whether or not it happens for 1.4 I don't know of any reason we couldn't
> move up to a consistent use of 5.2.0. I think the mixture just happened over
> time as people used which ever was current. There is an issue using SCA
> callbacks with JMS temporary destinations with AMQ 4.1.1 which is fixed in
> 5.x so moving up would avoid any issues with that.
>
>   ...ant
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by ant elder <an...@gmail.com>.
On Wed, Dec 10, 2008 at 7:08 AM, Luciano Resende <lu...@gmail.com>
wrote:
> On Tue, Dec 9, 2008 at 2:49 AM, ant elder <an...@gmail.com> 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 ?
>

Whether or not it happens for 1.4 I don't know of any reason we couldn't
move up to a consistent use of 5.2.0. I think the mixture just happened over
time as people used which ever was current. There is an issue using SCA
callbacks with JMS temporary destinations with AMQ 4.1.1 which is fixed in
5.x so moving up would avoid any issues with that.

  ...ant

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Dec 9, 2008 at 2:49 AM, ant elder <an...@gmail.com> 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 <ra...@gmail.com> 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 <lu...@gmail.com>
>> 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 <na...@apache.org> 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/
>>> >>>
>>> >>> 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://lresende.blogspot.com/
>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by ant elder <an...@gmail.com>.
Another fix could be to move up to one of the ActiveMQ 5.x jars which don't
include derby.

   ...ant

On Tue, Dec 9, 2008 at 8:47 AM, Ramkumar R <ra...@gmail.com> 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.
>
>
> On Tue, Dec 9, 2008 at 12:54 PM, Luciano Resende <lu...@gmail.com>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 <na...@apache.org> 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
>

Re: [1.4] Derby related issues in BPEL samples (side effect from ActiveMQ dependencies), was Re: [VOTE] Release Tuscany Java SCA 1.4 (RC1)

Posted by Ramkumar R <ra...@gmail.com>.
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.

On Tue, Dec 9, 2008 at 12:54 PM, Luciano Resende <lu...@gmail.com>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 <na...@apache.org> 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