Re: svn commit: r1569966 - in /tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config: AppInfoBuilder.java event/BeforeAppInfoBuilderEvent.java
Did not got it locally yesterday.
Lemme give it a try again.
Jean-Louis
2014-02-20 2:27 GMT+01:00 Thiago Veronezi :
> Hi Jean-Louis,
> It looks like the BeforeAppInfoBuilderEvent class breaks the build.
>
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.543
> sec <<< FAILURE! - in org.apache.openejb.DependenceValidationTest
> testAssembler(org.apache.openejb.DependenceValidationTest) Time
> elapsed: 0.504 sec <<< FAILURE!
> junit.framework.AssertionFailedError: org.apache.openejb.config.event
> should have no dependencies on org.apache.openejb.config expected:<0>
> but was:<2>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.openejb.DependenceValidationTest.assertNotDependentOn(DependenceValidationTest.java:94)
> at
> org.apache.openejb.DependenceValidationTest.testAssembler(DependenceValidationTest.java:69)
>
>
> It has an invalid import. Can you check it out?
>
> []s,
> Thiago.
>
>
>
>
>
> On Wed, Feb 19, 2014 at 6:15 PM, wrote:
>
> > Author: jlmonteiro
> > Date: Wed Feb 19 23:15:06 2014
> > New Revision: 1569966
> >
> > URL: http://svn.apache.org/r1569966
> > Log:
> > OPENEJB-2074 add a new event before AppInfoBuilder
> >
> > Added:
> >
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java
> > - copied, changed from r1569938,
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java
> > Modified:
> >
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> >
> > Modified:
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> > URL:
> >
> http://svn.apache.org/viewvc/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java?rev=1569966&r1=1569965&r2=1569966&view=diff
> >
> >
> ==
> > ---
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> > (original)
> > +++
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> > Wed Feb 19 23:15:06 2014
> > @@ -41,6 +41,7 @@ import org.apache.openejb.assembler.clas
> > import org.apache.openejb.assembler.classic.ServletInfo;
> > import org.apache.openejb.assembler.classic.ValidatorBuilder;
> > import org.apache.openejb.assembler.classic.WebAppInfo;
> > +import org.apache.openejb.config.event.BeforeAppInfoBuilderEvent;
> > import org.apache.openejb.config.sys.Container;
> > import org.apache.openejb.config.sys.Resource;
> > import org.apache.openejb.config.sys.Service;
> > @@ -115,6 +116,10 @@ class AppInfoBuilder {
> > }
> >
> > public AppInfo build(final AppModule appModule) throws
> > OpenEJBException {
> > +// send an event so that it becomes pretty easy at this step to
> > dynamically change the module description
> > +// before going into the info tree. Pretty easy to hack on
> > portability issues.
> > +SystemInstance.get().fireEvent(new
> > BeforeAppInfoBuilderEvent(appModule));
> > +
> > final AppInfo appInfo = new AppInfo();
> > appInfo.appId = appModule.getModuleId();
> > appInfo.path = appModule.getJarLocation();
> >
> > Copied:
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java
> > (from r1569938,
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java)
> > URL:
> >
> http://svn.apache.org/viewvc/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java?p2=tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java&p1=tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java&r1=1569938&r2=1569966&rev=1569966&view=diff
> >
> >
> ==
> > ---
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java
> > (original)
> > +++
> >
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java
> > Wed Feb 19 23:15:06 2014
> > @@ -16,40 +16,23 @@
> > */
> > package org.apache.openejb.config.event;
> >
> > +import org.apache.openejb.config.AppModule;
> > import org.apache.openejb.observer.Event;
> >
> > -im
Re: svn commit: r1569966 - in /tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config: AppInfoBuilder.java event/BeforeAppInfoBuilderEvent.java
Hi Jean-Louis,
It looks like the BeforeAppInfoBuilderEvent class breaks the build.
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.543
sec <<< FAILURE! - in org.apache.openejb.DependenceValidationTest
testAssembler(org.apache.openejb.DependenceValidationTest) Time
elapsed: 0.504 sec <<< FAILURE!
junit.framework.AssertionFailedError: org.apache.openejb.config.event
should have no dependencies on org.apache.openejb.config expected:<0>
but was:<2>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.TestCase.assertEquals(TestCase.java:401)
at
org.apache.openejb.DependenceValidationTest.assertNotDependentOn(DependenceValidationTest.java:94)
at
org.apache.openejb.DependenceValidationTest.testAssembler(DependenceValidationTest.java:69)
It has an invalid import. Can you check it out?
[]s,
Thiago.
On Wed, Feb 19, 2014 at 6:15 PM, wrote:
> Author: jlmonteiro
> Date: Wed Feb 19 23:15:06 2014
> New Revision: 1569966
>
> URL: http://svn.apache.org/r1569966
> Log:
> OPENEJB-2074 add a new event before AppInfoBuilder
>
> Added:
>
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java
> - copied, changed from r1569938,
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java
> Modified:
>
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
>
> Modified:
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> URL:
> http://svn.apache.org/viewvc/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java?rev=1569966&r1=1569965&r2=1569966&view=diff
>
> ==
> ---
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> (original)
> +++
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/AppInfoBuilder.java
> Wed Feb 19 23:15:06 2014
> @@ -41,6 +41,7 @@ import org.apache.openejb.assembler.clas
> import org.apache.openejb.assembler.classic.ServletInfo;
> import org.apache.openejb.assembler.classic.ValidatorBuilder;
> import org.apache.openejb.assembler.classic.WebAppInfo;
> +import org.apache.openejb.config.event.BeforeAppInfoBuilderEvent;
> import org.apache.openejb.config.sys.Container;
> import org.apache.openejb.config.sys.Resource;
> import org.apache.openejb.config.sys.Service;
> @@ -115,6 +116,10 @@ class AppInfoBuilder {
> }
>
> public AppInfo build(final AppModule appModule) throws
> OpenEJBException {
> +// send an event so that it becomes pretty easy at this step to
> dynamically change the module description
> +// before going into the info tree. Pretty easy to hack on
> portability issues.
> +SystemInstance.get().fireEvent(new
> BeforeAppInfoBuilderEvent(appModule));
> +
> final AppInfo appInfo = new AppInfo();
> appInfo.appId = appModule.getModuleId();
> appInfo.path = appModule.getJarLocation();
>
> Copied:
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java
> (from r1569938,
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java)
> URL:
> http://svn.apache.org/viewvc/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java?p2=tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java&p1=tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java&r1=1569938&r2=1569966&rev=1569966&view=diff
>
> ==
> ---
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeDeploymentEvent.java
> (original)
> +++
> tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/event/BeforeAppInfoBuilderEvent.java
> Wed Feb 19 23:15:06 2014
> @@ -16,40 +16,23 @@
> */
> package org.apache.openejb.config.event;
>
> +import org.apache.openejb.config.AppModule;
> import org.apache.openejb.observer.Event;
>
> -import java.net.URL;
> -import java.util.Arrays;
> -
> @Event
> -public class BeforeDeploymentEvent {
> -private final URL[] urls;
> -private final ClassLoader parentClassLoader;
> +public class BeforeAppInfoBuilderEvent {
>
> -public BeforeDeploymentEvent(final URL[] files) {
> -this(files, null);
> -}
> +private final A
Re: Security releases
Agree with the possible more work, but it should be hopefully for us, isn't
it?
I mean, the main goal is to have limited changes so that customers/users
are confident in upgrading.
So, if more work for us, but less for users, the target is achieved IMHO.
JLouis
2014-02-19 21:54 GMT+01:00 Romain Manni-Bucau :
> +1 if possible (the issue will be to upgrade a lib without uprgading
> to next version, can need as much work as upgrading to trunk
> sometimes...)
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-19 20:27 GMT+01:00 Bjorn Danielsson <
> bjorn-apa...@lists.cuspycode.com>:
> > +1 for having quick and minimal effort security-only releases.
> >
> > At least for updating the latest release in cases where the
> > patch has limited impact on everything else ("minimal effort").
> >
> > --
> > Bjorn Danielsson
> > Cuspy Code AB
> >
> >
> > David Blevins wrote:
> >> So as I mentioned in the security reporting thread, although we do
> always use the most recent versions of everything in our releases, we
> should probably address our timing.
> >>
> >> Over the lifetime of TomEE we average 4.14 months between releases.
> Also in the lifetime of TomEE, there've been about 18 CVEs that affect us.
> That's one every 1.61 months.
> >>
> >> On top of that, once a new TomEE 1.x version comes out we don't really
> keep supporting the previous 1.x release, which we should -- at least for
> security fixes.
> >>
> >> - - -
> >>
> >> The fastest and most realistic way I can see to continuously turn out
> releases that contain security updates with the least amount time is to:
> >>
> >> - branch from the latest supported tags (1.5.x, 1.6.x)
> >> - apply the security patch or do the library upgrade
> >> - release them as 1.5.x.y, 1.6.x.y
> >>
> >> My gut says anything else will just encounter the usual 4 month delay.
> As well I can see there being a significant advantage to having security
> only releases:
> >>
> >> - a lot easier to do the legal screening, code header scanning, etc.
> >> - far less community time spent on rigorously testing all our
> applications
> >> - less regression testing users have to do to upgrade. (We're always
> adding new features to 1.x.y releases)
> >> - doesn't disrupt or put pressure on our development cycle
> >>
> >> With the current Tomcat CVE now fixed, that'd give us:
> >>
> >> - 1.5.2.1
> >> - 1.6.0.1
> >>
> >> Thoughts?
> >>
> >>
> >> -David
>
--
Jean-Louis
Re: LazyStopWebappClassLoader LinkageError
exactly, that's why we are responsible of most of them, in particular for cxf which is sthg we integrate Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-19 19:20 GMT+01:00 agumbrecht : > Here's a really good explanation: > http://frankkieviet.blogspot.de/2009/03/javalanglinkageerror-loader-constraint.html > > Andy. > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667902.html > Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Security releases
+1 if possible (the issue will be to upgrade a lib without uprgading
to next version, can need as much work as upgrading to trunk
sometimes...)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-19 20:27 GMT+01:00 Bjorn Danielsson :
> +1 for having quick and minimal effort security-only releases.
>
> At least for updating the latest release in cases where the
> patch has limited impact on everything else ("minimal effort").
>
> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> David Blevins wrote:
>> So as I mentioned in the security reporting thread, although we do always
>> use the most recent versions of everything in our releases, we should
>> probably address our timing.
>>
>> Over the lifetime of TomEE we average 4.14 months between releases. Also in
>> the lifetime of TomEE, there've been about 18 CVEs that affect us. That's
>> one every 1.61 months.
>>
>> On top of that, once a new TomEE 1.x version comes out we don't really keep
>> supporting the previous 1.x release, which we should -- at least for
>> security fixes.
>>
>> - - -
>>
>> The fastest and most realistic way I can see to continuously turn out
>> releases that contain security updates with the least amount time is to:
>>
>> - branch from the latest supported tags (1.5.x, 1.6.x)
>> - apply the security patch or do the library upgrade
>> - release them as 1.5.x.y, 1.6.x.y
>>
>> My gut says anything else will just encounter the usual 4 month delay. As
>> well I can see there being a significant advantage to having security only
>> releases:
>>
>> - a lot easier to do the legal screening, code header scanning, etc.
>> - far less community time spent on rigorously testing all our applications
>> - less regression testing users have to do to upgrade. (We're always
>> adding new features to 1.x.y releases)
>> - doesn't disrupt or put pressure on our development cycle
>>
>> With the current Tomcat CVE now fixed, that'd give us:
>>
>> - 1.5.2.1
>> - 1.6.0.1
>>
>> Thoughts?
>>
>>
>> -David
Re: Security releases
+1 for having quick and minimal effort security-only releases.
At least for updating the latest release in cases where the
patch has limited impact on everything else ("minimal effort").
--
Bjorn Danielsson
Cuspy Code AB
David Blevins wrote:
> So as I mentioned in the security reporting thread, although we do always use
> the most recent versions of everything in our releases, we should probably
> address our timing.
>
> Over the lifetime of TomEE we average 4.14 months between releases. Also in
> the lifetime of TomEE, there've been about 18 CVEs that affect us. That's
> one every 1.61 months.
>
> On top of that, once a new TomEE 1.x version comes out we don't really keep
> supporting the previous 1.x release, which we should -- at least for security
> fixes.
>
> - - -
>
> The fastest and most realistic way I can see to continuously turn out
> releases that contain security updates with the least amount time is to:
>
> - branch from the latest supported tags (1.5.x, 1.6.x)
> - apply the security patch or do the library upgrade
> - release them as 1.5.x.y, 1.6.x.y
>
> My gut says anything else will just encounter the usual 4 month delay. As
> well I can see there being a significant advantage to having security only
> releases:
>
> - a lot easier to do the legal screening, code header scanning, etc.
> - far less community time spent on rigorously testing all our applications
> - less regression testing users have to do to upgrade. (We're always
> adding new features to 1.x.y releases)
> - doesn't disrupt or put pressure on our development cycle
>
> With the current Tomcat CVE now fixed, that'd give us:
>
> - 1.5.2.1
> - 1.6.0.1
>
> Thoughts?
>
>
> -David
Re: svn commit: r1569795 [1/35] - in /tomee/tomee/trunk/container/openejb-core/src/main: config/pmd/ java/javax/xml/ws/ java/javax/xml/ws/wsaddressing/ java/org/apache/openejb/ java/org/apache/openejb
+1, Like it a lot ;-) Andy.
Re: Security releases
+1 looks good. Just regarding the latest digit, was wondering is we could use instead: su1, security update 1 sec01, security 01 The latest one is the more commonly used. JLouis 2014-02-19 18:08 GMT+01:00 David Blevins : > So as I mentioned in the security reporting thread, although we do always > use the most recent versions of everything in our releases, we should > probably address our timing. > > Over the lifetime of TomEE we average 4.14 months between releases. Also > in the lifetime of TomEE, there've been about 18 CVEs that affect us. > That's one every 1.61 months. > > On top of that, once a new TomEE 1.x version comes out we don't really > keep supporting the previous 1.x release, which we should -- at least for > security fixes. > > - - - > > The fastest and most realistic way I can see to continuously turn out > releases that contain security updates with the least amount time is to: > > - branch from the latest supported tags (1.5.x, 1.6.x) > - apply the security patch or do the library upgrade > - release them as 1.5.x.y, 1.6.x.y > > My gut says anything else will just encounter the usual 4 month delay. As > well I can see there being a significant advantage to having security only > releases: > > - a lot easier to do the legal screening, code header scanning, etc. > - far less community time spent on rigorously testing all our > applications > - less regression testing users have to do to upgrade. (We're always > adding new features to 1.x.y releases) > - doesn't disrupt or put pressure on our development cycle > > With the current Tomcat CVE now fixed, that'd give us: > > - 1.5.2.1 > - 1.6.0.1 > > Thoughts? > > > -David > > > > > > -- Jean-Louis
Re: LazyStopWebappClassLoader LinkageError
Here's a really good explanation: http://frankkieviet.blogspot.de/2009/03/javalanglinkageerror-loader-constraint.html Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667902.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Security releases
So as I mentioned in the security reporting thread, although we do always use the most recent versions of everything in our releases, we should probably address our timing. Over the lifetime of TomEE we average 4.14 months between releases. Also in the lifetime of TomEE, there've been about 18 CVEs that affect us. That's one every 1.61 months. On top of that, once a new TomEE 1.x version comes out we don't really keep supporting the previous 1.x release, which we should -- at least for security fixes. - - - The fastest and most realistic way I can see to continuously turn out releases that contain security updates with the least amount time is to: - branch from the latest supported tags (1.5.x, 1.6.x) - apply the security patch or do the library upgrade - release them as 1.5.x.y, 1.6.x.y My gut says anything else will just encounter the usual 4 month delay. As well I can see there being a significant advantage to having security only releases: - a lot easier to do the legal screening, code header scanning, etc. - far less community time spent on rigorously testing all our applications - less regression testing users have to do to upgrade. (We're always adding new features to 1.x.y releases) - doesn't disrupt or put pressure on our development cycle With the current Tomcat CVE now fixed, that'd give us: - 1.5.2.1 - 1.6.0.1 Thoughts? -David
Re: LazyStopWebappClassLoader LinkageError
yep, my comment was just "when you see it in tomee don't think that's it first". Geronimo uses OSGi and it happens far more often in OSGi than in normal javase. Since we filter classes it can happen as well but often we can fix it properly. That's not because adding twi int can do an overflow that you don't get the result you want because of it ;) Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-19 16:53 GMT+01:00 David Blevins : > Not exactly what I meant. Kevan Miller dug into this for a couple weeks a > couple years back as this problem happens in Geronimo as well. > > It's not really specific to any library and seems to be an issue in the VM > itself occasionally stepping on itself loading a class. I don't recall the > exact details he dug up but seem to recall there's a rare condition in which > a simple circular reference causes the JVM to try and load a class it's > already trying to load earlier in the stack. He had it pinned down to a > particular class and method, IIRC. > > It works most the time, but there was some situations where it could fail and > the only workaround was to catch the LinkageError and try again. On the > second try the class in question would be loaded so the LinkageError wouldn't > occur. > > Seems it can pop up with pretty much any flavor of child classloader. > > At least that's my vague recollection. > > > -David > > On Feb 19, 2014, at 7:29 AM, Romain Manni-Bucau wrote: > >> That's not what I meant. I was used to dig into these issues and they >> had most of the time no link at all with parallelism. Was just out >> filtering which was wrong. It can still have side effects but enhance >> so much th euser experience that we need to keep it IMO. CXF was one >> of the most common framework where we were a bit wrong. SO I strongly >> believe this is not only a synchro issue. >> >> If that's just a synchro issue we can synchronized the classloader >> (not a lock please, it doesn't bring anything) but i doubt it. >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> >> 2014-02-19 15:25 GMT+01:00 David Blevins : >>> Synchronization issues rarely are :) >>> >>> -David >>> >>> On Feb 19, 2014, at 6:01 AM, agumbrecht wrote: >>> OK, I'll dig in a bit later - And yes, it's not an 'always' thing? Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667889.html Sent from the OpenEJB Dev mailing list archive at Nabble.com. >>> >
Re: LazyStopWebappClassLoader LinkageError
Not exactly what I meant. Kevan Miller dug into this for a couple weeks a couple years back as this problem happens in Geronimo as well. It's not really specific to any library and seems to be an issue in the VM itself occasionally stepping on itself loading a class. I don't recall the exact details he dug up but seem to recall there's a rare condition in which a simple circular reference causes the JVM to try and load a class it's already trying to load earlier in the stack. He had it pinned down to a particular class and method, IIRC. It works most the time, but there was some situations where it could fail and the only workaround was to catch the LinkageError and try again. On the second try the class in question would be loaded so the LinkageError wouldn't occur. Seems it can pop up with pretty much any flavor of child classloader. At least that's my vague recollection. -David On Feb 19, 2014, at 7:29 AM, Romain Manni-Bucau wrote: > That's not what I meant. I was used to dig into these issues and they > had most of the time no link at all with parallelism. Was just out > filtering which was wrong. It can still have side effects but enhance > so much th euser experience that we need to keep it IMO. CXF was one > of the most common framework where we were a bit wrong. SO I strongly > believe this is not only a synchro issue. > > If that's just a synchro issue we can synchronized the classloader > (not a lock please, it doesn't bring anything) but i doubt it. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-19 15:25 GMT+01:00 David Blevins : >> Synchronization issues rarely are :) >> >> -David >> >> On Feb 19, 2014, at 6:01 AM, agumbrecht wrote: >> >>> OK, I'll dig in a bit later - And yes, it's not an 'always' thing? >>> >>> Andy. >>> >>> >>> >>> -- >>> View this message in context: >>> http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667889.html >>> Sent from the OpenEJB Dev mailing list archive at Nabble.com. >>
Re: Adding a security page to TomEE website
Hi all, Please find on the staging some proposals and information. http://tomee.staging.apache.org/security/ Feedback welcome so that we can start with a process and also start checking CVE. JLouis 2014-02-19 15:28 GMT+01:00 David Blevins : > Looks great so far. Filling in some details on 1.6.x and 1.5.x now. > > -David > > On Feb 19, 2014, at 3:32 AM, Jean-Louis MONTEIRO > wrote: > > > Hello guys, > > > > In regards to the discussion opened here > > > http://openejb.979440.n4.nabble.com/Security-reporting-requirements-td4667859.html > > > > I'm creating a page on our website to describe the security process. I > > mainly took inspiration from other apache projects (tomcat to name but a > > few). > > > > I will commit it without any link and push again here so that anyone is > > free to say yes or no and to comment, add additional information. > > > > -- > > Jean-Louis > > -- Jean-Louis
Re: LazyStopWebappClassLoader LinkageError
That's not what I meant. I was used to dig into these issues and they had most of the time no link at all with parallelism. Was just out filtering which was wrong. It can still have side effects but enhance so much th euser experience that we need to keep it IMO. CXF was one of the most common framework where we were a bit wrong. SO I strongly believe this is not only a synchro issue. If that's just a synchro issue we can synchronized the classloader (not a lock please, it doesn't bring anything) but i doubt it. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-19 15:25 GMT+01:00 David Blevins : > Synchronization issues rarely are :) > > -David > > On Feb 19, 2014, at 6:01 AM, agumbrecht wrote: > >> OK, I'll dig in a bit later - And yes, it's not an 'always' thing? >> >> Andy. >> >> >> >> -- >> View this message in context: >> http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667889.html >> Sent from the OpenEJB Dev mailing list archive at Nabble.com. >
Re: Adding a security page to TomEE website
Looks great so far. Filling in some details on 1.6.x and 1.5.x now. -David On Feb 19, 2014, at 3:32 AM, Jean-Louis MONTEIRO wrote: > Hello guys, > > In regards to the discussion opened here > http://openejb.979440.n4.nabble.com/Security-reporting-requirements-td4667859.html > > I'm creating a page on our website to describe the security process. I > mainly took inspiration from other apache projects (tomcat to name but a > few). > > I will commit it without any link and push again here so that anyone is > free to say yes or no and to comment, add additional information. > > -- > Jean-Louis
Re: LazyStopWebappClassLoader LinkageError
Synchronization issues rarely are :) -David On Feb 19, 2014, at 6:01 AM, agumbrecht wrote: > OK, I'll dig in a bit later - And yes, it's not an 'always' thing? > > Andy. > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667889.html > Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: LazyStopWebappClassLoader LinkageError
OK, I'll dig in a bit later - And yes, it's not an 'always' thing? Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885p4667889.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: LazyStopWebappClassLoader LinkageError
Hi
not really, this is surely a wrong usage of cxf classloader. 90% of
our linkage errors are not linked to "not luck"
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-19 14:56 GMT+01:00 David Blevins :
> These happen from time to time. Seems to be some sort of synchronization bug
> in the VM classloader.
>
> Only real cure is to try/catch(LinkageError) fairly early and simply retry.
> It always seems to work the second time.
>
> Around org.apache.tomee.catalina.LazyStopWebappClassLoader.loadClass would be
> good.
>
> Do a search for usages of LinkageError in the codebase and you'll see a
> handful of other places we've had to apply the same band-aid.
>
>
> -David
>
>
> On Feb 19, 2014, at 5:22 AM, agumbrecht wrote:
>
>> Any ideas?
>>
>> SEVERE: error invoking
>> Observer{class=com.tomitribe.wadler.wadl.WadlInstaller}
>> java.lang.LinkageError: loader constraint violation: loader (instance of
>> org/apache/tomee/catalina/LazyStopWebappClassLoader) previously initiated
>> loading for a different type with name "org/apache/cxf/message/Message"
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>> at
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> at
>> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2944)
>> at
>> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1208)
>> at
>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
>> at
>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569)
>> at
>> org.apache.tomee.catalina.LazyStopWebappClassLoader.loadClass(LazyStopWebappClassLoader.java:143)
>> at java.lang.Class.getDeclaredMethods0(Native Method)
>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
>> at java.lang.Class.privateGetPublicMethods(Class.java:2651)
>> at java.lang.Class.getMethods(Class.java:1467)
>> at
>> org.apache.cxf.jaxrs.model.AbstractResourceInfo.findContextSetterMethods(AbstractResourceInfo.java:125)
>> at
>> org.apache.cxf.jaxrs.model.AbstractResourceInfo.(AbstractResourceInfo.java:65)
>> at org.apache.cxf.jaxrs.model.ProviderInfo.(ProviderInfo.java:29)
>> at
>> org.apache.cxf.jaxrs.provider.ProviderFactory.setProviders(ProviderFactory.java:552)
>> at
>> org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:766)
>> at
>> com.tomitribe.wadler.wadl.WadlInstaller.appCreated(WadlInstaller.java:32)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>>
>>
>> Andy.
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: LazyStopWebappClassLoader LinkageError
These happen from time to time. Seems to be some sort of synchronization bug
in the VM classloader.
Only real cure is to try/catch(LinkageError) fairly early and simply retry. It
always seems to work the second time.
Around org.apache.tomee.catalina.LazyStopWebappClassLoader.loadClass would be
good.
Do a search for usages of LinkageError in the codebase and you'll see a handful
of other places we've had to apply the same band-aid.
-David
On Feb 19, 2014, at 5:22 AM, agumbrecht wrote:
> Any ideas?
>
> SEVERE: error invoking
> Observer{class=com.tomitribe.wadler.wadl.WadlInstaller}
> java.lang.LinkageError: loader constraint violation: loader (instance of
> org/apache/tomee/catalina/LazyStopWebappClassLoader) previously initiated
> loading for a different type with name "org/apache/cxf/message/Message"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2944)
> at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1208)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569)
> at
> org.apache.tomee.catalina.LazyStopWebappClassLoader.loadClass(LazyStopWebappClassLoader.java:143)
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
> at java.lang.Class.privateGetPublicMethods(Class.java:2651)
> at java.lang.Class.getMethods(Class.java:1467)
> at
> org.apache.cxf.jaxrs.model.AbstractResourceInfo.findContextSetterMethods(AbstractResourceInfo.java:125)
> at
> org.apache.cxf.jaxrs.model.AbstractResourceInfo.(AbstractResourceInfo.java:65)
> at org.apache.cxf.jaxrs.model.ProviderInfo.(ProviderInfo.java:29)
> at
> org.apache.cxf.jaxrs.provider.ProviderFactory.setProviders(ProviderFactory.java:552)
> at
> org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:766)
> at
> com.tomitribe.wadler.wadl.WadlInstaller.appCreated(WadlInstaller.java:32)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
>
>
> Andy.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
LazyStopWebappClassLoader LinkageError
Any ideas?
SEVERE: error invoking
Observer{class=com.tomitribe.wadler.wadl.WadlInstaller}
java.lang.LinkageError: loader constraint violation: loader (instance of
org/apache/tomee/catalina/LazyStopWebappClassLoader) previously initiated
loading for a different type with name "org/apache/cxf/message/Message"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2944)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1208)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569)
at
org.apache.tomee.catalina.LazyStopWebappClassLoader.loadClass(LazyStopWebappClassLoader.java:143)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
at java.lang.Class.privateGetPublicMethods(Class.java:2651)
at java.lang.Class.getMethods(Class.java:1467)
at
org.apache.cxf.jaxrs.model.AbstractResourceInfo.findContextSetterMethods(AbstractResourceInfo.java:125)
at
org.apache.cxf.jaxrs.model.AbstractResourceInfo.(AbstractResourceInfo.java:65)
at org.apache.cxf.jaxrs.model.ProviderInfo.(ProviderInfo.java:29)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.setProviders(ProviderFactory.java:552)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:766)
at
com.tomitribe.wadler.wadl.WadlInstaller.appCreated(WadlInstaller.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/LazyStopWebappClassLoader-LinkageError-tp4667885.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Adding a security page to TomEE website
Hello guys, In regards to the discussion opened here http://openejb.979440.n4.nabble.com/Security-reporting-requirements-td4667859.html I'm creating a page on our website to describe the security process. I mainly took inspiration from other apache projects (tomcat to name but a few). I will commit it without any link and push again here so that anyone is free to say yes or no and to comment, add additional information. -- Jean-Louis
