[jira] [Created] (GERONIMO-6065) OpenJPA 2.1.1-SNAPSHOT
OpenJPA 2.1.1-SNAPSHOT -- Key: GERONIMO-6065 URL: https://issues.apache.org/jira/browse/GERONIMO-6065 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6067) MyFaces 2.0.8-SNAPSHOT
MyFaces 2.0.8-SNAPSHOT -- Key: GERONIMO-6067 URL: https://issues.apache.org/jira/browse/GERONIMO-6067 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6066) OpenEJB 4.0.0-SNAPSHOT
OpenEJB 4.0.0-SNAPSHOT -- Key: GERONIMO-6066 URL: https://issues.apache.org/jira/browse/GERONIMO-6066 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6063) Yoko 1.2-SNAPSHOT
Yoko 1.2-SNAPSHOT - Key: GERONIMO-6063 URL: https://issues.apache.org/jira/browse/GERONIMO-6063 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6061) Geronimo 3.0 trunk SNAPSHOT dependencies
Geronimo 3.0 trunk SNAPSHOT dependencies Key: GERONIMO-6061 URL: https://issues.apache.org/jira/browse/GERONIMO-6061 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Reporter: David Blevins Fix For: 3.0-M2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6062) XBean 3.8-SNAPSHOT
XBean 3.8-SNAPSHOT -- Key: GERONIMO-6062 URL: https://issues.apache.org/jira/browse/GERONIMO-6062 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6033) testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6033. - Resolution: Won't Fix This will go away with the merge of David Jencks' OSGi friendly code that always uses OpenEJB with OpenWebBeans and CDI. > testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest) > - > > Key: GERONIMO-6033 > URL: https://issues.apache.org/jira/browse/GERONIMO-6033 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6032) testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6032. - Resolution: Fixed > testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest) > -- > > Key: GERONIMO-6032 > URL: https://issues.apache.org/jira/browse/GERONIMO-6032 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6052) testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6052: --- Assignee: David Blevins > testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > --- > > Key: GERONIMO-6052 > URL: https://issues.apache.org/jira/browse/GERONIMO-6052 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6053) testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6053. - Resolution: Fixed Assignee: David Blevins > testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > - > > Key: GERONIMO-6053 > URL: https://issues.apache.org/jira/browse/GERONIMO-6053 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6056) testDestroyRemovesSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6056. - Resolution: Fixed Assignee: David Blevins > testDestroyRemovesSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > -- > > Key: GERONIMO-6056 > URL: https://issues.apache.org/jira/browse/GERONIMO-6056 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6052) testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6052. - Resolution: Fixed > testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > --- > > Key: GERONIMO-6052 > URL: https://issues.apache.org/jira/browse/GERONIMO-6052 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: openejb-jar-2.2.xsd out-of-date?
Looks like a pretty small change. If it is more accurate than what is there now, I don't see a reason not to commit it. I'm not sure what help you need, but if there is something, definitely let me know. Not sure I have time to do any development in the area, but can do my best to get any info you might need. -David On Jul 7, 2011, at 6:36 PM, han hongfang wrote: > Oops~ incorrect version was attached. I have updated it with the diff version > in JIRA system. > > On Fri, Jul 8, 2011 at 6:53 AM, David Blevins wrote: > > On Jul 7, 2011, at 1:18 AM, han hongfang wrote: > > > I Created a JIRA in Geronimo and attached the patch: > > https://issues.apache.org/jira/browse/GERONIMO-6050 > > > > To David Blevins, > > > > Could you kindly help to review the patch and update accordingly in openejb > > side if necessary? > > A diff would be easier to review, but it probably isn't necessary -- if > something isn't right we can continue to fix it. No trouble. > > If it is more accurate than what is there now, I don't see a reason not to > commit it. > > > -David > > > > > -- > Best regards, > > Han Hong Fang (Janet) > hanhongfang AT apache.org > >
[jira] [Commented] (GERONIMO-6056) testDestroyRemovesSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061762#comment-13061762 ] David Blevins commented on GERONIMO-6056: - Regression caused by GERONIMO-6035. The fix for GERONIMO-6035 is very valid so these likely fail for legitimate reasons. Will investigate. > testDestroyRemovesSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > -- > > Key: GERONIMO-6056 > URL: https://issues.apache.org/jira/browse/GERONIMO-6056 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6056) testDestroyRemovesSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
testDestroyRemovesSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) -- Key: GERONIMO-6056 URL: https://issues.apache.org/jira/browse/GERONIMO-6056 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6053) testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins updated GERONIMO-6053: Comment: was deleted (was: Regression caused by GERONIMO-6035. The fix for GERONIMO-6035 is very valid so these likely fail for legitimate reasons. Will investigate.) > testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > - > > Key: GERONIMO-6053 > URL: https://issues.apache.org/jira/browse/GERONIMO-6053 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6052) testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061731#comment-13061731 ] David Blevins commented on GERONIMO-6052: - Regression caused by GERONIMO-6035. The fix for GERONIMO-6035 is very valid so these likely fail for legitimate reasons. Will investigate. > testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > --- > > Key: GERONIMO-6052 > URL: https://issues.apache.org/jira/browse/GERONIMO-6052 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6053) testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061732#comment-13061732 ] David Blevins commented on GERONIMO-6053: - Regression caused by GERONIMO-6035. The fix for GERONIMO-6035 is very valid so these likely fail for legitimate reasons. Will investigate. > testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > - > > Key: GERONIMO-6053 > URL: https://issues.apache.org/jira/browse/GERONIMO-6053 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6053) testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061733#comment-13061733 ] David Blevins commented on GERONIMO-6053: - Regression caused by GERONIMO-6035. The fix for GERONIMO-6035 is very valid so these likely fail for legitimate reasons. Will investigate. > testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) > - > > Key: GERONIMO-6053 > URL: https://issues.apache.org/jira/browse/GERONIMO-6053 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6053) testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
testDestroyingEjbDestroysDependents(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) - Key: GERONIMO-6053 URL: https://issues.apache.org/jira/browse/GERONIMO-6053 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6052) testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest)
testDestroyingEjbDestroysDependentSimples(org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest) --- Key: GERONIMO-6052 URL: https://issues.apache.org/jira/browse/GERONIMO-6052 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6035) testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodT
[ https://issues.apache.org/jira/browse/GERONIMO-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6035. - Resolution: Fixed > testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodTest) > -- > > Key: GERONIMO-6035 > URL: https://issues.apache.org/jira/browse/GERONIMO-6035 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: openejb-jar-2.2.xsd out-of-date?
On Jul 7, 2011, at 1:18 AM, han hongfang wrote: > I Created a JIRA in Geronimo and attached the patch: > https://issues.apache.org/jira/browse/GERONIMO-6050 > > To David Blevins, > > Could you kindly help to review the patch and update accordingly in openejb > side if necessary? A diff would be easier to review, but it probably isn't necessary -- if something isn't right we can continue to fix it. No trouble. If it is more accurate than what is there now, I don't see a reason not to commit it. -David
[jira] [Resolved] (GERONIMO-6036) testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDef
[ https://issues.apache.org/jira/browse/GERONIMO-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6036. - Resolution: Fixed > testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest) > -- > > Key: GERONIMO-6036 > URL: https://issues.apache.org/jira/browse/GERONIMO-6036 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6034) testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6034. - Resolution: Fixed > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > - > > Key: GERONIMO-6034 > URL: https://issues.apache.org/jira/browse/GERONIMO-6034 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6037) testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6037. - Resolution: Fixed > testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest) > - > > Key: GERONIMO-6037 > URL: https://issues.apache.org/jira/browse/GERONIMO-6037 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6036) testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDef
[ https://issues.apache.org/jira/browse/GERONIMO-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6036: --- Assignee: David Blevins > testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest) > -- > > Key: GERONIMO-6036 > URL: https://issues.apache.org/jira/browse/GERONIMO-6036 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release Connector/Transaction components
On Jul 5, 2011, at 11:29 AM, Jacek Laskowski wrote: > On Thu, Jun 30, 2011 at 12:26 PM, Jacek Laskowski > wrote: > >> It's been a while since I was more active wrt Geronimo and there's a >> chance to change it - I may run the release process if no one objects. > > Hi, > > No one raised your hand to object or accept my offer, so I'm taking it on. > > As I understood it's to release > https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/. Doing both would be fine, but it's this one that is needed for OpenEJB 3.2: http://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.2/ -David
[jira] [Assigned] (GERONIMO-6034) testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6034: --- Assignee: David Blevins > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > - > > Key: GERONIMO-6034 > URL: https://issues.apache.org/jira/browse/GERONIMO-6034 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6034) testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058165#comment-13058165 ] David Blevins commented on GERONIMO-6034: - Passing in OpenEJB, still haven't identified the cause in Geronimo. Related to the testPassivationOfEjbs() > testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) > - > > Key: GERONIMO-6034 > URL: https://issues.apache.org/jira/browse/GERONIMO-6034 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6037) testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058162#comment-13058162 ] David Blevins commented on GERONIMO-6037: - Passing in OpenEJB, still haven't identified the cause in Geronimo. > testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest) > - > > Key: GERONIMO-6037 > URL: https://issues.apache.org/jira/browse/GERONIMO-6037 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6037) testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6037: --- Assignee: David Blevins > testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest) > - > > Key: GERONIMO-6037 > URL: https://issues.apache.org/jira/browse/GERONIMO-6037 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (GERONIMO-6039) testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058158#comment-13058158 ] David Blevins edited comment on GERONIMO-6039 at 7/1/11 12:54 AM: -- Fails in both OpenEJB and Geronimo. Should be an easy fix for Geronimo. We simply need to construct and populate a limited version of ManagedBean -- anything that extends AbstractInjectionTargetBean really, populate the injection target information, then call: - injectFields(..) - injectMethods(..) - injectSuperFields(..) - injectSuperMethods(..) was (Author: dblevins): Fails in both OpenEJB and Geronimo. Should be an easy fix for Geronimo. > testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest) > -- > > Key: GERONIMO-6039 > URL: https://issues.apache.org/jira/browse/GERONIMO-6039 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6039) testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058158#comment-13058158 ] David Blevins commented on GERONIMO-6039: - Fails in both OpenEJB and Geronimo. Should be an easy fix for Geronimo. > testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest) > -- > > Key: GERONIMO-6039 > URL: https://issues.apache.org/jira/browse/GERONIMO-6039 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6036) testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDe
[ https://issues.apache.org/jira/browse/GERONIMO-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058157#comment-13058157 ] David Blevins commented on GERONIMO-6036: - Fails in both OpenEJB and Geronimo > testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest) > -- > > Key: GERONIMO-6036 > URL: https://issues.apache.org/jira/browse/GERONIMO-6036 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6038) testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonCo
[ https://issues.apache.org/jira/browse/GERONIMO-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058155#comment-13058155 ] David Blevins commented on GERONIMO-6038: - This appears to be an issue with scanning CDI beans and the GeronimoResourceInjectionService. It's a bare bean with no other annotations other than @EJB. We currently only scan for beans annotated with @Produces then we scan those classes for @Resource and @EJB, etc. We just need to widen our scope. Not too tricky as the xbean-finder code has been in proved so that we can get a list of all the possible CDI beans. We just need to scan that regardless of if @Produces is used. > testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest) > -- > > Key: GERONIMO-6038 > URL: https://issues.apache.org/jira/browse/GERONIMO-6038 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins >Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6032) testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058151#comment-13058151 ] David Blevins commented on GERONIMO-6032: - Have this working in my copy but results in 4 new failures (was 50+ then 20+ now is 4.. still hacking). > testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest) > -- > > Key: GERONIMO-6032 > URL: https://issues.apache.org/jira/browse/GERONIMO-6032 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6033) testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058150#comment-13058150 ] David Blevins commented on GERONIMO-6033: - Works in OpenEJB trunk code with the embedded setup. > testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest) > - > > Key: GERONIMO-6033 > URL: https://issues.apache.org/jira/browse/GERONIMO-6033 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6035) testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodT
[ https://issues.apache.org/jira/browse/GERONIMO-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6035: --- Assignee: David Blevins > testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodTest) > -- > > Key: GERONIMO-6035 > URL: https://issues.apache.org/jira/browse/GERONIMO-6035 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6032) testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6032: --- Assignee: David Blevins > testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest) > -- > > Key: GERONIMO-6032 > URL: https://issues.apache.org/jira/browse/GERONIMO-6032 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6036) testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefi
testNonStaticProducerMethodInheritedBySpecializingSubclass(org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest) -- Key: GERONIMO-6036 URL: https://issues.apache.org/jira/browse/GERONIMO-6036 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6038) testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonCont
testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest) -- Key: GERONIMO-6038 URL: https://issues.apache.org/jira/browse/GERONIMO-6038 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6038) testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonCon
[ https://issues.apache.org/jira/browse/GERONIMO-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins reassigned GERONIMO-6038: --- Assignee: David Blevins > testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest) > -- > > Key: GERONIMO-6038 > URL: https://issues.apache.org/jira/browse/GERONIMO-6038 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6039) testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest)
testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest) -- Key: GERONIMO-6039 URL: https://issues.apache.org/jira/browse/GERONIMO-6039 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6037) testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest)
testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest) - Key: GERONIMO-6037 URL: https://issues.apache.org/jira/browse/GERONIMO-6037 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6032) testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)
testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest) -- Key: GERONIMO-6032 URL: https://issues.apache.org/jira/browse/GERONIMO-6032 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6033) testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)
testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest) - Key: GERONIMO-6033 URL: https://issues.apache.org/jira/browse/GERONIMO-6033 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6035) testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodTe
testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodTest) -- Key: GERONIMO-6035 URL: https://issues.apache.org/jira/browse/GERONIMO-6035 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6034) testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) - Key: GERONIMO-6034 URL: https://issues.apache.org/jira/browse/GERONIMO-6034 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6031) Remaining JCDI Failures
Remaining JCDI Failures --- Key: GERONIMO-6031 URL: https://issues.apache.org/jira/browse/GERONIMO-6031 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6029) Upgrade slf4j api version to one that correctly does not require the impl
Upgrade slf4j api version to one that correctly does not require the impl - Key: GERONIMO-6029 URL: https://issues.apache.org/jira/browse/GERONIMO-6029 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Reporter: David Blevins Assignee: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Snapshots
On Mar 10, 2011, at 1:43 AM, Mark Struberg wrote: > Not sure if we like to do that. Of course it would be easier to handle, but > this might break geronimo snapshot releases which assume that a current SPI > doesn't got changed. > > I think we can leave it as is with our manual deploys. This way, we have the > opportunity to tell the geronimo guys that something will change before we > break their build ;) > > @geronimo folks, what is your opinion? Now that we have CI systems setup for both Geronimo and OpenEJB we're getting a fair amount of build failures due to out of date OWB snaps. Who has access to setup the OWB snapshots to automatically publish? -David > --- On Thu, 3/10/11, David Blevins wrote: > >> From: David Blevins >> Subject: Snapshots >> To: d...@openwebbeans.apache.org >> Date: Thursday, March 10, 2011, 1:06 AM >> Does our hudson setup deploy >> snapshots? If not I could set that up in >> buildbot. It's possible in buildbot to have it only >> deploy after a successful 'mvn clean install' >> >> -David >> >> >> >> > > >
Re: [DISCUSSION] How to bind and locate global JNDI for datasource.
On Jun 17, 2011, at 3:25 AM, Shawn Jiang wrote: > Here are what I tried: > > 1, use openejb remote jndi system to bind DS object with moduleId > "openejb/global". I added a DataSource service tracker in EjbDaemonGBean to > listen DS service to complete this step. > 2, I tried to use fall back to remoteInitialContext lookup in RootContext. > 3, I found that JndiRequestHandler can only handle > "org.apache.commons.dbcp.BasicDataSource" type DS. It can't handle > TranqlDataSource used in geronimo. My gut says we'll probably have to handle global DataSources vs global EJB lookups differently. For the non-global JNDI lookups the AppClient would use the Geronimo built JNDI and that would have all the datasource, jms connection factory, topic, queue, and other resources bound into it. The EJB names were built by Geronimo but were really just links that resulted in the OpenEJB JNDI being used to look those up via different names (the openejb/Deployment names). Seems like we need a way to leverage that here. Is this code running in the AppClient container or as a bare plain java se client? -David
Re: [DISCUSSION] How to bring server global/app context to applient context ?
On Jun 12, 2011, at 2:53 AM, Shawn Jiang wrote:
> For leveraging openejb remote jndi system idea, I thought about it, to
> add "global/app xxx" "openejb/deployment/xxx" mapping in openejb so that
> when a jndi request comes, openejb could return the requested object with
> following path
>
> java:global/x name > "openejb/deployment/" name ---> ejb proxy
> object.
In that regard we sort of have a global tree already -- was never finished, but
will get us by. Implemented a quick 'global' lookup ability in the
o.a.openejb.ejbd.JndiRequestHandler
It basically assumes all names that start with "global" are global names and
directs the call to the "first" global namespace.
Typically we've been using the "moduleId" request parameter to redirect calls
to other contexts. We can leverage that for global/app lookups as well if it
makes things easier.
Don't know if we want to use it, but it's there if we do.
> But we still need to handle the client side, how do we wrap the java:global
> and java:app jndi lookup with something like ClientEjbReference so that it
> could genereate a remote openejb jndi request in initialContext.lookup()
> automatically ? And we need to bind a environment entries binding copy to
> openejb jndi ?
Not sure on this one either. If we're using xbean-naming on the client we
could maybe use a federated context to delegate all unsuccessful "global"
lookups to the OpenEJB client context.
-David
> On Sun, Jun 12, 2011 at 2:51 PM, David Jencks wrote:
> I think we should use the openejb remote jndi system. We might need to
> modify it. AFAIK the only things it makes sense to get to the app client are
> environment entries and remote ejbs.
>
>
> thanks
> david jencks
>
>
> On Jun 11, 2011, at 8:28 PM, Shawn Jiang wrote:
>
> > Curretly, we only include the ear global and app context to application
> > client context. because applient is running in different VM other than
> > server itself. As a result, you can't use JNDI lookup to get the server
> > global/app reference in appclient.
> >
> > Sure we want to add the global and app context in whole server to appclient
> > module. Currently, following code was used to create the app client
> > context at build time.
> >
> > --
> >
> > org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(EARContext,
> > Module, Bundle, Collection) {
> >
> >
> > AbstractName jndiContextName =
> > earContext.getNaming().createChildName(appClientDeploymentContext.getModuleName(),
> > "StaticJndiContext", "StaticJndiContext");
> > GBeanData jndiContextGBeanData = new GBeanData(jndiContextName,
> > StaticJndiContextPlugin.class);
> > jndiContextGBeanData.setAttribute("context",
> > appClientModule.getJndiContext());
> > ..
> >
> > }
> >
> > ---
> >
> >
> > Can anyone shed some light on how to bring server global/app context to
> > applient context ?
> >
> > --
> > Shawn
>
>
>
>
> --
> Shawn
Re: Opening up xbean svn access (Fwd: Jar listing performance)
On Jun 9, 2011, at 5:04 AM, Kevan Miller wrote: > > On Jun 9, 2011, at 2:21 AM, David Blevins wrote: > >> >> On Jun 8, 2011, at 9:36 PM, David Blevins wrote: >> >>> I and pretty much everyone with dual OpenEJB/Geronimo commit is likely way >>> too busy to commit this patch (XBEAN-176). >> >> Ended up having to make CDI related change to xbean and cleared out this >> patch. We should still consider opening things up though. > > Let's definitely keep an eye on things. Have there been problems getting > patches applied? Nah it's just been steadily shrinking. Instead of putting good things in, people just take them out. I've watched the finder code get forked a few times and it will likely happen again as a commons project. Overall the projects that used to contribute to xbean have largely stopped doing so and we've been unsuccessful convincing anyone to start using the libraries. As you say, we'll keep an eye on it. I don't really have the brain capacity to think about good solutions at the moment anyway. -David
Re: Opening up xbean svn access (Fwd: Jar listing performance)
On Jun 8, 2011, at 9:36 PM, David Blevins wrote: > I and pretty much everyone with dual OpenEJB/Geronimo commit is likely way > too busy to commit this patch (XBEAN-176). Ended up having to make CDI related change to xbean and cleared out this patch. We should still consider opening things up though. > > I wonder in general if we shouldn't just open up the xbean section of the > repo since it is more or less a commons area. Would be nice to open it up to > at least OpenEJB. I.e. we just tweak the svn auth file like so: > > [/geronimo/xbean/] > @geronimo = rw > @openejb = rw > > Could potentially open it to OpenWebBeans at some point later if it starts > using xbean-finder. So far talk on the OWB side has always been "lets move > everything commons" which I suppose we could do, but that seems like a lot of > pointless refactoring and repackaging and moving when we could just add a > couple lines to the svn auth file. > > Thoughts? > > > -David > > Begin forwarded message: > >> From: Romain Manni-Bucau >> Date: June 7, 2011 10:22:22 PM PDT >> To: d...@openejb.apache.org >> Subject: Re: Jar listing performance >> Reply-To: d...@openejb.apache.org >> >> In fact there are 2 kind of API for Jar/Zip: the ZipFile and the >> ZipInputStream (same for jars). If you use the inpout stream one ... you use >> an input stream so you read everything. If you use the file one you directly >> call native methods so under linux in particular it works better (i didn't >> test under windows but i hope it is the same). >> >> David said me we are using JarArchive: >> https://issues.apache.org/jira/browse/XBEAN-176 >> >> - Romain >> >> 2011/6/8 David Blevins >> >>> FYI, to Romain, regarding http://www.friendpaste.com/JU7WuKslKle9UaAL3r21M >>> >>> There might be caching going on in the first call that makes the second >>> call go faster. We should check that angle. Maybe switch the order or loop >>> the main code a couple times. >>> >>> -David >>> >>> >>> >
Opening up xbean svn access (Fwd: Jar listing performance)
I and pretty much everyone with dual OpenEJB/Geronimo commit is likely way too busy to commit this patch (XBEAN-176). I wonder in general if we shouldn't just open up the xbean section of the repo since it is more or less a commons area. Would be nice to open it up to at least OpenEJB. I.e. we just tweak the svn auth file like so: [/geronimo/xbean/] @geronimo = rw @openejb = rw Could potentially open it to OpenWebBeans at some point later if it starts using xbean-finder. So far talk on the OWB side has always been "lets move everything commons" which I suppose we could do, but that seems like a lot of pointless refactoring and repackaging and moving when we could just add a couple lines to the svn auth file. Thoughts? -David Begin forwarded message: > From: Romain Manni-Bucau > Date: June 7, 2011 10:22:22 PM PDT > To: d...@openejb.apache.org > Subject: Re: Jar listing performance > Reply-To: d...@openejb.apache.org > > In fact there are 2 kind of API for Jar/Zip: the ZipFile and the > ZipInputStream (same for jars). If you use the inpout stream one ... you use > an input stream so you read everything. If you use the file one you directly > call native methods so under linux in particular it works better (i didn't > test under windows but i hope it is the same). > > David said me we are using JarArchive: > https://issues.apache.org/jira/browse/XBEAN-176 > > - Romain > > 2011/6/8 David Blevins > >> FYI, to Romain, regarding http://www.friendpaste.com/JU7WuKslKle9UaAL3r21M >> >> There might be caching going on in the first call that makes the second >> call go faster. We should check that angle. Maybe switch the order or loop >> the main code a couple times. >> >> -David >> >> >>
Re: [jira] [Created] (GERONIMO-5989) CDI EAR deployment issue
Thanks, Shawn! On Jun 1, 2011, at 7:02 PM, Shawn Jiang wrote: > I'll take a look. > > On Thu, Jun 2, 2011 at 8:27 AM, David Blevins wrote: > Made great progress in CDI/EJB integration, but seems we have a general issue > with deploying EARs the CDI TCK gives us so we aren't seeing it yet. > > It looks like the deploy is successful but the EJB module doesn't start. No > errors in the log other than the webapp failing to start due to missing EJB > jar classes. > > If someone could take a quick look that would be wonderful. I've attached an > example EAR to the JIRA. > > > -David > > On Jun 1, 2011, at 5:16 PM, David Blevins (JIRA) wrote: > > > CDI EAR deployment issue > > > > > > Key: GERONIMO-5989 > > URL: https://issues.apache.org/jira/browse/GERONIMO-5989 > > Project: Geronimo > > Issue Type: Bug > > Security Level: public (Regular issues) > > Components: deployment, javaee6 > >Reporter: David Blevins > > > > > > Attached is one of many EAR files produced by the CDI TCK that do not > > deploy. Both the EJB and WAR modules are found and created, but only the > > WAR starts and has none of the required jars in the classpath. > > > > -- > > This message is automatically generated by JIRA. > > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > -- > Shawn
Re: [jira] [Created] (GERONIMO-5989) CDI EAR deployment issue
Made great progress in CDI/EJB integration, but seems we have a general issue with deploying EARs the CDI TCK gives us so we aren't seeing it yet. It looks like the deploy is successful but the EJB module doesn't start. No errors in the log other than the webapp failing to start due to missing EJB jar classes. If someone could take a quick look that would be wonderful. I've attached an example EAR to the JIRA. -David On Jun 1, 2011, at 5:16 PM, David Blevins (JIRA) wrote: > CDI EAR deployment issue > > > Key: GERONIMO-5989 > URL: https://issues.apache.org/jira/browse/GERONIMO-5989 > Project: Geronimo > Issue Type: Bug > Security Level: public (Regular issues) > Components: deployment, javaee6 >Reporter: David Blevins > > > Attached is one of many EAR files produced by the CDI TCK that do not deploy. > Both the EJB and WAR modules are found and created, but only the WAR starts > and has none of the required jars in the classpath. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5989) CDI EAR deployment issue
[ https://issues.apache.org/jira/browse/GERONIMO-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins updated GERONIMO-5989: Attachment: EnterpriseQualifierDefinitionTest.ear As of OpenEJB/OpenWebBeans/XBean r1130358, this test should pass. > CDI EAR deployment issue > > > Key: GERONIMO-5989 > URL: https://issues.apache.org/jira/browse/GERONIMO-5989 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, javaee6 > Reporter: David Blevins > Labels: cdi, deployment, ear, ejb, tck > Attachments: EnterpriseQualifierDefinitionTest.ear > > > Attached is one of many EAR files produced by the CDI TCK that do not deploy. > Both the EJB and WAR modules are found and created, but only the WAR starts > and has none of the required jars in the classpath. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5989) CDI EAR deployment issue
CDI EAR deployment issue Key: GERONIMO-5989 URL: https://issues.apache.org/jira/browse/GERONIMO-5989 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment, javaee6 Reporter: David Blevins Attached is one of many EAR files produced by the CDI TCK that do not deploy. Both the EJB and WAR modules are found and created, but only the WAR starts and has none of the required jars in the classpath. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to marshal/unmarshal HandlerType correctly ?
Those data types used to be strings. That's probably why it worked before. I wouldn't lose any sleep if we changed them back to String from QName if it made things easier now. Can always revisit it later. -David On May 24, 2011, at 7:39 AM, Ivan wrote: > I just committed some changes to trunk at revision: 1127089. Current > solution is to use a XmlAdapter to create the QName even if it is > illegal. Now, it is OK to unmarshal the XML file, but while > marshalling the object to XML texts, those namespace information is > lost ... > Not sure whether there is better way for this. > > 2011/5/23 Ivan : >> Hi, >>In the HandlerChain class of the jee module, we uses QName for the >> type of serviceNamePattern and portNamePattern for better access (By >> default, String type is used in the generated classes). But in the web >> service spec, it is allowed to specify * and invalid name space >> prefix. >>e.g. >> >> > xmlns:ns1="http://hello.org";>foo:HelloService >> .. >> >> >>Now, while parsing the DD above, an exception like >> java.lang.IllegalArgumentException: prefix foo is not bound to a >> namespace is thrown. >>Is there a way in JAXB to create a QName even the name space is >> invalid ? I am thinking to have a XMLAdapter to do this from String, >> but seems no way to look up the namespace by the prefix. >>Thoughts ? Thanks. >> -- >> Ivan >> > > > > -- > Ivan
[jira] [Commented] (GERONIMO-5855) Simplify EJB Deployment
[ https://issues.apache.org/jira/browse/GERONIMO-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034099#comment-13034099 ] David Blevins commented on GERONIMO-5855: - I know Geronimo has the ability to create an AbstractFinder that can scan all the parts of the webapp. If we maybe yanked the AnnotationFinder being used in isEjbModule and replaced it with one of Geronimo's creation, that might work better. Assuming I understand the issue correctly. Sounds like we simply aren't able to identify the war as an EJB module -- hoping the rest of the code which uses the proper finder will work. > Simplify EJB Deployment > --- > > Key: GERONIMO-5855 > URL: https://issues.apache.org/jira/browse/GERONIMO-5855 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: OpenEJB >Reporter: David Blevins >Assignee: David Blevins > Fix For: 3.0 > > Attachments: SimplifyEjbModuleCreation.diff > > > Seems like we're always having issues due to changes in the OpenEJB > DeploymentLoader code, so I've attempted to extract the parts that Geronimo > needs. Hopefully this can provide some stability and maybe even help with > tuning deployment to Geronimo's needs in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo 3.0 and descriptors (was: Re: openejb-jar-2.2.xsd out-of-date?)
Soo The discussion on the openejb-jar.xml confusion has brought up some relevant topics (see the previous email for backstory). Such as we probably need to decide what we might want to do with our descriptors going forward. At least in terms of David Jencks' branch changes, gbeans and are dead and there's no more dependency information in the descriptors anymore. David can probably fill in some details as well as maybe comment on the likely hood of us releasing a 3.0 final with that code, but... Certainly in terms of the EJB related descriptors we already have a ton of legacy and it looks like we're getting more. Specifically: 1. osgi/gbean changes (the branch changes). No more dependency information. Not sure the impact on naming and gbean specific queries. 2. "clustering" elements. No one to my knowledge has ever used or even tried to use the WADI clustering stuff. Do we want to keep carrying it forward? 3. CMP data. CMP is dead and we could probably get along fine just making the 1, 2 or 0 users out there use the jpa mapping file directly. 4. The 'openejb-jar' element of the new geronimo-openejb.xml file. From a Geronimo perspective, the only thing useful in it that is not already in the geronimo-openejb.xml jar file is the ability to specify which container you want your bean deployed in -- assuming you don't want the default. That's a rare case, but certainly would be easy to add to the geronimo-openejb.xml file. If we're going to change all the geronimo descriptors incompatibly, then maybe we want to kill the openejb-jar.xml file in the process, switch everyone over to a new-new geronimo-openejb-3.0.xsd (not yet written) and make the related JAXB in Geronimo land. If we aren't changing things incompatibly, then maybe we just leave things alone and try to make tiny changes where needed. Any thoughts? -David
Re: openejb-jar-2.2.xsd out-of-date?
On May 5, 2011, at 12:44 AM, han hongfang wrote:
> The openejb-jar-2.2.xsd comes from latest geronimo server v3.0-snapshot build
> under schema folder. To me, I think this xsd file is invalid since for
> example[...]
Right, as I mention the JAXB tree and schema are not well maintained.
Sometimes the JAXB tree is updated the schema is not or vice versa.
> Another question is, in geronimo v3.0-snapshot, which schema should the
> deployment plan openejb-jar.xml comply to? openejb-jar-{versionA}.xsd or
> geronimo-openejb-{versionB}.xsd, or even both are OK? and what the value of
> {versionA} and {versionB}?
The old Geronimo specific openejb-jar v2 is read in, if found, and split into
the new geronimo-openejb.xml file (geronimo specific) and the new
openejb-jar.xml file (not geronimo specific). As noted the link it was done
mostly for backwards compatibility. The TCK and all our docs and examples
still use the "old" openejb-jar.xml file and not the new
geronimo-openejb.xml+openejb-jar.xml file.
And actually, some of the CMP parts of the old openejb-jar.xml are translated
into JPA mapping files. In Geronimo 1.0 we used TranQL and now we use JPA to
deliver legacy CMP info. So really that old openejb-jar.xml file gets split
into potentially 3 files: geronimo-openejb.xml, openejb-jar.xml and jpa
mapping.xml for for any CMP beans.
As for which "wins", we first try to read in the openejb-jar.xml as the new
version. If that fails we try again using the old version and then will do the
conversion and OpenEJB, Geronimo and OpenJPA will each get their parts.
> I'm considering to reuse these JAXB objects in Geronimo server adapter v3.0.
> Can you point me to the exact xsd file for this JAXB objects? I did a quick
> check, and can not find some classes in openejb-jar-2.2.xsd and
> geronimo-openejb-2.0.xsd, which come from latest geronimo v3.0-snapshot
> build, e.g., AbstractClusteringType.
Some of the parts of the related Geronimo schemas are not read into the tree as
strong types. Anything in the 'clustering', 'abstractNamingEntry', 'service'
and 'security' elements are packed into generic JAXBElement types. All this
stuff was generated by the JAXB compiler which wasn't able to handle some of
the more clever things David J. did with the Geronimo schemas. The result was
those abstract classes like AbstractClusteringType that have no concrete
implementations. It's technically accurate representation of the schema, but
functionally useless.
All the generic information is lost at runtime so "JAXBElement" is really just "JAXBElement" and the
AbstractClusteringType never factors in. The entire JAXB tree (JAXBElement
data and all) is/was ultimately handed over to XMLBeans which does/did the real
work. There wasn't any interest in using JAXB in Geronimo itself then so most
of the real code was done by Geronimo with XMLBeans copies of the descriptor
data. So the JAXB tree only needed to be good enough to do the conversion and
get the xml where it needed to go.
Worked well enough for 4-5 years, but now we have a new major version and we
could chose to do things all differently if we want.
> Meanwhile, I plan to put the JAXB objects of geronimo-openejb-{version}.xsd
> and openejb-jar-{version}.xsd into separate package.
I suspect the goal is to write some tooling and in that front the current JAXB
tree might not be what we want to be focusing on going forward. Certainly, the
fact that much of the tree is just loosely typed JAXBElement objects and not
concrete classes, it won't really do the trick as-is now.
We'd have to invest time in fixing it up, at least a little. I think we need
to ask ourselves if this is really the setup we want going forward. Was hoping
to hear from David J at least. Let me take another shot in a follow up email.
-David
Re: LinkageError woes
On May 10, 2011, at 6:57 PM, David Blevins wrote: > I have a hunch that eagerly loading annotations *and* enums might do the > trick. Going to see if that is the case as that might give us more > information about the issue and potentially a workaround that might be one we > can stomach. Loading all the classes eagerly is not ok, but eagerly loading > annotation and enum classes might be livable till we can find the real issue. Looks like eagerly loading all the application's annotations and enums twice does the trick. The first time fails with the LinkageError and the second time works. Currently performing some magic in debugger with evaluating expressions to get this accomplished. Not going to codify it just yet, but if we wanted this as a hack as an implemented workaround we'd need to use ASM to scrape and get a list of all annotation and enum classes, put that data in perhaps a gbean that is setup to load on app startup with a dependency on the app classloader, then have that gbean do the double load. The xbean-finder code doesn't currently have the ability to list annotations and enums -- we'd have to add it or scrape again. Hopefully we can find the real issue and not have to do that. -David
Re: LinkageError woes
On May 10, 2011, at 5:56 PM, Kevan Miller wrote: > > On May 10, 2011, at 8:19 PM, David Blevins wrote: > >> >> On May 10, 2011, at 3:48 PM, Kevan Miller wrote: >> >>> >>> On May 10, 2011, at 5:08 PM, Kevan Miller wrote: >>> >>>> >>>> On May 10, 2011, at 3:54 PM, David Blevins wrote: >>>> >>>>> Running out of places to perform our LinkageError hack. >>>>> >>>>> We've been doing the "try again" routine on all our code (xbean, >>>>> openwebbeans, etc) and it seems we've followed that path as far as it >>>>> will lead us. Currently stuck at the following with no good ideas on how >>>>> to work around it. >>>> >>>> Yuck. Thanks for getting us this far! >>>> >>>> For some reason, I had the notion that this was all going to be resolved >>>> by moving up to the latest OpenJPA release. Obviously, I was mis-guided >>>> (at best) and definitely hadn't gotten to the test validation stage. >>>> >>>> I guess OpenJPA would be where I might hope we could resolve... I can try >>>> banging my head against the wall for a bit... >>> >>> Well, one reason why OpenJPA wouldn't help resolve is if OpenJPA weren't >>> involved... Hmph. >>> >>> If my memory is correct, this will work on Felix... >> >> Indeed it seems like an Equinox issue. >> >> Tried a hack involving wrapping the classloader with one that double-tries >> loadClass if a LinkageError is thrown. Didn't work. Might have needed to >> have done the hack a little deeper -- I just did the wrapping in >> TomcatWebAppContext. >> >> At the moment trying to find at least some dirty hack that will let me get >> far enough to see if the test will pass sans this issue. Current hack idea: >> eagerly load all annotation classes. > > Started looking at Equinox code a bit. Also sent of a question. See who gets > there first... Eagerly loading annotation classes alone didn't do the trick. Loading *all* the classes does work and results in all 5 persistence tests to pass. I have a hunch that eagerly loading annotations *and* enums might do the trick. Going to see if that is the case as that might give us more information about the issue and potentially a workaround that might be one we can stomach. Loading all the classes eagerly is not ok, but eagerly loading annotation and enum classes might be livable till we can find the real issue. -David
Re: LinkageError woes
On May 10, 2011, at 3:48 PM, Kevan Miller wrote: > > On May 10, 2011, at 5:08 PM, Kevan Miller wrote: > >> >> On May 10, 2011, at 3:54 PM, David Blevins wrote: >> >>> Running out of places to perform our LinkageError hack. >>> >>> We've been doing the "try again" routine on all our code (xbean, >>> openwebbeans, etc) and it seems we've followed that path as far as it will >>> lead us. Currently stuck at the following with no good ideas on how to >>> work around it. >> >> Yuck. Thanks for getting us this far! >> >> For some reason, I had the notion that this was all going to be resolved by >> moving up to the latest OpenJPA release. Obviously, I was mis-guided (at >> best) and definitely hadn't gotten to the test validation stage. >> >> I guess OpenJPA would be where I might hope we could resolve... I can try >> banging my head against the wall for a bit... > > Well, one reason why OpenJPA wouldn't help resolve is if OpenJPA weren't > involved... Hmph. > > If my memory is correct, this will work on Felix... Indeed it seems like an Equinox issue. Tried a hack involving wrapping the classloader with one that double-tries loadClass if a LinkageError is thrown. Didn't work. Might have needed to have done the hack a little deeper -- I just did the wrapping in TomcatWebAppContext. At the moment trying to find at least some dirty hack that will let me get far enough to see if the test will pass sans this issue. Current hack idea: eagerly load all annotation classes. -David
LinkageError woes
Running out of places to perform our LinkageError hack. We've been doing the "try again" routine on all our code (xbean, openwebbeans, etc) and it seems we've followed that path as far as it will lead us. Currently stuck at the following with no good ideas on how to work around it. 2011-05-10 12:01:17,089 ERROR [[JBoss Test Harness Test Runner]] Servlet.service() for servlet [JBoss Test Harness Test Runner] in context with path [/org.jboss.jsr299.tck.tests.implementation.simple .resource.persistenceContext.PersistenceContextInjectionTest] threw exception org.testng.TestNGException: Cannot create/initialize the JDK5 annotation finder org.testng.internal.annotations.JDK15AnnotationFinder at org.testng.internal.ClassHelper.createJdkAnnotationFinder(ClassHelper.java:186) at org.testng.TestNG.initializeAnnotationFinders(TestNG.java:756) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:892) at org.testng.TestNG.runSuitesLocally(TestNG.java:876) at org.testng.TestNG.run(TestNG.java:784) at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:696) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48) at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:550) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:380) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:166) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:288) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:243) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:373) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.testng.internal.ClassHelper.createJdkAnnotationFinder(ClassHelper.java:183) ... 29 more Caused by: java.lang.LinkageError: loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader): attempted duplicate class definition for name: "org/testng/annotations/Configuratio n" at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:580) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:550) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:481) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:469) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449) at
Re: openejb-jar-2.2.xsd out-of-date?
On Apr 14, 2011, at 1:25 AM, han hongfang wrote: > Hi devs, > > I got following errors when I tried to generate the jaxbmodel class for > openejb-jar-2.2.xsd using maven-jaxb-plugin:1.1.1. Taking > entity-manager-factory-ref for instance, it can not be found in > geronimo-naming-1.2.xsd. This old email has some related info: http://markmail.org/message/w76ndrfv27v53mbk There already are JAXB objects for old/new descriptors and as a result the schema is rarely updated. I think for a while we didn't even have one. There's a bit of legacy here in the for a short bit (Geronimo 1.0/OpenEJB 2.0) OpenEJB was not really a separate project in any technical sense. The OpenEJB 3.x codebase returned to being more standalone. The reason to keep the v2 openejb-jar.xml format was it was made 100% for Geronimo -- it has all the Geronimo dependency and config stuff in it amongst other things. Anyway, here are the root JAXB objects for the related trees: openejb-jar v2: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-jee/src/main/java/org/apache/openejb/jee/oejb2/OpenejbJarType.java geronimo-ejb: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-jee/src/main/java/org/apache/openejb/jee/oejb2/GeronimoEjbJarType.java Here's the newer non-geronimo-specific openejb tree: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-jee/src/main/java/org/apache/openejb/jee/oejb3/ In terms of what we should do now with a new major Geronimo version, I suspect it will largely depend on David J's work. Seems like there'll be a very big and very not backwards-compatible change with regards to parents/childern and dependency information. Not sure what our plans are with regards to backwards compatibility of existing descriptors. -David
Re: How to provide external openejb-jar.xml for ejb in war ?
On Apr 28, 2011, at 7:21 PM, Ivan wrote: > How about extending the current geronimo-web.xml file ? Add an any element to > hold the contents from openejb-jar.xml. Something like that should work. Interestingly the topic of alt-dds and EJBs in .war files came up in the Java EE 6 EG. Specifically, that alt-dd support is at best ambiguous and at worst broken now that a single module can be many different types. It was an incredibly short conversation with little participation that basically ended in "well if people complain, we can fix it next time." Anyway, putting the openejb-jar in the geronimo-web.xml is pretty natural. -David > > 2011/4/29 Shawn Jiang > We can use following style to provide external openejb-jar.xml for ejb in ear. > > http://geronimo.apache.org/xml/ns/j2ee/application-1.1";> > > > ejb.jar > http://www.openejb.org/xml/ns/openejb-jar-2.1";> > > > > > > > > > ... > > > > But, in javaee 6, ejb could put into war directly.When there's ejb in > war, and we want to use external plan to customize these ejb. > > I'm wondering if there's a existing way to do the similar module config in > war like we are doing in ear. > > -- > Shawn > > > > -- > Ivan
Re: Time for trunk res
On Apr 25, 2011, at 9:45 PM, David Jencks wrote: > It seems like it will cause less disruption if I put the new stuff on a > branch. Unless someone asks I'm going to keep the same version, > 3.0-SNAPSHOT. So, don't push snapshots off the branch :-) > > Unless I can figure out some git magic I'm going to do this by applying the > work to trunk, moving trunk to the new branch, and restoring trunk. Catching up on this thread and was going to suggest exactly that. Buys us a little time to do some manual TCK runs off the branch. Once things look good, we could flip branch/trunk again. -David > I'm going to try to condense the git commits a bit so each one is fairly > substantial but don't plan to spend a lot of time on this. > > I expect to do this tomorrow. > > thanks > david jencks > > On Apr 25, 2011, at 7:36 PM, Kevan Miller wrote: > >> >> On Apr 25, 2011, at 5:37 AM, Shawn Jiang wrote: >> >>> With the later options, we need to re-setup m2 dev/AHP/build environment >>> immediately and have to maintain two set of code for tck for an unknown >>> period. I'd prefer the sandbox/branch instead of branching current trunk >>> before major potential issues in the new kernel is resolved. >> >> I"m ok with that. As long as trunk changes are being merged into the new >> branch. >> >>> >>> Here are the possible working logic if choosing the sandbox option: >>> >>> 1, Run full tck/SVT against the sandbox branch to find the gaps. >>> 2, Keep resolving the Major issues until we are comfortable to put it into >>> trunk. >>> 3, Branch current trunk to new M2 when the sandbox branch is ready. >>> 4, Merge the sandbox branch to trunk. >> >> The key will be when 2 occurs. Hopefully, it will be soon... >> >> --kevan >
Fwd: Current use of GitHub
I know a few of us use Git for Apache work. Feel encouraged to lend some feedback to infra. -David Begin forwarded message: > Resent-From: > From: "Gav..." > Date: April 2, 2011 11:45:10 PM PDT > To: > Subject: Current use of GitHub > Reply-To: infrastructure-...@apache.org > > I'm trying to understand the _current_ workflows of those ASF committers > using Git and how the ASF GitHub mirrors tie into that - if at all. > > A fair few projects requested ASF git mirrors and also requested mirrors of > that on GitHub (that 2nd request is now standard with the 1st) > > So far , from projects I've browsed on GitHub, I see a few forks here and > there and a few Pull requests here and there. > That is where it gets fuzzy for me. Obviously, no-one can actually pull in > those pull requests into the Apache/$project repo mirror, so > how are committers applying those pull requests? Are they pulling them into > their own copies of the mirror, converting them into a patch > that svn understands and then applying, if so, how? If not, how else? > > Also, apart from Github, how else are Git only users providing patches to > projects, which patch programs are in use, and of those which > are most used by those projects/committers that need to apply them. > > For those of you that are committers and have direct access to svn, but are > preferring to use Git before then committing your work to svn, > what is your workflow and tools used (whether or not it involves GitHub) > > No deviating into what could happen or what would be a good idea please yet, > this is just a survey on what people are currently actually > doing to incorporate Git into their workflows and how we then get those > applied. > > Thanks > > Gav... > > >
[jira] [Resolved] (GERONIMO-5888) Delete temp directories on exit
[ https://issues.apache.org/jira/browse/GERONIMO-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-5888. - Resolution: Fixed > Delete temp directories on exit > --- > > Key: GERONIMO-5888 > URL: https://issues.apache.org/jira/browse/GERONIMO-5888 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Reporter: David Blevins > Assignee: David Blevins > Fix For: 3.0 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Excessive tmp file usage
We're filling up the tmp dir on buildbot with gigs of leftover tmp files created in our build. Most of it is temp directories. Attempted to hack up a solution to delete all the temp directories on exit (GERONIMO-5888) Let me know if you spot any issues. -David
[jira] [Created] (GERONIMO-5888) Delete temp directories on exit
Delete temp directories on exit --- Key: GERONIMO-5888 URL: https://issues.apache.org/jira/browse/GERONIMO-5888 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: David Blevins Assignee: David Blevins Fix For: 3.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
AnnotationFinder 2.0
Some long needed changes/improvements to the finder API. XBEAN-165: Meta Annotation Support XBEAN-166 : Class Name Filtering for Optimized Scanning XBEAN-171: RegexFilteredArchive supporting regular expressions to include/exclude classes from scanning XBEAN-172: PrefixFilteredArchive supports "startsWith" list of accepted prefixes XBEAN-173: PackageFilteredArchive supports strict list of accepted package names XBEAN-167: Archive Interface for cleaner integration of Classpath and OSGi based systems XBEAN-168: ClassesArchive for static class list finder support XBEAN-169: ClasspathArchive for traditional java classpath finder support XBEAN-170: BundleArchive for OSGi bundle finder support The first, meta annotations, is probably less interesting in Geronimo terms, but the second two classes of changes are major improvements. Rather than subclassing I've attempted to abstract out the few parts that are different and switch us over to a delegation based model. Once that was done adding wrapping/decorating of the delegates to achieve filtering was a natural next step. A bit reason I'm not fan of subclassing as in that model doing this kind of shared filtering would require all the subclasses to inherit from this new "filtering" parent which would in turn now subclass from the original parent. And that is an oversimplification as you can't really wrap abstract methods like that -- a filtering parent class can't call "subclass.doThis()" and mutate the result in it's own "doThis()" method, so you end up with more abstract methods. Delegation is also composable, whereas you can't dynamically change your parent class to use or not use the common filtering parent class. Anyway enough about that :) So what we have now is a composable system. You create your finder and feed it an archive, like so: new AnnotationFinder( new BundleArchive() ); If you want some filtering, you add that in: new AnnotationFinder( new PackageFilteredArchive( new BundleArchive(), "org.foo" ) ); And if some day we decide we want to support some sort of mashing of OSGi and traditional sources, we could create an Archive implementation to combine them, like so: new AnnotationFinder( new PackageFilteredArchive( new CompositeArchive( new BundleArchive(), new ClasspathArchive() ), "org.foo" ) ); Sky is the limit. Some concrete things I need help with. 1) Finishing the BundleArchive. I have stub in there based on the subclass version. But the subclass "pushed" classes into the finder and the new approach is a "pull". Anyone who has any time, please grab XBEAN-170 and assign it to yourself. It's up for grabs. 2) Converting all the code from AbstractFinder to AnnotationFinder. Once we get #1 finished, we'll need to roll the code over. It should be fairly easy as the effective API is the same, just the way we construct things is different. Still in the works: 1) Tests for all the filters 2) An SAXParser style error handler -- the whole classesNotLoaded thing is going bye-bye 3) Finishing the ClasspathArchive and Meta Annotation support for fields -David
Re: Server build failed
On Mar 16, 2011, at 2:09 PM, Kevan Miller wrote: > > On Mar 15, 2011, at 5:00 AM, Shenghao Fang wrote: > >> I finally made the build successfully by upgrading maven to 3.03. >> >> But I don't know the root cause exactly. >> >> Anyway, thanks for your hint. >> >> 2011/3/15 Ivan >> Do you solve this issue ? I got the similar error, and found it was caused >> by an old >> org\apache\geronimo\geronimo\3.0-SNAPSHOT\geronimo-3.0-SNAPSHOT.pom file on >> the snapshot site. Manually copy this file from the source code to the local >> maven repository would make it work. > > > I've been building fine with mvn 2.2.1. If we have a bad snapshot pom, then > let's get a new snapshot deployed... Added a buildbot definition for forcing a snapshot deploy "geronimo-trunk-deploy". It can be triggered from the IRC bot like the other build definitions, but won't run on a schedule. I.e. we can run it as needed. Will fire it off as soon as the build Kevan triggered is done. -David
Availability spec compile error
Any ideas? http://ci.apache.org/builders/specs-trunk/builds/2/steps/compile/logs/stdio -David
Re: CI and Snapshots publishing
Already have OpenEJB setup. Plan to run the idea on dev@openwebbeans to make sure no one objects. Also if there are any other snapshots we regularly need (wink?), let me know I'd I'll ask them on their dev list if they don't mind me setting them up. -David On Mar 9, 2011, at 4:35 PM, Shawn Jiang wrote: > great ! > > > Will you also do the same to openejb and openwebbeans ? If so , I will > unchain openejb/owb from current AHP build to save build time. > > On Thu, Mar 10, 2011 at 7:55 AM, David Blevins > wrote: > It took a bit of work, but managed to set us up in Buildbot > (http://ci.apache.org/buildbot.html). > > Commits to the following sections of svn will trigger a build of that > section. If the build completes successfully (tests and all), then a second > "mvn deploy" will be triggered to publish snapshots. > > geronimo/bundles/trunk > geronimo/daytrader/trunk > geronimo/genesis/trunk > geronimo/gshell/trunk > geronimo/samples/trunk > geronimo/server/trunk > geronimo/specs/trunk > geronimo/xbean/trunk > geronimo/yoko/trunk > geronimo/components/txmanager/trunk > geronimo/devtools/eclipse-plugin/trunk > geronimo/devtools/maven-plugins/trunk > > We'll get email notifications to comm...@geronimo.apache.org. > > There's also now a geronimobot on #geronimo where it is possible to force > builds, get status and other things. > > Hopefully it will save us all time and not the other way around :) > > It will certainly be nice to have current snapshots -- or any at all for that > matter. > > > -David > > > > > -- > Shawn
CI and Snapshots publishing
It took a bit of work, but managed to set us up in Buildbot (http://ci.apache.org/buildbot.html). Commits to the following sections of svn will trigger a build of that section. If the build completes successfully (tests and all), then a second "mvn deploy" will be triggered to publish snapshots. geronimo/bundles/trunk geronimo/daytrader/trunk geronimo/genesis/trunk geronimo/gshell/trunk geronimo/samples/trunk geronimo/server/trunk geronimo/specs/trunk geronimo/xbean/trunk geronimo/yoko/trunk geronimo/components/txmanager/trunk geronimo/devtools/eclipse-plugin/trunk geronimo/devtools/maven-plugins/trunk We'll get email notifications to comm...@geronimo.apache.org. There's also now a geronimobot on #geronimo where it is possible to force builds, get status and other things. Hopefully it will save us all time and not the other way around :) It will certainly be nice to have current snapshots -- or any at all for that matter. -David
[jira] Closed: (GERONIMO-5855) Simplify EJB Deployment
[ https://issues.apache.org/jira/browse/GERONIMO-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins closed GERONIMO-5855. --- Resolution: Fixed Thanks, Shawn! > Simplify EJB Deployment > --- > > Key: GERONIMO-5855 > URL: https://issues.apache.org/jira/browse/GERONIMO-5855 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: OpenEJB > Reporter: David Blevins > Assignee: David Blevins > Fix For: 3.0 > > Attachments: SimplifyEjbModuleCreation.diff > > > Seems like we're always having issues due to changes in the OpenEJB > DeploymentLoader code, so I've attempted to extract the parts that Geronimo > needs. Hopefully this can provide some stability and maybe even help with > tuning deployment to Geronimo's needs in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-5853) EJB Module is always created while deploying a web application
[ https://issues.apache.org/jira/browse/GERONIMO-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins closed GERONIMO-5853. --- Resolution: Fixed > EJB Module is always created while deploying a web application > -- > > Key: GERONIMO-5853 > URL: https://issues.apache.org/jira/browse/GERONIMO-5853 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 3.0-M1, 3.0 >Reporter: Ivan > > With the latest OpenEJB snapshot, it seems that an EJB module is always > created even no ejb beans in the deployed web application., and it took a > long time to star the EJBModule GBean. > ---> > 2011-03-07 22:26:00,875 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,WebModule=WSDLTest_web.war,j2eeType=EJBModule,name=WSDLTest_web.war > consume 11172 > 2011-03-07 22:26:01,078 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?EJBModule=WSDLTest_web.war,J2EEApplication=default/WSDLTest/1299507925968/car,WebModule=WSDLTest_web.war,j2eeType=ValidatorFactory,name=ValidatorFactory > consume 203 > 2011-03-07 22:26:12,765 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,j2eeType=ValidatorFactory,name=ValidatorFactory > consume 78 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?j2eeType=J2EEApplication,name=default/WSDLTest/1299507925968/car > consume 0 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,Servlet=com.sun.ts.tests.jaxws.sharedwebservices.doclithelloservice.HelloImpl,WebModule=WSDLTest_web.war,j2eeType=GBean,name=POJOWebServiceContainerFactoryGBean > consume 0 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,Servlet=com.sun.ts.tests.jaxws.sharedwebservices.doclithelloservice.Hello2Impl,WebModule=WSDLTest_web.war,j2eeType=GBean,name=POJOWebServiceContainerFactoryGBean > consume 0 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,Servlet=com.sun.ts.tests.jaxws.sharedwebservices.doclithelloservice.Hello3Impl,WebModule=WSDLTest_web.war,j2eeType=GBean,name=POJOWebServiceContainerFactoryGBean > consume 0 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,WebModule=WSDLTest_web.war,j2eeType=GBean,name=jspLifecycleProvider > consume 0 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,j2eeType=ApplicationJndi,name=ApplicationJndi > consume 0 > 2011-03-07 22:26:24,203 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,WebModule=WSDLTest_web.war,j2eeType=ContextSource,name=ContextSource > consume 0 > 2011-03-07 22:26:38,906 INFO [GBeanInstance] INFO IVAN > default/WSDLTest/1299507925968/car?J2EEApplication=default/WSDLTest/1299507925968/car,j2eeType=WebModule,name=WSDLTest_web.war > consume 14703 > <--- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can anyone tell me what's the reason to remove the .jar extension in GERONIMO-5253 ?
That looks pretty good! I'll trade you patches. I haven't yet been able to verify if this works, but the idea is clear -- just use the code we need. https://issues.apache.org/jira/browse/GERONIMO-5855 My TCK setup got messed up somehow and I'm currently re-downloading it, but I figure you might be able to verify it a little quicker. -David On Mar 8, 2011, at 7:17 AM, Shawn Jiang wrote: > Hi David, > > I just attached a patch to https://issues.apache.org/jira/browse/OPENEJB-1439 > > All ejblink cases passed locally with the patch. Could you help review it ? > > On Tue, Mar 8, 2011 at 11:00 AM, David Blevins > wrote: > Thanks, Shawn! > > On Mar 6, 2011, at 6:46 PM, Shawn Jiang wrote: > > > In the changes of JIRA[1] made by Jarek, there are many code[2] added in > > all module builders to remove the .jar extension from module name. I could > > also find similar change[1] in openejb code.For EJB module, because > > openejb will need the .jar style module name to resolve the EJB > > link(xxx.jar#xxx), the change broke the ejb link cases. > > Looks like we broke the link resolving code when we added the Java EE 6 > support. The link resolving code shouldn't be using the > moduleId, rather the path of the archive itself. > > Previously there was not spec defined concept of module-name (moduleId for > us). When we pushed in the spec module-name concept on top of the existing > code, things probably got a little confused. The moduleId vs path logic was > never very clear in the code previously. Probably we need to do some tweaks > in the integration and maybe OpenEJB to get this right. > > > I want to revert the .jar removal code from EjbModuleBuilder to fix this, > > but I don't want to broke other things because of the revert. Can anyone > > tell me what's the reason to remove the .jar extension ? > > That's the spec defined module name if the element isn't set in > the descriptor. > > > -David > > > > > -- > Shawn
[jira] Updated: (GERONIMO-5855) Simplify EJB Deployment
[ https://issues.apache.org/jira/browse/GERONIMO-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins updated GERONIMO-5855: Attachment: SimplifyEjbModuleCreation.diff Seems I have an old TCK version so can't immediately verify this change. Attaching the change in the meantime. > Simplify EJB Deployment > --- > > Key: GERONIMO-5855 > URL: https://issues.apache.org/jira/browse/GERONIMO-5855 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: OpenEJB >Reporter: David Blevins >Assignee: David Blevins > Fix For: 3.0 > > Attachments: SimplifyEjbModuleCreation.diff > > > Seems like we're always having issues due to changes in the OpenEJB > DeploymentLoader code, so I've attempted to extract the parts that Geronimo > needs. Hopefully this can provide some stability and maybe even help with > tuning deployment to Geronimo's needs in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-5855) Simplify EJB Deployment
[ https://issues.apache.org/jira/browse/GERONIMO-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins updated GERONIMO-5855: Component/s: OpenEJB Fix Version/s: 3.0 > Simplify EJB Deployment > --- > > Key: GERONIMO-5855 > URL: https://issues.apache.org/jira/browse/GERONIMO-5855 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: OpenEJB > Reporter: David Blevins > Assignee: David Blevins > Fix For: 3.0 > > > Seems like we're always having issues due to changes in the OpenEJB > DeploymentLoader code, so I've attempted to extract the parts that Geronimo > needs. Hopefully this can provide some stability and maybe even help with > tuning deployment to Geronimo's needs in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-5855) Simplify EJB Deployment
Simplify EJB Deployment --- Key: GERONIMO-5855 URL: https://issues.apache.org/jira/browse/GERONIMO-5855 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: David Blevins Assignee: David Blevins Seems like we're always having issues due to changes in the OpenEJB DeploymentLoader code, so I've attempted to extract the parts that Geronimo needs. Hopefully this can provide some stability and maybe even help with tuning deployment to Geronimo's needs in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can anyone tell me what's the reason to remove the .jar extension in GERONIMO-5253 ?
Thanks, Shawn! On Mar 6, 2011, at 6:46 PM, Shawn Jiang wrote: > In the changes of JIRA[1] made by Jarek, there are many code[2] added in all > module builders to remove the .jar extension from module name. I could also > find similar change[1] in openejb code.For EJB module, because openejb > will need the .jar style module name to resolve the EJB link(xxx.jar#xxx), > the change broke the ejb link cases. Looks like we broke the link resolving code when we added the Java EE 6 support. The link resolving code shouldn't be using the moduleId, rather the path of the archive itself. Previously there was not spec defined concept of module-name (moduleId for us). When we pushed in the spec module-name concept on top of the existing code, things probably got a little confused. The moduleId vs path logic was never very clear in the code previously. Probably we need to do some tweaks in the integration and maybe OpenEJB to get this right. > I want to revert the .jar removal code from EjbModuleBuilder to fix this, > but I don't want to broke other things because of the revert. Can anyone tell > me what's the reason to remove the .jar extension ? That's the spec defined module name if the element isn't set in the descriptor. -David
Re: Is GeronimoMappedName still required ?
We may not need it if we prune out the things from the JNDI tree we don't want OpenEJB to build. We used to use it as a way to merge the OpenEJB built JNDI tree with the Geronimo built one. The OpenEJB one was in "front" and the Geronimo one was in back. So the OpenEJB tree had links to all the Geronimo tree items Geronimo wanted to control. Now it's the reverse. -David On Feb 21, 2011, at 5:57 PM, Ivan wrote: > OK, seems that no one remembered that history, I also noticed that file is > added long long ago. I think that the only way is to remove it, and check > whether everything still works well. > > 2011/2/19 Ivan > >> Hi, >> I found a GeronimoMappedName in the EJB deployment chain, and it will >> configure the mapped name for some of jndi staff. Seems that mapped name is >> used to configured server specified jndi name, but I did not find the >> configured jndi:java:comp/geronimo/env/ namespace in Geronimo JNDI tree now >> (From the history, it seems that that tree is created in the >> EJBDeploymentGBean in the past). I am wondering that do we still require it >> ? As it will configure the resource refer to an nonexisting place. >> Thanks. >> >> -- >> Ivan >> > > > > -- > Ivan
Re: OOM:PermGen space problem when running jcdi tck on Linux box.
On Feb 14, 2011, at 7:35 AM, Shawn Jiang wrote: > The JCDI automation has been in a bad shape for quite a while. Though the > geronimo start jvm args have been updated to a large max memory level. > > -Xmx2056m -XX:MaxPermSize=1024m > > The jcdi tck is still not happy with java.lang.OutOfMemoryError: PermGen > space. I can also recreate OMM on my local ubuntu box but can't recreate it > on my window laptop. > > I don't know if the same problem exists on Mac. Is anyone else seeing the > same issue ? I have the same issue on Mac and have been using a JAVA_OPTS workaround similar to the one you posted. I had been using a vanilla environment variable. Seems you found a simply way to do it in the pom. We should definitely use your approach. -David
Bad 2.2.1 release
Looks like our 2.2.1 release does not contain the final OpenEJB 3.1.4 binaries and instead contains older binaries from a release vote that never passed. $ cd /tmp $ wget -q http://www.apache.org/dist/geronimo/2.2.1/geronimo-tomcat6-javaee5-2.2.1-bin.tar.gz $ tar xzf geronimo-tomcat6-javaee5-2.2.1-bin.tar.gz $ jar tvf /tmp/geronimo-tomcat6-javaee5-2.2.1/repository/org/apache/openejb/openejb-core/3.1.4/openejb-core-3.1.4.jar | tail 562 Sun Oct 31 21:28:14 PDT 2010 org/openejb/OpenEJB.class 7379 Sun Oct 31 21:28:10 PDT 2010 schema/openejb-jar.xsd 6545 Sun Oct 31 21:28:10 PDT 2010 schema/openejb.xsd 2882 Sun Oct 31 21:28:10 PDT 2010 schema/service-jar.xsd 32 Sun Oct 31 21:28:10 PDT 2010 users.properties 0 Sun Oct 31 21:33:30 PDT 2010 META-INF/maven/ 0 Sun Oct 31 21:33:30 PDT 2010 META-INF/maven/org.apache.openejb/ 0 Sun Oct 31 21:33:30 PDT 2010 META-INF/maven/org.apache.openejb/openejb-core/ 14964 Sun Oct 31 20:57:22 PDT 2010 META-INF/maven/org.apache.openejb/openejb-core/pom.xml 115 Sun Oct 31 21:33:30 PDT 2010 META-INF/maven/org.apache.openejb/openejb-core/pom.properties $ wget -q -U Maven http://repo1.maven.org/maven2/org/apache/openejb/openejb-core/3.1.4/openejb-core-3.1.4.jar $ jar tvf openejb-core-3.1.4.jar | tail 562 Fri Nov 12 15:32:08 PST 2010 org/openejb/OpenEJB.class 7379 Fri Nov 12 15:32:06 PST 2010 schema/openejb-jar.xsd 6545 Fri Nov 12 15:32:06 PST 2010 schema/openejb.xsd 2882 Fri Nov 12 15:32:06 PST 2010 schema/service-jar.xsd 32 Fri Nov 12 15:32:06 PST 2010 users.properties 0 Fri Nov 12 15:32:14 PST 2010 META-INF/maven/ 0 Fri Nov 12 15:32:14 PST 2010 META-INF/maven/org.apache.openejb/ 0 Fri Nov 12 15:32:14 PST 2010 META-INF/maven/org.apache.openejb/openejb-core/ 14964 Fri Nov 12 15:12:40 PST 2010 META-INF/maven/org.apache.openejb/openejb-core/pom.xml 115 Fri Nov 12 15:32:12 PST 2010 META-INF/maven/org.apache.openejb/openejb-core/pom.properties Unfortunately that old openejb-3.1.4 binary contains this bug: https://issues.apache.org/jira/browse/OPENEJB-1394 We'll definitely need another 2.2.x release of some kind. Whether or not we want to include any other fixes is probably a good discussion to have. -David
[jira] Updated: (GERONIMO-5309) Invalid signature for org.apache.geronimo.genesis:genesis:pom:1.2 at central
[ https://issues.apache.org/jira/browse/GERONIMO-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins updated GERONIMO-5309: Attachment: genesis-1.2.tar.gz Resigned genesis-1.2-site.xml genesis-1.2.pom attached > Invalid signature for org.apache.geronimo.genesis:genesis:pom:1.2 at central > - > > Key: GERONIMO-5309 > URL: https://issues.apache.org/jira/browse/GERONIMO-5309 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Anders Hammar >Assignee: Matt Hogstrom > Attachments: genesis-1.2.tar.gz > > > The signature of org.apache.geronimo.genesis:genesis:pom:1.2 > (http://repo1.maven.org/maven2/org/apache/geronimo/genesis/genesis/1.2/genesis-1.2.pom) > at Maven central is invalid. This is most likely because that the signature > att the Apache repo is invalid. Using signature procurement will then block > this making, for example the JMS spec implementation of Geronimo not usable > in Maven. > Suggested action: > 1. Verify the pom at the Apache repo (against the one in svn) > 2. Resign and deploy to the Apache repo > 3. It should now be synced to central > You will most likely need help handling the repo in Apache's Nexus instance. > Try contacting Brian Fox (Apache Maven PMC) and he should be able to help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is there any remaining blocking issue for Geronimo 2.2.1 release ?
On Mon, Nov 29, 2010 at 5:00 PM, Shawn Jiang wrote: > Thanks Rick, I'll cut a release for voting. > One release manager to another, thank you! Let's hope you have better luck than I did with the OpenEJB release :) /me crosses fingers -David
Re: Time for a 3.1.3 release?
I'm repeatedly getting HTTP 502 errors while uploading the assemblies to nexus Going to keep retrying. If anyone has any tips, they would be very welcome. I seem to remember encountering this before and eventually it just worked. Seems like something here is in dire need of improvement. -David
Re: [VOTE] release EJB 3.1 spec version 1.0.1
+1 And thanks for the 'don't wrap EJBException' improvement -David On Sep 13, 2010, at 5:34 AM, Rick McGuire wrote: > This is a bug fix release to fix a couple of problems with the EJB embedded > container support. > > The components up for vote are: > > org/apache/geronimo/specs/geronimo-ejb_3.1_spec/1.0.1/geronimo-ejb_3.1_spec-1.0.1-source-release.zip > org/apache/geronimo/specs/geronimo-ejb_3.1_spec/1.0.1/geronimo-ejb_3.1_spec-1.0.1-source-release.tar.gz > > > from the staging repository at: > > https://repository.apache.org/content/repositories/orgapachegeronimo-015/ > > The source repo is: > > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-ejb_3.1_spec-1.0.1 > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > Rick >
Re: [VOTE] Release new geronimo-annotation_1.1 1.0.1 and geronimo-jaxb_2.2 1.0.1 spec versions
+1 On Aug 18, 2010, at 4:08 AM, Rick McGuire wrote: > These are bug fix releases to fix problems in the common annotation and jaxb > spec bundles. > > The common annotations bundle included a package > (javax.annotation.processing) that is not part of the common annotations > specification. This package is part of the base Java SE 6 support, so this > has been removed from the common annotations jar. > > https://issues.apache.org/jira/browse/GERONIMO-5529 > > The jaxb update has a workaround for a problem in the Sun jaxb impl. Details > can be found here: > > https://issues.apache.org/jira/browse/GERONIMO-5500 > > This is a single vote for both spec updates. > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > Staging repo: > https://repository.apache.org/content/repositories/orgapachegeronimo-123/ > > The source repos are: > > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.1_spec-1.0.1 > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jaxb_2.2_spec-1.0.1 > > Rick > >
JCDI and Bean Validation TCKs
Currently we have these setup in the private svn where the Java EE TCK porting modules live. The JCDI and Bean Validation TCKs are public Apache licensed, so we could move the porting modules for those two TCKs into our public svn. The part of my brain that finds esthetic pleasure in filling cabinets likes everything all organized in the one VM, but the part of me that likes to be more public than private thinks it's unnecessarily restrictive to make people sign the Sun/Apache NDA to get access to things not under that restriction. Specifically, everyone in the related communities (OpenWebBeans, OpenEJB) could easily access the public TCKs. Mark and Gurkan fall into that category now. Both are in the process of getting NDAs filled, but we could definitely speed that up by opening the porting code to the public. We might even be able to work the JCDI and Bean Validation into our larger test suite right in the main build as they only take a moments to run. Thoughts? -David
Re: JAXB tree for spec dds
On Jun 23, 2010, at 11:46 PM, David Jencks wrote: > While trying to figure out how to get geronimo and openejb to cooperate > better building jndi trees I spent couple days converting geronimo to use > openejb's openejb-jee jaxb tree for spec dds. AFAICT it works as well as the > xmlbeans tree and is a lot easier to work with. It brings the conflicts > between geronimo and openejb into clearer focus for me, and currently this is > resulting in more tck failures. However I think I will be able to come up > with a good solution for building the jndi tree now. > > If there are no objections I'd like to clean this up a little bit and commit > it tomorrow. Will certainly clean up the integration code where we had to convert these things back and forth from jaxb to xmlbeans. -David
Re: Adding OSGi support to Geronimo spec jars.
On May 25, 2010, at 3:17 AM, Rick McGuire wrote: > 2) The ProviderLocator. This is how APIs that need to resolve providers > access the registry information. The provider registry is an OSGi service, so > the ProviderLocator needs a bundle context instance to resolve the service > instance. The Activator manages obtaining the bundle context at activation > and setting up a service tracker to give access to the registry service. The > ProviderLocator code manages the details of locating a loading a service > instance and will revert to classic classpath behavior if used outside of an > OSGi environment. On this note, I'm trying to determine what the performance impact might be in a large OSGi environment. Looks like the Activator always enables a ServiceTracker and that tracker appears to look for the ProviderRegistry service on every call. Is that a correct and do you have any idea what the general contract on ServiceTracker.getService() might be? Not sure if that's a quick call or might slow down the more bundles you have. -David
Re: Adding OSGi support to Geronimo spec jars.
Hey I got an idea. Since we're already modding spec jars, some of which will have to be installed into the endorsed dir directory anyway, Why don't we just mod the java.util.ServiceLoader class to do this optional OSGi search? You know, the whole one to rule them all approach. Then we don't have to mod each spec jar and it would work even for SAXParserFactory and other Java SE searches. And people could opt-in. "If you want this functionality, install this jar to your endorsed dir" -David On May 25, 2010, at 3:17 AM, Rick McGuire wrote: > On 5/24/2010 8:06 PM, David Blevins wrote: >> On May 24, 2010, at 3:49 PM, David Jencks wrote: >> >> >>> On May 24, 2010, at 2:18 PM, David Blevins wrote: >>> >>> >>>> 1. Using EJB as an example, how does one say "I am a provider". There is >>>> no "i am the EJB container" interface to implement so what exactly are we >>>> looking for? >>>> >>> >>> EJB is not an example. the provider stuff works for 2 situations: >>> >> The activator and locator were added to the EJB spec jar. Was that a >> mistake? >> > I don't believe it was. There are two sides to this generally. The first side > is the role played by the specs, which generally need to locate a provider. > Typically, the specification defines a search path that generally searches > for 1) a META-INF/services definition, 2) a class defined in a properties > file, and 3) a system property. Depending on the age of the specification, > the order in which these 3 are searched will vary, and the newest java ee > components only define step 1. Generally, this search order will resolve to > the name of a provider class that the API code will then instantiate to > create the provider instance. > > The second role is that of the provider class itself. Typically, a provider > jar would use the META-INF/services mechanism to advertise its availability. > The java EE defined mechanism for locating the provider is to search the > classpath for an appropriate META-INF/services file and load the first > definition it locates. > > In an OSGi environment, there are a number of problems associated with the > "search the classpath" step, so the ProviderLocator was created. There are > two pieces to this: > > 1) A provider registry. This is an extender that watches new bundles being > activated, and if the bundle contains the appropriate metadata, then then the > services it exports are made part of a framework-wide registry. > > 2) The ProviderLocator. This is how APIs that need to resolve providers > access the registry information. The provider registry is an OSGi service, so > the ProviderLocator needs a bundle context instance to resolve the service > instance. The Activator manages obtaining the bundle context at activation > and setting up a service tracker to give access to the registry service. The > ProviderLocator code manages the details of locating a loading a service > instance and will revert to classic classpath behavior if used outside of an > OSGi environment. > > There are two different models in play here for locating a provider instance. > In the first model, the API has been handed the name of the desired provider > directly as a class name. The API could would then attempt to instantiate > that class directly (typically by using the thread context classloader). In > the second model, an appropriate META-INF/services definition is located > using the interface that the provider is expected to implement as the search > key. The services definition file provides a mapping to the provider class > name, which is then loaded and instantiated. In terms of my search paths > defined in the first paragraph above, 1) is the META-INF/services mode, and > 2) and 3) are the first mode of direct loading. > > The provider registry can handle either of these locator modes. If your > provider is already using a META-INF/services model, then the registry then > generally all you need to do is add an SPI-Provider header to your jar file. > Openejb should have this already, but the EJB3 spec code is not strictly > following the EJB specification for locating the provider, so it is possible > it is not. > > If your provider needs to be located via a direct load mechanism where the > class name is provided, then you can use an Export-Service-Provider header to > advertise your provider class so the ProviderLocator code can locate it by > name. > > So, what should the openejb code be doing? The best solution would be to > create the META-INF/services file that maps EJBConta
