[groovy-user] Upgrading Groovy and Java on an existing application?
21 views
Skip to first unread message
nabblee
Nov 9, 2014, 6:49:56 PM11/9/14
to us...@groovy.codehaus.org
I have a pretty hefty application (about 200 classes, I would estimate) the
currently compiles with Groovy 2.0 and runs on Java 1.7.0_40.
I would like to start using Meteor for the UI, which means exposing some of
my Groovy application data using DDP. There is a Java DDP client at
https://github.com/advantageous/ddp-client-java, but it requires Java 8.
So, I'm facing the prospect of upgrading Groovy and Java, and I'm very
concerned that my application will never run again.
Should this be a smooth process, or am I asking for trouble jumping all the
way to Groovy 2.3 and Java 1.8?
Thanks for any advice, for or against. (I'm open to other suggestions
regarding Meteor DDP integration, as well.)
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663.html
Sent from the groovy - user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
currently compiles with Groovy 2.0 and runs on Java 1.7.0_40.
I would like to start using Meteor for the UI, which means exposing some of
my Groovy application data using DDP. There is a Java DDP client at
https://github.com/advantageous/ddp-client-java, but it requires Java 8.
So, I'm facing the prospect of upgrading Groovy and Java, and I'm very
concerned that my application will never run again.
Should this be a smooth process, or am I asking for trouble jumping all the
way to Groovy 2.3 and Java 1.8?
Thanks for any advice, for or against. (I'm open to other suggestions
regarding Meteor DDP integration, as well.)
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663.html
Sent from the groovy - user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Russel Winder
Nov 10, 2014, 5:29:21 AM11/10/14
to us...@groovy.codehaus.org
On Sun, 2014-11-09 at 16:46 -0700, nabblee wrote:
> I have a pretty hefty application (about 200 classes, I would estimate) the
> currently compiles with Groovy 2.0 and runs on Java 1.7.0_40.
>
> I would like to start using Meteor for the UI, which means exposing some of
> my Groovy application data using DDP. There is a Java DDP client at
> https://github.com/advantageous/ddp-client-java, but it requires Java 8.
>
> So, I'm facing the prospect of upgrading Groovy and Java, and I'm very
> concerned that my application will never run again.
>
> Should this be a smooth process, or am I asking for trouble jumping all the
> way to Groovy 2.3 and Java 1.8?
>
> Thanks for any advice, for or against. (I'm open to other suggestions
> regarding Meteor DDP integration, as well.)
Sounds to me very like, try Groovy 2.3 on Java 8 and see what happens,
> I have a pretty hefty application (about 200 classes, I would estimate) the
> currently compiles with Groovy 2.0 and runs on Java 1.7.0_40.
>
> I would like to start using Meteor for the UI, which means exposing some of
> my Groovy application data using DDP. There is a Java DDP client at
> https://github.com/advantageous/ddp-client-java, but it requires Java 8.
>
> So, I'm facing the prospect of upgrading Groovy and Java, and I'm very
> concerned that my application will never run again.
>
> Should this be a smooth process, or am I asking for trouble jumping all the
> way to Groovy 2.3 and Java 1.8?
>
> Thanks for any advice, for or against. (I'm open to other suggestions
> regarding Meteor DDP integration, as well.)
and then plan things.
Personally I would upgrade now anyway and take any hit of fixing your
application. Any other strategy just builds more and more technical
debt.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Schalk Cronj é
Nov 10, 2014, 5:35:05 AM11/10/14
to us...@groovy.codehaus.org
On 10/11/2014 15:57, Russel Winder wrote:
> On Sun, 2014-11-09 at 16:46 -0700, nabblee wrote:
>> I have a pretty hefty application (about 200 classes, I would estimate) the
>> currently compiles with Groovy 2.0 and runs on Java 1.7.0_40.
>>
>> I would like to start using Meteor for the UI, which means exposing some of
>> my Groovy application data using DDP. There is a Java DDP client at
>> https://github.com/advantageous/ddp-client-java, but it requires Java 8.
>>
>> So, I'm facing the prospect of upgrading Groovy and Java, and I'm very
>> concerned that my application will never run again.
>>
>> Should this be a smooth process, or am I asking for trouble jumping all the
>> way to Groovy 2.3 and Java 1.8?
>>
>> Thanks for any advice, for or against. (I'm open to other suggestions
>> regarding Meteor DDP integration, as well.)
> Sounds to me very like, try Groovy 2.3 on Java 8 and see what happens,
> and then plan things.
>
> Personally I would upgrade now anyway and take any hit of fixing your
> application. Any other strategy just builds more and more technical
> debt.
>
I would suggest upgrading either Groovy or Java, not both at the same
> On Sun, 2014-11-09 at 16:46 -0700, nabblee wrote:
>> I have a pretty hefty application (about 200 classes, I would estimate) the
>> currently compiles with Groovy 2.0 and runs on Java 1.7.0_40.
>>
>> I would like to start using Meteor for the UI, which means exposing some of
>> my Groovy application data using DDP. There is a Java DDP client at
>> https://github.com/advantageous/ddp-client-java, but it requires Java 8.
>>
>> So, I'm facing the prospect of upgrading Groovy and Java, and I'm very
>> concerned that my application will never run again.
>>
>> Should this be a smooth process, or am I asking for trouble jumping all the
>> way to Groovy 2.3 and Java 1.8?
>>
>> Thanks for any advice, for or against. (I'm open to other suggestions
>> regarding Meteor DDP integration, as well.)
> Sounds to me very like, try Groovy 2.3 on Java 8 and see what happens,
> and then plan things.
>
> Personally I would upgrade now anyway and take any hit of fixing your
> application. Any other strategy just builds more and more technical
> debt.
>
time and see what happens. If you have issues it will be easier to point
fingers at the culprit.
--
Schalk W. Cronjé
@ysb33r
Cédric Champeau
Nov 10, 2014, 5:40:26 AM11/10/14
to us...@groovy.codehaus.org
On 10/11/2014 11:32, Schalk Cronj é wrote:
>
>> Personally I would upgrade now anyway and take any hit of fixing your
>> application. Any other strategy just builds more and more technical
>> debt.
>>
> I would suggest upgrading either Groovy or Java, not both at the same
> time and see what happens. If you have issues it will be easier to
> point fingers at the culprit.
>
Upgrading Groovy first would be a good idea, because using Java 8 on
>
>> Personally I would upgrade now anyway and take any hit of fixing your
>> application. Any other strategy just builds more and more technical
>> debt.
>>
> I would suggest upgrading either Groovy or Java, not both at the same
> time and see what happens. If you have issues it will be easier to
> point fingers at the culprit.
>
Groovy 2.0 is deemed to fail.
--
Cédric Champeau
SpringSource - Pivotal
http://twitter.com/CedricChampeau
http://melix.github.io/blog
http://spring.io/ http://www.gopivotal.com/
Russel Winder
Nov 10, 2014, 9:08:31 AM11/10/14
to us...@groovy.codehaus.org
On Mon, 2014-11-10 at 16:02 +0530, Schalk Cronj é wrote:
[…]
More importantly though your proposal is The Right Thing To Do™.
As Cédric says though Java 7 → Java 8 first then Groovy 2.0 → 2.3.7
afterwards.
[…]
> I would suggest upgrading either Groovy or Java, not both at the same
> time and see what happens. If you have issues it will be easier to point
> fingers at the culprit.
Clearly I was thinking "Big Bang" rather than being Agile ;-)
> time and see what happens. If you have issues it will be easier to point
> fingers at the culprit.
More importantly though your proposal is The Right Thing To Do™.
As Cédric says though Java 7 → Java 8 first then Groovy 2.0 → 2.3.7
afterwards.
Cédric Champeau
Nov 10, 2014, 9:46:10 AM11/10/14
to us...@groovy.codehaus.org
As Cédric says though Java 7 → Java 8 first then Groovy 2.0 → 2.3.7
afterwards.
I actually said the opposite. If you go Java 8 first, then you will run Groovy on something which is known to be incompatible. Groovy 2.3+ only is compatible with Java 8, so it's less problematic to upgrade Groovy *then* the JDK.
Russel Winder
Nov 12, 2014, 3:11:03 AM11/12/14
to us...@groovy.codehaus.org
On Mon, 2014-11-10 at 15:43 +0100, Cédric Champeau wrote:
> > As Cédric says though Java 7 → Java 8 first then Groovy 2.0 → 2.3.7
> > afterwards.
> >
> > I actually said the opposite. If you go Java 8 first, then you will run
> Groovy on something which is known to be incompatible. Groovy 2.3+ only is
> compatible with Java 8, so it's less problematic to upgrade Groovy *then*
> the JDK.
Actually I was saying what you and Schalk were saying I just got the
> > As Cédric says though Java 7 → Java 8 first then Groovy 2.0 → 2.3.7
> > afterwards.
> >
> > I actually said the opposite. If you go Java 8 first, then you will run
> Groovy on something which is known to be incompatible. Groovy 2.3+ only is
> compatible with Java 8, so it's less problematic to upgrade Groovy *then*
> the JDK.
digits transposed.
nabblee
Nov 16, 2014, 6:02:57 PM11/16/14
to us...@groovy.codehaus.org
Well, this has been as painful as I feared. :-)
I've updated Groovy, Java, GGTS (Eclipse) on my Mac and my Ubuntu server. I
thought I was in good shape, but I hit a problem I can't get past. I am
using ObjectDB and Gpars, as well, and I've updated both those jars to the
latest versions. But I can't get past an issue with instantiating an object
that has both an @Singleton(strict=false) and an @ActiveObject annotation
(this object also happens to talk to ObjectDB). The line it's failing on is
simply
tu = TUActor.instance
And TUActor has the annotations.
Here's the stacktrace. Any idea what the problem could be? My Google
searches have been fruitless.
15:58:26.849 [main] DEBUG com.tradeunafraid.TUActor - TUActor(lee2.odb)
Exception in thread "main" java.lang.ExceptionInInitializerError
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1844)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3690)
at
org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:48)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at com.tradeunafraid.TradeUnafraid.init(TradeUnafraid.groovy:127)
at com.tradeunafraid.TradeUnafraid$init$0.callCurrent(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at com.tradeunafraid.TradeUnafraid.run(TradeUnafraid.groovy:64)
at com.tradeunafraid.TradeUnafraid$run.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at com.tradeunafraid.TradeUnafraid.main(TradeUnafraid.groovy:723)
Caused by: com.objectdb.o._PersistenceException: Failed to generate dynamic
type java.util.HashMap$Entry
at com.objectdb.o._PersistenceException.b(_PersistenceException.java:45)
at com.objectdb.o.JPE.g(JPE.java:145)
at com.objectdb.o.ERR.f(ERR.java:56)
at com.objectdb.o.OST.onObjectDBError(OST.java:596)
at com.objectdb.jpa.EMF.createEntityManager(EMF.java:260)
at javax.persistence.EntityManagerFactory$createEntityManager.call(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at com.tradeunafraid.TUActor.<init>(TUActor.groovy:53)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at
org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
at
org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:186)
at com.tradeunafraid.TUActor.<clinit>(TUActor.groovy)
... 21 more
Caused by: com.objectdb.o.UserException: Failed to generate dynamic type
java.util.HashMap$Entry
at com.objectdb.o.MSG.d(MSG.java:75)
at com.objectdb.o.ACL.d(ACL.java:167)
at com.objectdb.o.STL.g(STL.java:97)
at com.objectdb.o.TYM.findClass(TYM.java:1036)
at com.objectdb.o.ACL.loadClass(ACL.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at com.objectdb.o.TYM.ay(TYM.java:1013)
at com.objectdb.o.UTY.initSysType(UTY.java:331)
at com.objectdb.o.TYS.l(TYS.java:166)
at com.objectdb.o.TYM.ae(TYM.java:511)
at com.objectdb.o.TYM.<init>(TYM.java:194)
at com.objectdb.o.OMF.ao(OMF.java:811)
at com.objectdb.o.OMF.an(OMF.java:765)
at com.objectdb.jpa.EMF.an(EMF.java:238)
at com.objectdb.o.OMF.am(OMF.java:693)
at com.objectdb.jpa.EMF.createEntityManager(EMF.java:257)
... 36 more
Caused by: java.lang.SecurityException: Prohibited package name: java.util
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
at com.objectdb.o.ACL.d(ACL.java:155)
... 50 more
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721704.html
I've updated Groovy, Java, GGTS (Eclipse) on my Mac and my Ubuntu server. I
thought I was in good shape, but I hit a problem I can't get past. I am
using ObjectDB and Gpars, as well, and I've updated both those jars to the
latest versions. But I can't get past an issue with instantiating an object
that has both an @Singleton(strict=false) and an @ActiveObject annotation
(this object also happens to talk to ObjectDB). The line it's failing on is
simply
tu = TUActor.instance
And TUActor has the annotations.
Here's the stacktrace. Any idea what the problem could be? My Google
searches have been fruitless.
15:58:26.849 [main] DEBUG com.tradeunafraid.TUActor - TUActor(lee2.odb)
Exception in thread "main" java.lang.ExceptionInInitializerError
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1844)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3690)
at
org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:48)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at com.tradeunafraid.TradeUnafraid.init(TradeUnafraid.groovy:127)
at com.tradeunafraid.TradeUnafraid$init$0.callCurrent(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at com.tradeunafraid.TradeUnafraid.run(TradeUnafraid.groovy:64)
at com.tradeunafraid.TradeUnafraid$run.call(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at com.tradeunafraid.TradeUnafraid.main(TradeUnafraid.groovy:723)
Caused by: com.objectdb.o._PersistenceException: Failed to generate dynamic
type java.util.HashMap$Entry
at com.objectdb.o._PersistenceException.b(_PersistenceException.java:45)
at com.objectdb.o.JPE.g(JPE.java:145)
at com.objectdb.o.ERR.f(ERR.java:56)
at com.objectdb.o.OST.onObjectDBError(OST.java:596)
at com.objectdb.jpa.EMF.createEntityManager(EMF.java:260)
at javax.persistence.EntityManagerFactory$createEntityManager.call(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at com.tradeunafraid.TUActor.<init>(TUActor.groovy:53)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at
org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
at
org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:186)
at com.tradeunafraid.TUActor.<clinit>(TUActor.groovy)
... 21 more
Caused by: com.objectdb.o.UserException: Failed to generate dynamic type
java.util.HashMap$Entry
at com.objectdb.o.MSG.d(MSG.java:75)
at com.objectdb.o.ACL.d(ACL.java:167)
at com.objectdb.o.STL.g(STL.java:97)
at com.objectdb.o.TYM.findClass(TYM.java:1036)
at com.objectdb.o.ACL.loadClass(ACL.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at com.objectdb.o.TYM.ay(TYM.java:1013)
at com.objectdb.o.UTY.initSysType(UTY.java:331)
at com.objectdb.o.TYS.l(TYS.java:166)
at com.objectdb.o.TYM.ae(TYM.java:511)
at com.objectdb.o.TYM.<init>(TYM.java:194)
at com.objectdb.o.OMF.ao(OMF.java:811)
at com.objectdb.o.OMF.an(OMF.java:765)
at com.objectdb.jpa.EMF.an(EMF.java:238)
at com.objectdb.o.OMF.am(OMF.java:693)
at com.objectdb.jpa.EMF.createEntityManager(EMF.java:257)
... 36 more
Caused by: java.lang.SecurityException: Prohibited package name: java.util
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
at com.objectdb.o.ACL.d(ACL.java:155)
... 50 more
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721704.html
Sent from the groovy - user mailing list archive at Nabble.com.
Russel Winder
Nov 17, 2014, 4:09:31 AM11/17/14
to us...@groovy.codehaus.org
On Sun, 2014-11-16 at 14:24 -0700, nabblee wrote:
[..]
> tu = TUActor.instance
[…]
[..]
> tu = TUActor.instance
[…]
> Caused by: java.lang.SecurityException: Prohibited package name: java.util
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
> at com.objectdb.o.ACL.d(ACL.java:155)
> ... 50 more
Looks like someone is trying to do something a bit naughty.
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
> at com.objectdb.o.ACL.d(ACL.java:155)
> ... 50 more
Jochen Theodorou
Nov 17, 2014, 5:54:17 AM11/17/14
to us...@groovy.codehaus.org
Am 16.11.2014 22:24, schrieb nabblee:
> Well, this has been as painful as I feared. :-)
>
> I've updated Groovy, Java, GGTS (Eclipse) on my Mac and my Ubuntu server. I
> thought I was in good shape, but I hit a problem I can't get past. I am
> using ObjectDB and Gpars, as well, and I've updated both those jars to the
> latest versions. But I can't get past an issue with instantiating an object
> that has both an @Singleton(strict=false) and an @ActiveObject annotation
> (this object also happens to talk to ObjectDB). The line it's failing on is
> simply
>
> tu = TUActor.instance
>
> And TUActor has the annotations.
>
> Here's the stacktrace. Any idea what the problem could be? My Google
> searches have been fruitless.
[...]
> Well, this has been as painful as I feared. :-)
>
> I've updated Groovy, Java, GGTS (Eclipse) on my Mac and my Ubuntu server. I
> thought I was in good shape, but I hit a problem I can't get past. I am
> using ObjectDB and Gpars, as well, and I've updated both those jars to the
> latest versions. But I can't get past an issue with instantiating an object
> that has both an @Singleton(strict=false) and an @ActiveObject annotation
> (this object also happens to talk to ObjectDB). The line it's failing on is
> simply
>
> tu = TUActor.instance
>
> And TUActor has the annotations.
>
> Here's the stacktrace. Any idea what the problem could be? My Google
> searches have been fruitless.
> Caused by: com.objectdb.o._PersistenceException: Failed to generate dynamic
> type java.util.HashMap$Entry
[...]
> type java.util.HashMap$Entry
> Caused by: java.lang.SecurityException: Prohibited package name: java.util
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
> at com.objectdb.o.ACL.d(ACL.java:155)
> ... 50 more
I remember we had a problem like this with ConfigSlurper, but that seems
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
> at com.objectdb.o.ACL.d(ACL.java:155)
> ... 50 more
not to be involved here... is it possible, that TUActor is written in
Groovy and extends HashMap?
bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
nabblee
Nov 17, 2014, 10:16:40 AM11/17/14
to us...@groovy.codehaus.org
All my code is written in Groovy. TUActor does not extend HashMap, though.
This is its basic structure:
@Slf4j
@Singleton(strict=false)
@ActiveObject
class TUActor {
static String dbName = null
static EntityManagerFactory emf = null
static EntityManager em = null
// construction //////////////////
def TUActor() {
dbName = "lee2.odb"
log.debug "TUActor($dbName)"
// spin up ObjectDB
emf = Persistence.createEntityManagerFactory (dbName)
em = emf.createEntityManager()
em.setFlushMode(FlushModeType.AUTO)
ObjectDB.em = em
log.debug "TUActor construction complete"
}
// there are several @ActiveMethod method implementations below
...
}
This seems like it could be related to a change in Groovy, perhaps? Here is
what ObjectDB support said at :
/It seems that this exception is caused by having java.util.HashMap.Entry in
the list of types in your database, since apparently this internal Java 7
type is not part of Java 8.
Having this type in the database is unexpected and may be the result of a
non standard operation. Maybe you can provide more information on direct use
of java.util.HashMap.Entry in your application that might have been caused
this issue. /
Now I'm thinking the problem is not actually with TUActor but with the
objects being read from ObjectDB. Some of them certainly contain lists and
maps. So, has something changed about the Groovy implementation between 2.1
and 2.3 that could have to do with ObjectDB having problems with HashMap?
Thanks very much,
Lee
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721707.html
This is its basic structure:
@Slf4j
@Singleton(strict=false)
@ActiveObject
class TUActor {
static String dbName = null
static EntityManagerFactory emf = null
static EntityManager em = null
// construction //////////////////
def TUActor() {
dbName = "lee2.odb"
log.debug "TUActor($dbName)"
// spin up ObjectDB
emf = Persistence.createEntityManagerFactory (dbName)
em = emf.createEntityManager()
em.setFlushMode(FlushModeType.AUTO)
ObjectDB.em = em
log.debug "TUActor construction complete"
}
// there are several @ActiveMethod method implementations below
...
}
This seems like it could be related to a change in Groovy, perhaps? Here is
what ObjectDB support said at :
/It seems that this exception is caused by having java.util.HashMap.Entry in
the list of types in your database, since apparently this internal Java 7
type is not part of Java 8.
Having this type in the database is unexpected and may be the result of a
non standard operation. Maybe you can provide more information on direct use
of java.util.HashMap.Entry in your application that might have been caused
this issue. /
Now I'm thinking the problem is not actually with TUActor but with the
objects being read from ObjectDB. Some of them certainly contain lists and
maps. So, has something changed about the Groovy implementation between 2.1
and 2.3 that could have to do with ObjectDB having problems with HashMap?
Thanks very much,
Lee
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721707.html
Sent from the groovy - user mailing list archive at Nabble.com.
nabblee
Nov 19, 2014, 10:14:09 AM11/19/14
to us...@groovy.codehaus.org
Any ideas?
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721723.html
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721723.html
nabblee
Nov 25, 2014, 1:19:25 PM11/25/14
to us...@groovy.codehaus.org
In case anyone else runs into this, the good folks at ObjectDB released
2.5.7_06, which fixes this problem.
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721762.html
2.5.7_06, which fixes this problem.
--
View this message in context: http://groovy.329449.n5.nabble.com/Upgrading-Groovy-and-Java-on-an-existing-application-tp5721663p5721762.html
Reply all
Reply to author
Forward
0 new messages