Re: failures on the build (not a build failure...)
Same here under Fedora 12: ERROR - Unable to clear Sun JarFileFactory cache java.lang.ClassCastException: java.lang.String cannot be cast to java.net.URL It seems that this happens deep inside OpenEJB while evaluating a property field 'fileCache' of an internal java class. Class jarFileFactory = Class.forName(sun.net.www.protocol.jar.JarFileFactory); Field fileCacheField = jarFileFactory.getDeclaredField(fileCache); After a bit searching I found the following Jira already opened for OpenEJB: http://issues.apache.org/jira/browse/GERONIMO-5036 LieGrue, strub --- Vicky Kak vicky@gmail.com schrieb am Di, 16.3.2010: Von: Vicky Kak vicky@gmail.com Betreff: Re: failures on the build (not a build failure...) An: dev@openwebbeans.apache.org Datum: Dienstag, 16. März, 2010 05:43 Uhr I am also experiencing the similar issues INFO - Deployed Application(path=classpath.ear) DESTROY EJB INFO - Undeploying app: classpath.ear ERROR - Unable to clear Sun JarFileFactory cache java.lang.ClassCastException: java.lang.String cannot be cast to java.net.URL at org.apache.openejb.ClassLoaderUtil.clearSunJarFileFactoryCache(ClassLoaderUtil.java:173) at org.apache.openejb.ClassLoaderUtil.destroyClassLoader(ClassLoaderUtil.java:130) at org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:918) I am also on ubuntu/java1.6. -Vicky Matthias Wessendorf wrote: Hi, I watched the build (it does end with SUCCESS), but during that I saw this on the -openejb package. I thought worth to share (I am on an ubuntu machine, java1.6) java.lang.ClassCastException: java.lang.String cannot be cast to java.net.URL at org.apache.openejb.ClassLoaderUtil.clearSunJarFileFactoryCache(ClassLoaderUtil.java:173) at org.apache.openejb.ClassLoaderUtil.destroyClassLoader(ClassLoaderUtil.java:130) at org.apache.openejb.ClassLoaderUtil.destroyClassLoader(ClassLoaderUtil.java:97) at org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:185) at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:509) at org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:380) at org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:299) at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:278) at org.apache.openejb.OpenEJB$Instance.init(OpenEJB.java:137) at org.apache.openejb.OpenEJB.init(OpenEJB.java:286) at org.apache.openejb.OpenEJB.init(OpenEJB.java:265) at org.apache.webbeans.ejb.EjbTestContext.initEjb(EjbTestContext.java:41) at org.apache.webbeans.ejb.definition.scope.EjbScopeTypeTest.init(EjbScopeTypeTest.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:220) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) INFO - Beginning load: /home/matzew/work/source/Apache/openwebbeans/webbeans-openejb/target/test-classes INFO - Configuring enterprise application: classpath.ear INFO - Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) INFO - Auto-creating a container for bean SimpleBean: Container(type=STATELESS, id=Default Stateless Container) INFO - Configuring
[jira] Closed: (OWB-130) implement JSR-330 annotations for OWB
[ https://issues.apache.org/jira/browse/OWB-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed OWB-130. - already fixed in M3 implement JSR-330 annotations for OWB - Key: OWB-130 URL: https://issues.apache.org/jira/browse/OWB-130 Project: OpenWebBeans Issue Type: New Feature Components: Core Affects Versions: M3 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: M3 Since the latest spec from 2009-08-17, JSR-299 is depending on JSR-330. We should reflect this fact by introducing a new package atinject-api and add it as dependency to webbeans-api -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OWB-123) remove StereoType restrictions
[ https://issues.apache.org/jira/browse/OWB-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed OWB-123. - closed, because already fixed in M3 remove StereoType restrictions -- Key: OWB-123 URL: https://issues.apache.org/jira/browse/OWB-123 Project: OpenWebBeans Issue Type: Bug Affects Versions: M2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: M3 StereoType restrictions have been removed from the spec. So we should also remove the checks from our code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Jira cleanup
Hi folks! I now closed all issues which got resolved in M2, M3 or M4, so our 'resolved' list should now only show issues which are done for the next release. LieGrue, strub __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Re: [jira] Created: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory
Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. As you said, you must not define interceptors as ApplicationScoped otherwise behaviour is undefined. Thanks; --Gurkan 2010/3/16 Mark Struberg (JIRA) j...@apache.org annotating an Interceptor with @ApplictionScoped leads to OutOfMemory - Key: OWB-327 URL: https://issues.apache.org/jira/browse/OWB-327 Project: OpenWebBeans Issue Type: Bug Affects Versions: M4 Reporter: Mark Struberg Assignee: Gurkan Erdogdu Priority: Critical Fix For: 1.0.0 If you write an Interceptor and manually annotate it @ApplicationScoped then the memory will get used up until a OOME. Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Re: [jira] Created: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory
Yes, I've now also checked with jboss folks and there seems to be no further restriction other than it's not a good idea ;) I think we should drop the scope and log a warning, wdyt? To consume up memory is at least not a good idea ;) LieGrue, strub --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Di, 16.3.2010: Von: Gurkan Erdogdu cgurkanerdo...@gmail.com Betreff: Re: [jira] Created: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory An: dev@openwebbeans.apache.org Datum: Dienstag, 16. März, 2010 19:14 Uhr Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. As you said, you must not define interceptors as ApplicationScoped otherwise behaviour is undefined. Thanks; --Gurkan 2010/3/16 Mark Struberg (JIRA) j...@apache.org annotating an Interceptor with @ApplictionScoped leads to OutOfMemory - Key: OWB-327 URL: https://issues.apache.org/jira/browse/OWB-327 Project: OpenWebBeans Issue Type: Bug Affects Versions: M4 Reporter: Mark Struberg Assignee: Gurkan Erdogdu Priority: Critical Fix For: 1.0.0 If you write an Interceptor and manually annotate it @ApplicationScoped then the memory will get used up until a OOME. Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Re: [jira] Created: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory
think we should drop the scope and log a warning, wdyt? Yea, good idea! From: Mark Struberg strub...@yahoo.de To: dev@openwebbeans.apache.org Sent: Tue, March 16, 2010 8:22:54 PM Subject: Re: [jira] Created: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory Yes, I've now also checked with jboss folks and there seems to be no further restriction other than it's not a good idea ;) I think we should drop the scope and log a warning, wdyt? To consume up memory is at least not a good idea ;) LieGrue, strub --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Di, 16.3.2010: Von: Gurkan Erdogdu cgurkanerdo...@gmail.com Betreff: Re: [jira] Created: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory An: dev@openwebbeans.apache.org Datum: Dienstag, 16. März, 2010 19:14 Uhr Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. As you said, you must not define interceptors as ApplicationScoped otherwise behaviour is undefined. Thanks; --Gurkan 2010/3/16 Mark Struberg (JIRA) j...@apache.org annotating an Interceptor with @ApplictionScoped leads to OutOfMemory - Key: OWB-327 URL: https://issues.apache.org/jira/browse/OWB-327 Project: OpenWebBeans Issue Type: Bug Affects Versions: M4 Reporter: Mark Struberg Assignee: Gurkan Erdogdu Priority: Critical Fix For: 1.0.0 If you write an Interceptor and manually annotate it @ApplicationScoped then the memory will get used up until a OOME. Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
[jira] Commented: (OWB-327) annotating an Interceptor with @ApplictionScoped leads to OutOfMemory
[ https://issues.apache.org/jira/browse/OWB-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846085#action_12846085 ] Mark Struberg commented on OWB-327: --- spec section 2.4.1 states that If an interceptor or decorator has any scope other than @Dependent, non-portable behaviour results. We should drop any other scope than @Dependent and log a warning in such a case. annotating an Interceptor with @ApplictionScoped leads to OutOfMemory - Key: OWB-327 URL: https://issues.apache.org/jira/browse/OWB-327 Project: OpenWebBeans Issue Type: Bug Affects Versions: M4 Reporter: Mark Struberg Assignee: Gurkan Erdogdu Priority: Critical Fix For: 1.0.0 If you write an Interceptor and manually annotate it @ApplicationScoped then the memory will get used up until a OOME. Please note that an Interceptor is per definition @Dependent scoped as of section 6.4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OWB-328) improve logger performance
[ https://issues.apache.org/jira/browse/OWB-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OWB-328. --- Resolution: Fixed improve logger performance -- Key: OWB-328 URL: https://issues.apache.org/jira/browse/OWB-328 Project: OpenWebBeans Issue Type: Improvement Affects Versions: M4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0 currently we always perform all the message preparation like getStackTrace() etc, even if the loglevel doesn't meet the needs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OWB-329) Interceptor instances get created each time the interceptor gets called
Interceptor instances get created each time the interceptor gets called --- Key: OWB-329 URL: https://issues.apache.org/jira/browse/OWB-329 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: M4 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Critical Fix For: 1.0.0 Interceptors are defined as being @Dependent scoped. Thus, for one @ApplicationScoped contextual instance, only one interceptor instance of a certain type must exist. But we currently create a new instance for each and every method invocation which is intercepted. This is not only terribly slow, but also doesn't work as expected from a portable perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: failures on the build (not a build failure...)
oh, cool - thx for digging! -Matthias On Tue, Mar 16, 2010 at 1:49 AM, Mark Struberg strub...@yahoo.de wrote: Same here under Fedora 12: ERROR - Unable to clear Sun JarFileFactory cache java.lang.ClassCastException: java.lang.String cannot be cast to java.net.URL It seems that this happens deep inside OpenEJB while evaluating a property field 'fileCache' of an internal java class. Class jarFileFactory = Class.forName(sun.net.www.protocol.jar.JarFileFactory); Field fileCacheField = jarFileFactory.getDeclaredField(fileCache); After a bit searching I found the following Jira already opened for OpenEJB: http://issues.apache.org/jira/browse/GERONIMO-5036 LieGrue, strub --- Vicky Kak vicky@gmail.com schrieb am Di, 16.3.2010: Von: Vicky Kak vicky@gmail.com Betreff: Re: failures on the build (not a build failure...) An: dev@openwebbeans.apache.org Datum: Dienstag, 16. März, 2010 05:43 Uhr I am also experiencing the similar issues INFO - Deployed Application(path=classpath.ear) DESTROY EJB INFO - Undeploying app: classpath.ear ERROR - Unable to clear Sun JarFileFactory cache java.lang.ClassCastException: java.lang.String cannot be cast to java.net.URL at org.apache.openejb.ClassLoaderUtil.clearSunJarFileFactoryCache(ClassLoaderUtil.java:173) at org.apache.openejb.ClassLoaderUtil.destroyClassLoader(ClassLoaderUtil.java:130) at org.apache.openejb.assembler.classic.Assembler.destroyApplication(Assembler.java:918) I am also on ubuntu/java1.6. -Vicky Matthias Wessendorf wrote: Hi, I watched the build (it does end with SUCCESS), but during that I saw this on the -openejb package. I thought worth to share (I am on an ubuntu machine, java1.6) java.lang.ClassCastException: java.lang.String cannot be cast to java.net.URL at org.apache.openejb.ClassLoaderUtil.clearSunJarFileFactoryCache(ClassLoaderUtil.java:173) at org.apache.openejb.ClassLoaderUtil.destroyClassLoader(ClassLoaderUtil.java:130) at org.apache.openejb.ClassLoaderUtil.destroyClassLoader(ClassLoaderUtil.java:97) at org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:185) at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:509) at org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:380) at org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:299) at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:278) at org.apache.openejb.OpenEJB$Instance.init(OpenEJB.java:137) at org.apache.openejb.OpenEJB.init(OpenEJB.java:286) at org.apache.openejb.OpenEJB.init(OpenEJB.java:265) at org.apache.webbeans.ejb.EjbTestContext.initEjb(EjbTestContext.java:41) at org.apache.webbeans.ejb.definition.scope.EjbScopeTypeTest.init(EjbScopeTypeTest.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:220) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) INFO - Beginning load: /home/matzew/work/source/Apache/openwebbeans/webbeans-openejb/target/test-classes INFO - Configuring enterprise application: classpath.ear INFO - Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) INFO - Auto-creating
