Re: Injection of Bundle/BundleContext into Java EE components
Hi
Sounds useful! I wonder if we want to support injecting both or just
bundleContext, since it is pretty straightforward to get bundle from
bundleContext (or the other way around).
Lin
On Thu, Oct 21, 2010 at 5:06 PM, Jarek Gawor jga...@gmail.com wrote:
Hi all,
I was thinking about adding support for injection of
Bundle/BundleContext objects into Java EE components via @Resource
annotation. Example:
class MyServlet extends HttpServlet {
@Resource
Bundle bundle;
@Resource
BundleContext bundleContext;
}
That should make it easier to interact with OSGi within Java EE apps.
I was also thinking of something similar with @Inject for web beans
(cdi stuff) but I'm not really sure it's all that useful since it
should be possible to inject Bundle/BundleContext via @Resource or
combine it with @Produces.
What do you think?
Jarek
Re: [ANNOUNCE] Welcome Linquan Jiang Shawn as a new Geronimo PMC member
Congrats Shawn! Lin On Tue, Sep 7, 2010 at 8:45 PM, Ivan xhh...@gmail.com wrote: I would like to welcome Shawn as he recently accepted the Geronimo PMC invitation to join the PMC. We look forward to working with him to maintain oversight of the Geronimo project. Welcome! -- Ivan
Re: [ANNOUNCE] Welcome Xuan Dai Delos as a new Geronimo PMC member
Congrats! Lin On Tue, Sep 7, 2010 at 3:32 PM, Donald Woods dwo...@apache.org wrote: Please join us in congratulating Delos as a new member of the Geronimo PMC. In addition to all his work on GEP and Samples, Delos also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Delos !!! The Apache Geronimo PMC
Re: [ANNOUNCE] Welcome Ming Xai Forrest as a new Geronimo PMC member
Congrats! Lin On Tue, Sep 7, 2010 at 3:34 PM, Donald Woods dwo...@apache.org wrote: Please join us in congratulating Forrest as a new member of the Geronimo PMC. In addition to all his work on Samples, Forrest also has demonstrated a clear commitment to Geronimo in numerous other areas. We're very glad that he has accepted our invitation to join us in providing oversight of the Geronimo project. Congratulation Forrest !!! The Apache Geronimo PMC
[jira] Commented: (GERONIMO-5553) Fail to enchance entities on Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903529#action_12903529 ] Lin Sun commented on GERONIMO-5553: --- Hi After some initial investigate, it turned out to be a user error in persistence.xml. The class should be: classorg.apache.sample.entities.Book/class while the one in the attached war has it configured as org.apache.geronimo.sample.entities.Book This is causing the entity enhancement error as it was tried to enhance the wrong class. After I made the above change, I am not seeing the entity didn't enhance error. P.S. This user case (a PU in war file) has to be a war file. If it is a WAB, it won't work, as the aries JPA doesn't support PU in WAB. Please advise if this answer is satisfactory. If so, you may close the bug. Thanks Lin Fail to enchance entities on Geronimo - Key: GERONIMO-5553 URL: https://issues.apache.org/jira/browse/GERONIMO-5553 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 3.0 Environment: OS:win xp Geronimo :3.0 20100824 build Reporter: Lu Jiang Assignee: Rick McGuire Fix For: 3.0 Attachments: booknew.war I tried to deploy a simple jpa sample on geronimo.But when persist data into database. Following exception will occur. openjpa-2.0.0-r422266:935683 nonfatal user error org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance org.apache.sample.entities.b...@97781f to PersistenceCapable failed. Ensure that it has been enhanced. FailedObject: org.apache.sample.entities.b...@97781f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4681) Create a plugin group that mirrors the JEE6 web profile.
[ https://issues.apache.org/jira/browse/GERONIMO-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4681. - Resolution: Fixed I believe this work is done in current trunk/plugingroups/javaee6-web-jetty javaee6-web-tomcat plugin groups. Create a plugin group that mirrors the JEE6 web profile. - Key: GERONIMO-4681 URL: https://issues.apache.org/jira/browse/GERONIMO-4681 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 The Web Profile for JEE6 is defined as containing the following JEE6 components: * Servlet 3.0 * JavaServer Pages (JSP) 2.2 * ExpressionLanguage (EL) 2.2 * Debugging Support for Other Languages (JSR-45) 1.0 * Standard Tag Library for JavaServer Pages (JSTL) 1.2 * JavaServer Faces (JSF) 2.0 * Common Annotations for Java Platform (JSR-250) 1.1 * Enterprise JavaBeans (EJB) 3.1 Lite * Java Transaction API (JTA) 1.1 * Java Persistence API (JPA) 2.0 Geronimo has versions of all of these, some at the equivalent level as required for the Web Profile, some at older levels. A great first step toward implementing the Web Profile would be to create a plugin group that allowed a Web-profile like install to be easily created using the JEE5 levels of the components. As JEE6 levels become available, additional plugins should be added to allow the pieces to be upgraded until we have the full stack available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [discuss]Web profile assemblies
Ok, thanks, I'll take your recommendation and keep both. :) I just removed the webservices-common and webservices-builder. We still need geronimo-webservices module since it is used by geronimo-tomcat whenever user requests to retrieve to see the wsdl via http and the work is delegated to the geronimo-webservices. So in additional to the base web profile, I think we added the following support: javamail connector javaee management/deployment jaspic (currently in) jacc Did the above sound right to people? Lin On Mon, Aug 23, 2010 at 6:10 AM, Rick McGuire rick...@gmail.com wrote: On 8/20/2010 4:36 PM, Lin Sun wrote: It seems hard to remove javamail given openejb depends on it. At least for the javamail schema for JNDI, which is used by the openejb-client. Also, I don't quite understand this comment in G roomt pom.xml - !-- Use org.apache.geronimo.javamail/geronimo-javamail_1.4_mail uber jar containing both the spec and the providers in order that users can actually use mail without advanced degrees in geronimo classloading. DO NOT add or replace this with org.apache.geronimo.specs/geronimo-javamail_1.4_spec -- dependency groupIdorg.apache.geronimo.javamail/groupId artifactIdgeronimo-javamail_1.4_mail/artifactId version1.8.1/version /dependency This seems to indicate that it is recommended to have java mail spec and impl together as dependency, instead of just using the spec jar. The uber jar is required in order for the Geronimo mail component to work correctly, since it configures the various transport implementations. If that is removed, it might be possible to revert to just the spec jar, but I think I'd recommend against it because it makes it more difficult to incrementally add the full javamail support back in. Rick Lin 1. whether we keep jaspi and javamail in web profile assembly? I personally would say no, but open to opinions.
Re: [discuss]Web profile assemblies
Yes they are all in the current web profile assembly with no plan to remove them. Thanks, Lin On Mon, Aug 23, 2010 at 4:19 PM, Donald Woods dwo...@apache.org wrote: We need connector, TranQL and RAs for OpenJPA -Donald On 8/20/10 2:29 PM, Lin Sun wrote: Ok, regarding tranql RAs, the derby ones are pulled in by system-database. The other RAs are pulled in as part of the db-connectors plugin which is part of the eba-tomcat plugin group. I think we are fine to keep these RAs in, if we want to support these different dbs like db2, oracle, sql server, etc in our web profile assembly. Lin 2. tranql: i cannot think of a reason why these resource adapters are needed for web profile... I can see geronimo-connector are needed but not the RAs. Maybe people who knows more about tranql could comment on this? Anything else I missed on this topic? Thanks Lin On Fri, Aug 20, 2010 at 11:30 AM, Jarek Gawor jga...@gmail.com wrote: On Fri, Aug 20, 2010 at 10:09 AM, Lin Sun linsun@gmail.com wrote: Hi I am checking at our web profile assemblies to ensure it met the requirements for Java EE 6 web profile and prune the unnecessary artifacts. I've been mainly look at the tomcat7-javaee6-web and I have some comments/questions: felix core: i assume we'll always ship 2 osgi runtime? Yep, that's the plan. connector (geronimo-connector, geronimo-connector-builder, connector spec): I think openejb uses connector, so we may have to keep it in. java ee management 1.1: Unchanged from Java EE 5. I assume this is provided by geronimo-management. Not sure if we could remove this? java ee deployment 1.2 related: Unchanged from Java EE 5. we may have to keep it in, to keep existing deployment work. geronimo-javamail: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-jaspi: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-webservices, geronimo-webservices-builder: think we could remove these. Yes, i think so. geronimo-yoko, yoko: think we could remove these. spec jars: we seems to include all specs in web profile assembly. things that can be removed: aspic, jaxr, jaxrpc, jaxws, dims, saaj, ccpp? I don't think this is very important. A lot of specs have dependencies on each other. So this might be a mess to sort it all out. I think we should be able to include them all even though we don't provide all of that functionality. At runtime an user should see an error that a given provider is not found. mina: think we could remove it... not sure which web profile function it related to. It's not related to web profile. It used so one can remotely login to Karaf/Geronimo shell. So this should be totally ok. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: think these are just test dependencies that were put into the assembly incorrectly. Again, not related to web profile. And these are used at runtime. We need them. Expect maybe pax-url-wrap. tranql: think we could remove it. openejb: anything we could do so that we can just have the ejb-lite function? pluto/portal: I assume these are needed for admin console so we need it. Right. Shouldn't matter for web profile. Jarek
[discuss]Web profile assemblies
Hi I am checking at our web profile assemblies to ensure it met the requirements for Java EE 6 web profile and prune the unnecessary artifacts. I've been mainly look at the tomcat7-javaee6-web and I have some comments/questions: felix core: i assume we'll always ship 2 osgi runtime? connector (geronimo-connector, geronimo-connector-builder, connector spec): I think openejb uses connector, so we may have to keep it in. java ee management 1.1: Unchanged from Java EE 5. I assume this is provided by geronimo-management. Not sure if we could remove this? java ee deployment 1.2 related: Unchanged from Java EE 5. we may have to keep it in, to keep existing deployment work. geronimo-javamail: can we get rid of it? think the answer is yes. geronimo-jaspi: can we get rid of it? think the answer is yes. geronimo-webservices, geronimo-webservices-builder: think we could remove these. geronimo-yoko, yoko: think we could remove these. spec jars: we seems to include all specs in web profile assembly. things that can be removed: aspic, jaxr, jaxrpc, jaxws, dims, saaj, ccpp? mina: think we could remove it... not sure which web profile function it related to. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: think these are just test dependencies that were put into the assembly incorrectly. tranql: think we could remove it. openejb: anything we could do so that we can just have the ejb-lite function? pluto/portal: I assume these are needed for admin console so we need it. I don't see activemq artifacts in our assembly, which is good! Thoughts/Comments appreciated, before I make any changes... Lin
Re: [discuss]Web profile assemblies
Hi, Thanks Rick/Ivan/Jarek much for the comments so far. I agree with most of the comments. I think these are what we agreed on - 1. keep extra spec jars instead of spending time to sort them out. 2. mina, yoko are needed. 3. pluto/portal are needed. 4. openejb: going to be hard to break down to ejb-lite. don't worry about it for now. 5. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: not causing any issue to have them in, leave them in for now. 6. javaee management/deployment are needed. 7. web services related are ok to remove. thus I think we need to decide the following: 1. whether we keep jaspi and javamail in web profile assembly? I personally would say no, but open to opinions. 2. tranql: i cannot think of a reason why these resource adapters are needed for web profile... I can see geronimo-connector are needed but not the RAs. Maybe people who knows more about tranql could comment on this? Anything else I missed on this topic? Thanks Lin On Fri, Aug 20, 2010 at 11:30 AM, Jarek Gawor jga...@gmail.com wrote: On Fri, Aug 20, 2010 at 10:09 AM, Lin Sun linsun@gmail.com wrote: Hi I am checking at our web profile assemblies to ensure it met the requirements for Java EE 6 web profile and prune the unnecessary artifacts. I've been mainly look at the tomcat7-javaee6-web and I have some comments/questions: felix core: i assume we'll always ship 2 osgi runtime? Yep, that's the plan. connector (geronimo-connector, geronimo-connector-builder, connector spec): I think openejb uses connector, so we may have to keep it in. java ee management 1.1: Unchanged from Java EE 5. I assume this is provided by geronimo-management. Not sure if we could remove this? java ee deployment 1.2 related: Unchanged from Java EE 5. we may have to keep it in, to keep existing deployment work. geronimo-javamail: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-jaspi: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-webservices, geronimo-webservices-builder: think we could remove these. Yes, i think so. geronimo-yoko, yoko: think we could remove these. spec jars: we seems to include all specs in web profile assembly. things that can be removed: aspic, jaxr, jaxrpc, jaxws, dims, saaj, ccpp? I don't think this is very important. A lot of specs have dependencies on each other. So this might be a mess to sort it all out. I think we should be able to include them all even though we don't provide all of that functionality. At runtime an user should see an error that a given provider is not found. mina: think we could remove it... not sure which web profile function it related to. It's not related to web profile. It used so one can remotely login to Karaf/Geronimo shell. So this should be totally ok. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: think these are just test dependencies that were put into the assembly incorrectly. Again, not related to web profile. And these are used at runtime. We need them. Expect maybe pax-url-wrap. tranql: think we could remove it. openejb: anything we could do so that we can just have the ejb-lite function? pluto/portal: I assume these are needed for admin console so we need it. Right. Shouldn't matter for web profile. Jarek
Re: [discuss]Web profile assemblies
Ok, regarding tranql RAs, the derby ones are pulled in by system-database. The other RAs are pulled in as part of the db-connectors plugin which is part of the eba-tomcat plugin group. I think we are fine to keep these RAs in, if we want to support these different dbs like db2, oracle, sql server, etc in our web profile assembly. Lin 2. tranql: i cannot think of a reason why these resource adapters are needed for web profile... I can see geronimo-connector are needed but not the RAs. Maybe people who knows more about tranql could comment on this? Anything else I missed on this topic? Thanks Lin On Fri, Aug 20, 2010 at 11:30 AM, Jarek Gawor jga...@gmail.com wrote: On Fri, Aug 20, 2010 at 10:09 AM, Lin Sun linsun@gmail.com wrote: Hi I am checking at our web profile assemblies to ensure it met the requirements for Java EE 6 web profile and prune the unnecessary artifacts. I've been mainly look at the tomcat7-javaee6-web and I have some comments/questions: felix core: i assume we'll always ship 2 osgi runtime? Yep, that's the plan. connector (geronimo-connector, geronimo-connector-builder, connector spec): I think openejb uses connector, so we may have to keep it in. java ee management 1.1: Unchanged from Java EE 5. I assume this is provided by geronimo-management. Not sure if we could remove this? java ee deployment 1.2 related: Unchanged from Java EE 5. we may have to keep it in, to keep existing deployment work. geronimo-javamail: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-jaspi: can we get rid of it? think the answer is yes. Maybe. Might be nicer to include it. geronimo-webservices, geronimo-webservices-builder: think we could remove these. Yes, i think so. geronimo-yoko, yoko: think we could remove these. spec jars: we seems to include all specs in web profile assembly. things that can be removed: aspic, jaxr, jaxrpc, jaxws, dims, saaj, ccpp? I don't think this is very important. A lot of specs have dependencies on each other. So this might be a mess to sort it all out. I think we should be able to include them all even though we don't provide all of that functionality. At runtime an user should see an error that a given provider is not found. mina: think we could remove it... not sure which web profile function it related to. It's not related to web profile. It used so one can remotely login to Karaf/Geronimo shell. So this should be totally ok. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: think these are just test dependencies that were put into the assembly incorrectly. Again, not related to web profile. And these are used at runtime. We need them. Expect maybe pax-url-wrap. tranql: think we could remove it. openejb: anything we could do so that we can just have the ejb-lite function? pluto/portal: I assume these are needed for admin console so we need it. Right. Shouldn't matter for web profile. Jarek
Re: [discuss]Web profile assemblies
It seems hard to remove javamail given openejb depends on it. At least for the javamail schema for JNDI, which is used by the openejb-client. Also, I don't quite understand this comment in G roomt pom.xml - !-- Use org.apache.geronimo.javamail/geronimo-javamail_1.4_mail uber jar containing both the spec and the providers in order that users can actually use mail without advanced degrees in geronimo classloading. DO NOT add or replace this with org.apache.geronimo.specs/geronimo-javamail_1.4_spec -- dependency groupIdorg.apache.geronimo.javamail/groupId artifactIdgeronimo-javamail_1.4_mail/artifactId version1.8.1/version /dependency This seems to indicate that it is recommended to have java mail spec and impl together as dependency, instead of just using the spec jar. Lin 1. whether we keep jaspi and javamail in web profile assembly? I personally would say no, but open to opinions.
Re: Setup instructions for the standalone tcks?
Hi Does anyone know the latest test status of these standalone TCKs? I am building my G 3.0 server and intend to run these TCKs one by one, except the at-inject-tck and the jcdi-tck. The at-inject tck doesn't need a full G server and it all pass now. From what I heard, the jcdi-tck isn't ready to run yet. Thanks, Lin On Wed, Aug 18, 2010 at 12:35 PM, Donald Woods dwo...@apache.org wrote: Moving to dev@ list since we're discussing the public ASL 2.0 licensed TCKS Yep, but nothing in the wiki yet for the public TCKs Just build the top level projects first, which builds some integration artifacts: cd geronimo/tck/branches/3.0/ mvn clean install Then run either BVAL or JCDI TCKs - cd validator-tck-runner mvn test -Pincontainer,geronimo-assembly -DassemblyId=tomcat7-javaee6 or mvn test -Pincontainer -Dgeronimo.home=/Users/x/geronimo/trunk/assemblies/. -Donald On 8/18/10 10:21 AM, Jarek Gawor wrote: For the standalone tcks, in each 'runner' directory I put a README.TXT file that describes how to the given tck. I hope it was kept it up-to-date. Jarek On Wed, Aug 18, 2010 at 8:53 AM, Rick McGuire rick...@gmail.com wrote: Are there any setup instructions for configuring/running the different standalone tcks? Rick
Re: Setup instructions for the standalone tcks?
Hi I tried to run the following: jaxb-tck-runner, stax-tck-runner it both has run.sh scripts and requires JAXB_HOME or STAX_HOME to be set. Anyone knows where these variables should be set to? Thanks Lin On Wed, Aug 18, 2010 at 3:40 PM, Lin Sun linsun@gmail.com wrote: Hi Does anyone know the latest test status of these standalone TCKs? I am building my G 3.0 server and intend to run these TCKs one by one, except the at-inject-tck and the jcdi-tck. The at-inject tck doesn't need a full G server and it all pass now. From what I heard, the jcdi-tck isn't ready to run yet. Thanks, Lin On Wed, Aug 18, 2010 at 12:35 PM, Donald Woods dwo...@apache.org wrote: Moving to dev@ list since we're discussing the public ASL 2.0 licensed TCKS Yep, but nothing in the wiki yet for the public TCKs Just build the top level projects first, which builds some integration artifacts: cd geronimo/tck/branches/3.0/ mvn clean install Then run either BVAL or JCDI TCKs - cd validator-tck-runner mvn test -Pincontainer,geronimo-assembly -DassemblyId=tomcat7-javaee6 or mvn test -Pincontainer -Dgeronimo.home=/Users/x/geronimo/trunk/assemblies/. -Donald On 8/18/10 10:21 AM, Jarek Gawor wrote: For the standalone tcks, in each 'runner' directory I put a README.TXT file that describes how to the given tck. I hope it was kept it up-to-date. Jarek On Wed, Aug 18, 2010 at 8:53 AM, Rick McGuire rick...@gmail.com wrote: Are there any setup instructions for configuring/running the different standalone tcks? Rick
Re: [DISCUSS] Policy for granting access to Geronimo TCK materials
I agree too! Lin On Wed, Aug 11, 2010 at 8:07 AM, Kevan Miller kevan.mil...@gmail.com wrote: All, Our policy for granting access to the Geronimo TCK test harness is described here -- https://cwiki.apache.org/GMOxPMGT/geronimo-project-policies.html#GeronimoProjectPolicies-AccesstoTCK The policy describes a 72 hour waiting period when granting non-Geronimo committers read-only access to our TCK test harness. This period was intended to allow the Geronimo PMC time to provide oversight on these requests. Presumably, a PMC member could block someone's request (though this has never occurred and I can't, frankly, imagine a case where we would block someone's request). If we had our preference, our TCK test harness would not be in a private svn. It would instead be publicly readable by all. I would like to remove the 72 hour waiting period from our policy. If an ASF committer requests access to our test harness, I believe we should grant this access immediately. The 72 hour waiting period might have been more meaningful when the Geronimo project maintained and distributed the Sun (now Oracle) TCK. As a reminder, these materials are obtained via an agreement between the ASF and Sun/Oracle. To gain access to these materials, an ASF committer must sign an NDA. We still maintain/distribute the Sun/Oracle TCK for Java EE 5. However, the JCP project is maintaining the newer TCK materials. The JCP does not have a waiting period for granting access to the JCP maintained TCK materials. Comments? Objections? If I don't hear any objections, I'll plan on updating our policy and removing the 72 hour window... --kevan
[discuss]atinject tck
Hi I have been investigating how to run the JSR 330 tck (also called the atinject tck), as this is a requirement for Java EE 6 compliance. I am able to check out the open web bean project and run its atinject tck from the open web bean project checkout dir, using the atinject tck runner provided by open web bean Basically the atinject tck runner deploys the tck test classes (note it is not an archive) to a stand-alone test container and the atinect tck tests verifies various fields/constructors/methods are injected correctly. The special part of the atinject tck is that there is no Java EE archive and all tests are written as junit tests. My first thought is we could reuse the atinject tck runner from open web bean project to run the tck, but the concern is that the tests are only deployed to a stand-alone test container instead of the Geronimo server. So I am not sure if that is valid. My current thoughts are that atinject tck is relatively small and are junit tests thus it is reasonable to run in a stand-alone test container. The JCDI(JSR 299) tck overlaps some of the atinject tck and should run with the real Application Server like Geronimo. If we also agree with this approach, I think we can just reuse the atinject tck runner in open web bean. WDYT? Lin -- Forwarded message -- From: Kevan Miller kevan.mil...@gmail.com Date: Tue, Aug 10, 2010 at 10:43 PM Subject: Re: JCDI and Bean Validation TCKs To: dev@geronimo.apache.org On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote: Ok, it sounds like more people prefer to move these tcks into a public svn location. So I guess we should create a https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks over. There should be no problem with moving the following modules (since it's all Apache licensed stuff): 1) jboss-test-harness-geronimo - integration code between jboss test harness geronimo which is used by #2 and #3 2) jcdi-testsuite - jcdi tck runner 3) validator-testsuite - bean validation tck runner All, Please note that the above TCK tests are in our public SVN. Unlike the mainstream Java EE TCK tests, which we are required to keep private, these tests are Apache licensed. We can discuss them openly. This means we have TCK materials in two places (public svn and private svn). I *much* prefer to have our TCK materials in public svn. So, although it complicates some things, IMO, we should err on the side of openness, rather than simplicity... --kevan
Re: [discuss]atinject tck
Hi Donald Thanks for the reply. I am not familar with BVAL tck. Can you point me the suiteXmlFiles? Also does the BVAL tck provides a valid archive to be deployed to a App server? Please see more comments in line. Lin On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote: It looks like the same general setup as the BVAL tck, in that it uses the surefire plugin and a suiteXmlFiles which is either provided in the downloaded TCK files or provided locally (which I don't think we can use the open web beans overrides unless we have TCK challenges approved by Oracle.) Could you please explain why we could not use the tck runner from open web beans? If we want to run the tests ourselves, we could copy some files to make it happen. They are all under ASL v2.0. atinject tck itself didn't provide any instruction on how to run them, other than the java doc. In the javadoc, it indicates the test needs to be configured with your injector. There is no mentioning of running this against a real App Server. The fact that they didn't provide a java ee archive and only provided .class files made me believe deploy/configure the class files onto the injector is sufficient.
Re: [discuss]atinject tck
BTW, I found this - http://groups.google.com/group/atinject-observer/browse_thread/thread/6eb81864296495e3/7834cf0821c8f358?#7834cf0821c8f358 I think the instruction were from the authors of the tck, while they gave examples of running this tck by itself with the injector, which in our case is the open web bean jar(s). Lin On Wed, Aug 11, 2010 at 12:58 PM, Lin Sun linsun@gmail.com wrote: Hi Donald Thanks for the reply. I am not familar with BVAL tck. Can you point me the suiteXmlFiles? Also does the BVAL tck provides a valid archive to be deployed to a App server? Please see more comments in line. Lin On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote: It looks like the same general setup as the BVAL tck, in that it uses the surefire plugin and a suiteXmlFiles which is either provided in the downloaded TCK files or provided locally (which I don't think we can use the open web beans overrides unless we have TCK challenges approved by Oracle.) Could you please explain why we could not use the tck runner from open web beans? If we want to run the tests ourselves, we could copy some files to make it happen. They are all under ASL v2.0. atinject tck itself didn't provide any instruction on how to run them, other than the java doc. In the javadoc, it indicates the test needs to be configured with your injector. There is no mentioning of running this against a real App Server. The fact that they didn't provide a java ee archive and only provided .class files made me believe deploy/configure the class files onto the injector is sufficient.
Re: [discuss]atinject tck
Thanks for the link - that is rather detailed and matches what I discovered so far. I have no prob in having their tck runner in our tck dir. I'll work on that. Lin On Wed, Aug 11, 2010 at 3:16 PM, Donald Woods dwo...@apache.org wrote: Yep, finally found the OWB email talking about the TCKs (see Q/A #3) - http://mail-archives.apache.org/mod_mbox/openwebbeans-dev/201001.mbox/%3c683599.32550...@web38207.mail.mud.yahoo.com%3e For build automation, I'd prefer we have copies of these OWB TCK projects in our own svn in the geronimo/tck area. -Donald On 8/11/10 12:56 PM, Jarek Gawor wrote: Donald, As Lin pointed out the atinject is a bit different. Both JCDI and Bean Validation TCKs can be run in standalone and in-container mode. For Geronimo we run them in in-container mode. However, the atinject TCK seems to only support the standalone mode. So the question is, is it enough to just run the atinject TCK in standalone mode or do we have to write some extra code to ensure it runs in in-container mode with Geronimo? Jarek On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods dwo...@apache.org wrote: It looks like the same general setup as the BVAL tck, in that it uses the surefire plugin and a suiteXmlFiles which is either provided in the downloaded TCK files or provided locally (which I don't think we can use the open web beans overrides unless we have TCK challenges approved by Oracle.) You should be able to copy the content from https://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tck/ over into our geronimo/tck/branches/3.0/ area and make a atinject-tck-runner project similar to the validator-tck-runner. Jarek already created the required jboss-test-harness-geronimo module to allow the JBoss TCK testharness to start/stop a Geronimo server, so the biggest part of the effort would be mapping the openwebbeans profile from Tomcat over to using Geronimo Since the JBoss provided TCKs use ASL 2.0, take a look at their website, which usually describes in pretty good detail how to run the TCKs in other app servers. -Donald On 8/11/10 9:30 AM, Lin Sun wrote: Hi I have been investigating how to run the JSR 330 tck (also called the atinject tck), as this is a requirement for Java EE 6 compliance. I am able to check out the open web bean project and run its atinject tck from the open web bean project checkout dir, using the atinject tck runner provided by open web bean Basically the atinject tck runner deploys the tck test classes (note it is not an archive) to a stand-alone test container and the atinect tck tests verifies various fields/constructors/methods are injected correctly. The special part of the atinject tck is that there is no Java EE archive and all tests are written as junit tests. My first thought is we could reuse the atinject tck runner from open web bean project to run the tck, but the concern is that the tests are only deployed to a stand-alone test container instead of the Geronimo server. So I am not sure if that is valid. My current thoughts are that atinject tck is relatively small and are junit tests thus it is reasonable to run in a stand-alone test container. The JCDI(JSR 299) tck overlaps some of the atinject tck and should run with the real Application Server like Geronimo. If we also agree with this approach, I think we can just reuse the atinject tck runner in open web bean. WDYT? Lin -- Forwarded message -- From: Kevan Miller kevan.mil...@gmail.com Date: Tue, Aug 10, 2010 at 10:43 PM Subject: Re: JCDI and Bean Validation TCKs To: dev@geronimo.apache.org On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote: Ok, it sounds like more people prefer to move these tcks into a public svn location. So I guess we should create a https://svn.apache.org/repos/asf/geronimo/tck repo and move the tcks over. There should be no problem with moving the following modules (since it's all Apache licensed stuff): 1) jboss-test-harness-geronimo - integration code between jboss test harness geronimo which is used by #2 and #3 2) jcdi-testsuite - jcdi tck runner 3) validator-testsuite - bean validation tck runner All, Please note that the above TCK tests are in our public SVN. Unlike the mainstream Java EE TCK tests, which we are required to keep private, these tests are Apache licensed. We can discuss them openly. This means we have TCK materials in two places (public svn and private svn). I *much* prefer to have our TCK materials in public svn. So, although it complicates some things, IMO, we should err on the side of openness, rather than simplicity... --kevan
Re: Web services in G 3.0-M1
+1 sounds reasonable Lin On Fri, May 21, 2010 at 6:07 AM, Rick McGuire rick...@gmail.com wrote: Jarek Gawor brought to my attention that the web services support in 3.0 has not yet gotten any testing or attention. While it builds, it is in a state where it doesn't really work. Since the focus of the M1 release is on the new Aries support and the Java EE 6 Web Profile, I think it makes sense to remove the web services components from the M1 release. Web services are not part of the Web Profile, so including them in the 3.0 Web Profile release was a bit of a stretch goal to begin with. Since this support might not be in the 3.0 final release and isn't really functional at this point anyway, I'm going to be removing the web services support from the M1 branch. Rick
Re: Runtime entity enhancement for OSGi applications
Seems No. 3 is the right approach, given that there is no overhead on the user side and it gives the ability to add the imports at the last minute, before the PU is resolved. No. 2 gives some extra work on the user side which can make the PU not portable. Np. 4 has to be done when PU is installed, and it is possible the provider is not even there yet. No. 5 can be confusing to the user as a fragment is attached to their PU. Lin On Tue, May 18, 2010 at 10:41 PM, Jarek Gawor jga...@gmail.com wrote: Hi all, I was looking into getting the runtime JPA entity enhancement for OSGi applications working in Geronimo. With some modifications to the Aries JPA code and some to Geronimo I was able to get runtime enhancement working (using the java agent approach) but with one major issue: The bundle that contains the persistence unit must be able to load some persistence provider specific (in our case openjpa) classes. That's because during the bytecode weaving, openjpa adds some openjpa specific interfaces to the entity classes. So how should we deal with this issue in Geronimo? 1) We could do nothing and just say we don't support runtime enhancement. 2) We could support runtime enhancement and require that bundles with PU have DynamicImport-Package: * header. 3) Use framework classloader hooks to dynamically add imports for the persistence provider specific packages to the bundles with PU . That of course, would rely on framework specific extensions. I know Equinox has such hooks and I think recently something similar was added to Felix. 4) Provide some url handler, e.g. jpa which would enhance the entity classes and add right imports during the install. Something similar to the webbundle url handler for web application archives. Of course, we would have to make sure the bundles with PU get installed via the url handler. 5) Have some kind of an extender that would generate a fragment bundle (with right persistence provider imports) and attach it to the bundle with PU. Or something similar that would require manifest modification or generation of additional bundle. Thoughts? Jarek
Re: OSGi version for Geronimo packages
Hi I think no. 3 is cool. some other qualifiers that I can think of are 3.0.0.m1, 3.0.0.m2, 3.0.0.release Lin On Thu, May 6, 2010 at 12:21 AM, Jarek Gawor jga...@gmail.com wrote: Hi, Before the milestone release we might have to figure out what osgi version (if any) the Geronimo packages should be exported at. I can think of a few possibilities: 1) No version exported for milestone releases. In the final release everything would be exported with 3.0.0 version. 2) Use version 3.0.0 for milestones and final release. Milestones are milestones and should not be used once the final is out. 3) Add some qualifier to the osgi version for milestone and final releases. We just need to be careful to pick the right qualifiers so that osgi resolves to the latest version. For example for milestones we could assign 3.0.0.M1 or 3.0.0.M2 but for the final we would have to assign 3.0.0.final or some other qualifier that is greater then 'Mx' using String.compareTo() rules. Thoughts or any other possibilities? I like #3 (or some version of it) but I'm also ok with #2. Jarek
Re: OSGi version for Geronimo packages
Right, that is why the final release needs to be called 3.0.0.final or 3.0.0.release and cannot be called 3.0.0! 3.0.0.final 3.0.0.M1 3.0.0.release 3.0.0.m1 Lin On Thu, May 6, 2010 at 9:42 AM, Guillaume Nodet gno...@gmail.com wrote: Keep in mind that in osgi, 3.0.0.m1 3.0.0 !!! On Thu, May 6, 2010 at 15:24, Lin Sun linsun@gmail.com wrote: Hi I think no. 3 is cool. some other qualifiers that I can think of are 3.0.0.m1, 3.0.0.m2, 3.0.0.release Lin On Thu, May 6, 2010 at 12:21 AM, Jarek Gawor jga...@gmail.com wrote: Hi, Before the milestone release we might have to figure out what osgi version (if any) the Geronimo packages should be exported at. I can think of a few possibilities: 1) No version exported for milestone releases. In the final release everything would be exported with 3.0.0 version. 2) Use version 3.0.0 for milestones and final release. Milestones are milestones and should not be used once the final is out. 3) Add some qualifier to the osgi version for milestone and final releases. We just need to be careful to pick the right qualifiers so that osgi resolves to the latest version. For example for milestones we could assign 3.0.0.M1 or 3.0.0.M2 but for the final we would have to assign 3.0.0.final or some other qualifier that is greater then 'Mx' using String.compareTo() rules. Thoughts or any other possibilities? I like #3 (or some version of it) but I'm also ok with #2. Jarek -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [ANNOUNCE] Congrats Donald Woods! New ASF Member
Congrats Donald! Lin On Sun, May 2, 2010 at 9:28 AM, Kevan Miller kevan.mil...@gmail.com wrote: Wanted to let the Geronimo community know that Donald Woods is a new member of the ASF. The ASF membership elected Donald in recognition of his many contributions to Geronimo, OpenJPA, and Incubator projects. Congrats to Donald on this well deserved achievement! --kevan
Re: osgi finder method to xbean?
That sounds a great idea to me! Lin On Fri, Apr 23, 2010 at 8:20 PM, David Jencks david_jen...@yahoo.com wrote: Jarek has written a bunch of useful looking osgi utility type stuff currently in geronimo-kernel. At least one of the classes, BundleAnnotationFinder, could be quite useful to other projects, so it might be a good idea to move it to xbean-finder. However, it uses many of the other classes. So how about moving all the non-geronimo-specific osgi utility classes to a new xbean-osgi that can be used by the osgi support in xbean-finder? thanks david jencks
Re: Deploying Aries Blog sample AriesTrader on Geronimo
Great news. Congrats! Lin On Mon, Mar 29, 2010 at 4:43 PM, Jarek Gawor jga...@gmail.com wrote: Hi all, I recently integrated the JTA and JPA pieces from Aries in Geronimo and exposed connection factories in OSGi service registry. With these changes we now have all the main pieces in place to deploy unmodified Aries Blog sample AriesTrader on Geronimo. Here's how to do it: 1) Make sure you have the latest trunk build. I used tomcat ee 6 assembly but things should also work with the jetty assembly. 2) Deploy the attached aries-datasource connector. It will create the data sources database tables for both samples. To deploy the connector do: ./bin/deploy -u system -p manager deploy ~/.m2/repository/org/tranql/tranql-connector-derby-embed-xa/1.5/tranql-connector-derby-embed-xa-1.5.rar aries-datasource.xml 3) Build samples module in Aries trunk. To deploy the Blog sample do: ./bin/deploy -u system -p manager deploy aries trunk/samples/blog/blog-jpa-eba/target/org.apache.aries.samples.blog.jpa.eba-0.1-incubating-SNAPSHOT.eba or to deploy AriesTrader do: ./bin/deploy -u system -p manager deploy aries trunk/samples/ariestrader-sample/assemblies/ariestrader-all-eba/target/org.apache.aries.samples.ariestrader.all-0.1-incubating-SNAPSHOT.eba If all goes well the Blog sample should be available under http://localhost:8080/blog and AriesTrader under http://localhost:8080/ariestrader. Btw, when running the deploy command you might see some Address already in use exceptions. They can be ignored. Let me know if you have any problems, Jarek
Re: osgi core/compendium from felix or osgi?
I think there was a similar discussion on aries list last year, and we decided to use the ones from osgi (which is more current and official). Lin On Tue, Mar 9, 2010 at 8:04 PM, David Jencks david_jen...@yahoo.com wrote: I noticed some comments on a felix list that I think indicated they thought the core and compendium bundles from osgi were more appropriate to use than the ones from felix. Should we switch? I have the changes locally but thought I should ask before applying them. thanks david jencks
Re: Understanding the partial=true; mandatory:=partial trick
Hi, thanks for trying that. I guess the difference of your scenario vs. what I've tried before is that your scenario imports the package but also exports the package(like bundle 2) Lin On Thu, Dec 10, 2009 at 4:50 PM, Jarek Gawor jga...@gmail.com wrote: On Wed, Dec 9, 2009 at 1:06 PM, Lin Sun linsun@gmail.com wrote: Hi, Do we have to use Require-Bundle here? I would think Import-Package of packageX with the mandatory attribute should wire bundle 2 to bundle 1. Here's my understanding of your scenario: Bundle1: Export-Package:x;partial=true;mandatory:=partial Bundle2: Import-Package:x;partial=true Export-Package:x Any other bundles - should be wired to bundle 2: Import-Package:x That's a good question. I tried it and it didn't work. I assume it was because if Bundle 3 was wired to Bundle 2 it was only able to see classes local to Bundle 2. That is, it acted like the Bundle 2 wasn't re-exporting the additional classes from Bundle 1. But I guess if Bundle 2 Required-Bundle: Bundle 1 these additional classes from Bundle 1 would be visible to Bundle 3. Jarek
Re: [VOTE] geronimo 2.2 release (2nd try)
+1 able to start, stop the server, visited admin console and verified a few link function okay. Thanks for pulling together this release David. I visited the jira list, it contains hundreds of items! Lin On Tue, Dec 8, 2009 at 2:56 AM, David Jencks david_jen...@yahoo.com wrote: I've managed to come up with a 2nd 2.2 release candidate built using the maven-release-plugin. This includes Kevan;s fixes of source headers and a warning removal. See the jira issues here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220styleName=Htmlversion=12312965 Staged to https://repository.apache.org/content/repositories/orgapachegeronimo-043/ The main artifacts up for vote are the source release archives https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip If you vote you should at least examine these and make sure something plausible builds from them. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) Many thanks david jencks
Re: Understanding the partial=true; mandatory:=partial trick
Hi, Do we have to use Require-Bundle here? I would think Import-Package of packageX with the mandatory attribute should wire bundle 2 to bundle 1. Here's my understanding of your scenario: Bundle1: Export-Package:x;partial=true;mandatory:=partial Bundle2: Import-Package:x;partial=true Export-Package:x Any other bundles - should be wired to bundle 2: Import-Package:x Lin On Tue, Dec 8, 2009 at 11:27 PM, Jarek Gawor jga...@gmail.com wrote: The best solution is of course the remove the split package problem in the first place. But if that's not possible, another solution is to combine the mandatory attribute trick with Require-Bundle. That is, bundle 1 exports package X with some mandatory attribute and bundle 2 has Require-Bundle on bundle 1 (and also exports package X). So all imports on package X would always be wired to bundle 2 and bundle 2 would have access to all classes in package X. Do I have that right?
Re: Understanding the partial=true; mandatory:=partial trick
Interesting. I used other mandatory attribute without Require-Bundle fine before. And partial here is just same as other mandatory attribute, right? Anyway this should be something quick to try to see if we could avoid Require-Bundle Lin On Wed, Dec 9, 2009 at 1:26 PM, Rick McGuire rick...@gmail.com wrote: Everything I've seen about using partial=true in the core specification also indicates that Require-Bundle is necessary to get everything wired up together. I don't see anything in the core specification that indicates partial=true has any meaning on an Import-Package. Section 3.12.1 specifically states: ...only bundles using the Require-Bundle header can have split packages. Which pretty much states that Require-Bundle needs to be used. Rick Lin On Tue, Dec 8, 2009 at 11:27 PM, Jarek Gawor jga...@gmail.com wrote: The best solution is of course the remove the split package problem in the first place. But if that's not possible, another solution is to combine the mandatory attribute trick with Require-Bundle. That is, bundle 1 exports package X with some mandatory attribute and bundle 2 has Require-Bundle on bundle 1 (and also exports package X). So all imports on package X would always be wired to bundle 2 and bundle 2 would have access to all classes in package X. Do I have that right?
Re: Fun with ears and osgi
Hi, I wonder if ear should continue working as what what they were working before and would not be installed as bundles in OSGi framework. And if users want to leverage OSGi functions in ear, they would have to migrate their ear file to an Aries Application (http://incubator.apache.org/aries/applications.html). Lin On Thu, Dec 3, 2009 at 8:26 PM, David Jencks david_jen...@yahoo.com wrote: Working on the admin console I've run into the problem that ears most naturally translate into more than one osgi bundle -- at least one bundle for each web module, maybe one per module. Right now the deployment system is putting the wars inside the car file, just like in 2.2, but as bundles. It looks like we are generating sort of reasonable metadata for the embedded bundles but there is certainly no way to access them. I can think of several approaches here: 1. For now at least, just have one bundle per ear. This is probably just a couple lines to change and should work for all reasonable apps. 2. modify the pax mvn url handler so it can deal with bundles hidden inside bundles. This has the advantage that an ear is still a single artifact but is otherwise slightly weird. 3. modify geronimo to package the wars as entirely separate bundles from the main ear. Maybe we can use the war module name as the classifier. In the interests of getting something working quickly I will probably try (1) first. I'm intrigued by (2) but would certainly appreciate some discussion before I spend much time on either (2) or (3). and maybe someone has an even better idea. I assume there is a similar problem for app clients thanks david jencks
Re: svn commit: r887267 - in /geronimo/server/trunk/plugins/aries: ./ aries-deployer/ aries-deployer/src/ aries-deployer/src/main/ aries-deployer/src/main/history/ aries-deployer/src/main/plan/ ger
Hi Jarek
Great progress! I have 2 minor comments, let me know if I misread it -
1. You may want to unget the ApplicationMetadata manager service
2. the deploymentException message looks weird - Unable to copy app
client module jar into configuration
Thanks
Lin
On Fri, Dec 4, 2009 at 11:59 AM, ga...@apache.org wrote:
Author: gawor
Date: Fri Dec 4 16:59:20 2009
New Revision: 887267
URL: http://svn.apache.org/viewvc?rev=887267view=rev
Log:
GERONIMO-4971: basic structure for deployer for aries applications. The
deployer communicates with Aries' ApplicationMetadataManager service to parse
the application manifest
Added:
geronimo/server/trunk/plugins/aries/
geronimo/server/trunk/plugins/aries/aries-deployer/
geronimo/server/trunk/plugins/aries/aries-deployer/pom.xml (with props)
geronimo/server/trunk/plugins/aries/aries-deployer/src/
geronimo/server/trunk/plugins/aries/aries-deployer/src/main/
geronimo/server/trunk/plugins/aries/aries-deployer/src/main/history/
geronimo/server/trunk/plugins/aries/aries-deployer/src/main/history/dependencies.xml
(with props)
geronimo/server/trunk/plugins/aries/aries-deployer/src/main/plan/
geronimo/server/trunk/plugins/aries/aries-deployer/src/main/plan/plan.xml
(with props)
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/pom.xml (with
props)
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/apache/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/apache/geronimo/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/apache/geronimo/aries/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/apache/geronimo/aries/builder/
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/apache/geronimo/aries/builder/AriesAppModule.java
(with props)
geronimo/server/trunk/plugins/aries/geronimo-aries-builder/src/main/java/org/apache/geronimo/aries/builder/AriesAppModuleBuilder.java
(with props)
geronimo/server/trunk/plugins/aries/pom.xml (with props)
Added: geronimo/server/trunk/plugins/aries/aries-deployer/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/aries/aries-deployer/pom.xml?rev=887267view=auto
==
--- geronimo/server/trunk/plugins/aries/aries-deployer/pom.xml (added)
+++ geronimo/server/trunk/plugins/aries/aries-deployer/pom.xml Fri Dec 4
16:59:20 2009
@@ -0,0 +1,63 @@
+?xml version=1.0 encoding=ISO-8859-1?
+!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the License); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an AS IS BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+--
+
+!-- $Rev$ $Date$ --
+
+project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
+
+modelVersion4.0.0/modelVersion
+
+parent
+groupIdorg.apache.geronimo.plugins/groupId
+artifactIdaries/artifactId
+version3.0-SNAPSHOT/version
+/parent
+
+groupIdorg.apache.geronimo.configs/groupId
+artifactIdaries-deployer/artifactId
+nameGeronimo Plugins, Aries :: Deployer/name
+packagingcar/packaging
+
+dependencies
+!-- parent --
+dependency
+groupIdorg.apache.geronimo.configs/groupId
+artifactIdj2ee-deployer/artifactId
+version${version}/version
+typecar/type
+/dependency
+
+dependency
+groupIdorg.apache.geronimo.modules/groupId
+artifactIdgeronimo-aries-builder/artifactId
+version${version}/version
+/dependency
+/dependencies
+
+build
+plugins
+plugin
+
[jira] Commented: (GERONIMO-4971) Recognize Aries applications in Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12785488#action_12785488 ] Lin Sun commented on GERONIMO-4971: --- FYI - The org.apache.aries.application.ApplicationMetadataManager that is published by blueprint as an OSGi service can be used to parse Application.mf file. Recognize Aries applications in Geronimo Key: GERONIMO-4971 URL: https://issues.apache.org/jira/browse/GERONIMO-4971 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0 Reporter: Jarek Gawor Assignee: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: RFC 66 and Geronimo
Hi, see comments below. Lin On Thu, Oct 8, 2009 at 5:48 AM, Rick McGuire rick...@gmail.com wrote: The URL handler is a different stage of the processing. That gets involved at the installation time of the bundle, and causes a transform of a standard WAR into a WAB, which then gets processed by the extender. Once the WAB has been installed and started, that's when the WAB extender kicks in, and at that point, there's no opportunity to perform the transformation. I think Geronimo has full control when the bundle/war is installed and this can be triggered by geronimo's existing deployment mechanisms (such as hot deployment, command line deployer or admin console deployment). I kinda think it is best to do this type of geronimo specific conversion at the install time, because it would be too late if we do it after the bundle is resolved/started. The web extender defined by RFC 66 is something that we must implement, but we could do stuff beyond what is defined for the web extender. :) What I am proposing is to develop a geronimo url handler that can convert the war file into the geronimo plugin (or whatever artifact that can be deployed to geronimo's web server). For example, when a war file is installed, we can use the following as location identifier of BundleContext.install(String loc). webbundle:geronimo:file:///Users/linsun/test1.war?Web-ContextPath=/linsun This will invoke the webbundle url handler which will convert the war to a wab for Geronimo. Then it will invoke the geronimo url handler which will convert the wab to geronimo plugin (or whatever artifact that can be deployed to geronimo's web server). Then the bundle is installed and resolved. Then the web extender defined by rfc 66 kicks in and listens to the bundle events. Should items are there for a reason and at least an attempt should be made to satisfy the language of the specification. If it turns out to be impossible, so be it, but the possibility of fully implementing that needs to be made. Right i just want to point that out. :)
Re: RFC 66 and Geronimo
What I meant was that geronimo has full control of artifact deployment when user is deploying through the geronimo supported deployment mechanism. You are right that a bundle can use BundleContext.install() to install any bundle at any time, but that doesn't mean it will work or it is supported. Even with RFC 66, a bundle that uses BundleContext.install() to install a war would fail only if they use the webbundle: url schema and use it correctly. On Thu, Oct 8, 2009 at 9:32 AM, Rick McGuire rick...@gmail.com wrote: No, Geronimo does not necessarily have full control of when a WAB bundle is installed. Any other bundle can use BundleContext.install() to install any bundle at any time, and a compliant RFC 66 implementation needs to be able to recognize that a WAB has been installed and react to it. I believe the RFC 66 impl only needs to recognize a WAB is starting/stopping (not installed) and react to it. The webbundle: URL scheme is for installing a WAR (not a WAB) and performs a conversion into a WAB bundle that is then processed by the extender when the converted bundle is started. The extender only takes control once a bundle containing the appropriate header manifest information has been started, at which point strategies that rely on altering the content of the bundle will not work. Right, I agree with what you said here, but I am not proposing to do something with the extender. I am proposing another url handler which is invoked when the bundle is installed and before the bundle is resolved/starting. I don't think what I am proposing has any conflict which what RFC 66 describes. Lin
Re: RFC 66 and Geronimo
Ok, I was under the impression that you need to modify the bundle before the bundle is started/starting, thus I was suggesting the url handler to do so. Lin On Thu, Oct 8, 2009 at 10:17 AM, Rick McGuire rick...@gmail.com wrote: I'm not trying to implement a new way for Geronimo to convert a WAB bundle into Geronimo artifacts that require pre-install conversion. I'm working on an RFC 66 extender that recognizes that a WAB bundle has been started and deploys this to the Geronimo hosted container implementing the behavior specified in RFC 66. This means that the only additional metadata in the bundle is the manifest header that specifies the context path. At this point, it is not possible to do a conversion on the bundle, it's too late for that. The deployment needs to be made using the information that available in the bundle already without requiring any side metadata such as an external Geronimo deployment descriptor. This essentially requires much of the same decision making as is used for JEE WAR installs, but needs to be done using runtime resources rather than by converting this into a static configuration. Rick Lin
Re: RFC 66 and Geronimo
Hi, Please see comments below, Thanks Lin On Wed, Oct 7, 2009 at 9:51 AM, Rick McGuire rick...@gmail.com wrote: For a WAB deployment, the extender become involved after the bundle has been installed and started. At this stage, there's no opportunity to modify the bundle contents. You are right that the extender gets notified when the bundle is already resolved and starting/started. However, I wonder if we want to modify the bundle contents through another URL handler like the webbundle url handler defined by RFC 66. I think RFC 66 mentions that the web bundle url handler should work with other url handlers. For example, we can have a geronimo specific url handler that handles the modifying of the bundle content to add Geronimo specific configurations during the installation of the bundle (when BundleContext.installBundle is invoked) and leverage the webbundle url handler from the Apache Aries project to do the manifest generation for the WAR to WAB conversion. Additionally, there is an RFC 66 requirement that if the bundle uses lazy activation, the bundle should not get activated until the first request for a servlet instance occurs (i.e., no class loading requests until deployment). I don't think the RFC mandates that, because it is the wording should that is used here, instead of must. There was someone from Sun that required the must to be removed from the rfc IIRC.
Re: [VOTE] Donate blueprint to Aries podling (2nd try)
+1 Lin On Fri, Sep 25, 2009 at 3:39 AM, Guillaume Nodet gno...@gmail.com wrote: The Aries podling has just been accepted (see http://incubator.apache.org/aries/) and would be a much better place for the blueprint implementation that has been developped in Geronimo. This vote is mainly for donating the code to the Aries project and maintain it there. [ ] +1 Donate the blueprint implementation to Aries [ ] -1 Do not The vote will be opened for 72 hours. Here's my +1 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Donate Blueprint implementation to Aries podling
+1 Lin On Wed, Sep 23, 2009 at 11:20 AM, Guillaume Nodet gno...@gmail.com wrote: Some time ago, a few Geronimo committers have started an implementation of the OSGi Blueprint Services spec, which is basically an OSGi standardized version of Spring-DM (the next version of Spring-DM being the RI of this spec). The code was developed at Geronimo mostly because the people that were interested in doing so were all Geronimo committers, so it was way easier to set that up inside Geronimo. However, the piece of code does not really fit well in Geronimo, as it has nothing to do with JEE. A few days ago, a podling named Aries has been proposed to the incubator. You'll find the proposal at http://wiki.apache.org/incubator/AriesProposal. Aries would be a much more natural home for the blueprint code currently in Geronimo. Thoughts / questions / remarks ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Resolved: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4683. --- Resolution: Fixed Transaction.commit method signature isn't entirely correctly Key: GERONIMO-4683 URL: https://issues.apache.org/jira/browse/GERONIMO-4683 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun I found out the Transaction.commit method signature isn't entirely correct. Per JTA 1.1 for the Transaction interface: commit public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, IllegalStateException, SecurityException, SystemException geronimo-jta_1.1_spec has: void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4683. - Transaction.commit method signature isn't entirely correctly Key: GERONIMO-4683 URL: https://issues.apache.org/jira/browse/GERONIMO-4683 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun I found out the Transaction.commit method signature isn't entirely correct. Per JTA 1.1 for the Transaction interface: commit public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, IllegalStateException, SecurityException, SystemException geronimo-jta_1.1_spec has: void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [discuss] update Transaction.commit method signature in jta spec jar
Thanks. If there is no objection by end of Sunday, I'll start this work earlier next week. Lin On Fri, Sep 18, 2009 at 12:42 AM, Jack Cai greensi...@gmail.com wrote: Agreed, since it won't hurt. -Jack On Fri, Sep 18, 2009 at 4:13 AM, Lin Sun linsun@gmail.com wrote: Hi, Recently, I opened GERONIMO-4683 in G about the Transaction.commit signature is missing the IllegalStateException. The reason why I raised this JIRA is because in OSGi RFC 98 (Transaction in OSGi) compliance test, we use Geronimo's JTA spec jar as the baseline. During OSGi RFC 98 compliance test run with an implementation of RFC 98, OSGi signature test currently checks strictly on exceptions throw by each of the method to see if it is the same as the baseline's signature, which is the Geronimo JTA spec jar. If it is not the same the test fail. For example, below is what is specified by the JTA java doc and G JTA spec. G JTA spec jar - Transaction.java public void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; JTA 1.1 Java doc - Transaction.java public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, SecurityException, IllegalStateException, SystemException What do you think of adding the missing unchecked exception IllegalStateException back to our JTA spec and release a newer version of the JTA spec jar just to be the same as what is in the Java doc? I think it is good for us to be consistent with what is in the JTA spec and we should be consistent in declaring the unchecked exceptions (we currently declares the SecurityException but not the IllegalStateException). p.s. if you are interested and have access to, the related discussion is OSGi alliance can be found here - https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1447 Thanks Lin
[discuss] update Transaction.commit method signature in jta spec jar
Hi, Recently, I opened GERONIMO-4683 in G about the Transaction.commit signature is missing the IllegalStateException. The reason why I raised this JIRA is because in OSGi RFC 98 (Transaction in OSGi) compliance test, we use Geronimo's JTA spec jar as the baseline. During OSGi RFC 98 compliance test run with an implementation of RFC 98, OSGi signature test currently checks strictly on exceptions throw by each of the method to see if it is the same as the baseline's signature, which is the Geronimo JTA spec jar. If it is not the same the test fail. For example, below is what is specified by the JTA java doc and G JTA spec. G JTA spec jar - Transaction.java public void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; JTA 1.1 Java doc - Transaction.java public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, SecurityException, IllegalStateException, SystemException What do you think of adding the missing unchecked exception IllegalStateException back to our JTA spec and release a newer version of the JTA spec jar just to be the same as what is in the Java doc? I think it is good for us to be consistent with what is in the JTA spec and we should be consistent in declaring the unchecked exceptions (we currently declares the SecurityException but not the IllegalStateException). p.s. if you are interested and have access to, the related discussion is OSGi alliance can be found here - https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1447 Thanks Lin
[jira] Closed: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4683. - Resolution: Invalid Assignee: Lin Sun Transaction.commit method signature isn't entirely correctly Key: GERONIMO-4683 URL: https://issues.apache.org/jira/browse/GERONIMO-4683 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun I found out the Transaction.commit method signature isn't entirely correct. Per JTA 1.1 for the Transaction interface: commit public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, IllegalStateException, SecurityException, SystemException geronimo-jta_1.1_spec has: void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reopened GERONIMO-4683: --- I just realized that the SecurityException is also unchecked exception. So we are listing one but not the other. Seems we should be consistent here. Transaction.commit method signature isn't entirely correctly Key: GERONIMO-4683 URL: https://issues.apache.org/jira/browse/GERONIMO-4683 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun I found out the Transaction.commit method signature isn't entirely correct. Per JTA 1.1 for the Transaction interface: commit public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, IllegalStateException, SecurityException, SystemException geronimo-jta_1.1_spec has: void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Welcome Shawn Lin Quan Jian as a new committer
Congrats! Lin On Mon, Aug 31, 2009 at 6:48 PM, David Jencksdavid_jen...@yahoo.com wrote: I would like to welcome Shawn, as he recently accepted the Geronimo PMC invitation to become a committer. His account (genspring) has been created so we may be seeing some commits from him soon. Congratulations! david jencks
Re: Welcome Rex Lei Wang as a new committer
Congrats! Lin On Mon, Aug 31, 2009 at 6:48 PM, David Jencksdavid_jen...@yahoo.com wrote: I would like to welcome Rex, as he recently accepted the Geronimo PMC invitation to become a committer. We are still waiting for his account to be created, but hope to get that straightened out shortly and start seeing commits. Congratulations! david jencks
Re: Welcome Ivan Xu as a new PMC member
Congrats! Lin On Mon, Aug 31, 2009 at 6:48 PM, David Jencksdavid_jen...@yahoo.com wrote: I would like to welcome Ivan as he recently accepted the Geronimo PMC invitation to join the PMC. We look forward to working with him to maintain oversight of the Geronimo project. Welcome! david jencks
[jira] Commented: (GERONIMO-4711) Geronimo Blueprint throws org.osgi.service.blueprint.container.ComponentDefinitionException: Cound not create component instance
[ https://issues.apache.org/jira/browse/GERONIMO-4711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724211#action_12724211 ] Lin Sun commented on GERONIMO-4711: --- Where is the component definition for this gshell-160? I don't see it in the blueprint.xml file of the attached archive. Geronimo Blueprint throws org.osgi.service.blueprint.container.ComponentDefinitionException: Cound not create component instance Key: GERONIMO-4711 URL: https://issues.apache.org/jira/browse/GERONIMO-4711 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Environment: Ubuntu 9.04, Sun JDK 6u10, Felix 1.8.0, Karaf SNAPSHOT, Blueprint SNAPSHOT Reporter: Hendy Irawan Attachments: caterpillar-blueprint-bug-sampler.tar.bz2, caterpillar-blueprint-stacktrace.txt Component should be Geronimo Blueprint, but I can't find it in the list. Relevant context of my Blueprint XML is as below. Do I write the XML correctly? ?xml version=1.0 encoding=UTF-8? blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; command-bundle xmlns=http://felix.apache.org/karaf/xmlns/gshell/v1.0.0; command name=ou/show action factory-bean=qi4jApp factory-method=createShowState property name=bundleContext ref=blueprintBundleContext/ property name=project ref=theProject / /action /command /command-bundle bean id=qi4jApp class=com.openubiquity.caterpillar.Qi4jApp /bean bean id=theProject class=com.openubiquity.caterpillar.SpringProject property name=name value=Caterpillar / property name=contextFiles list valuebundle-context-osgi.xml/value valuebundle-context.xml/value /list /property /bean /blueprint BTW, what is the URL of Blueprint XSD ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jta spec bundle issue in felix
Also, would it be possible to get it working by specify a version range, like: Import-Package:javax.transaction;version=”[1.1,1.2)” Lin On Wed, Jun 10, 2009 at 4:06 PM, Lin Sunlinsun@gmail.com wrote: Interesting prob... I wonder if you add the split-package (see http://www.aqute.biz/Code/Bnd) when you export the jta packages would solve the prob for you. This is what I have been using but I only tried Equinox so far. Export-Package = \ javax.transaction;version=1.1;-split-package:=first, \ javax.transaction.xa;version=1.1;-split-package:=first Lin On Wed, Jun 10, 2009 at 1:58 PM, Jarek Gaworjga...@gmail.com wrote: Hey all, I'm experimenting with JPA (OpenJPA specifically) in osgi environment and I ran into an interesting issue with the transaction API. The root of the problem is that the JDK provides a *subset* of the javax.transaction classes that the JTA specification defines. And that creates problems (i.e. java.lang.NoClassDefFoundError) at runtime depending on which bundle is used to wire in the transaction packages. The JVM transaction packages are exported via the system bundle (just like any other JVM package). On Felix, the JVM packages are exported with the version of the JVM you are running on (e.g. if you are running Java 5, the version attribute is set to 1.5.0). Our JTA spec bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API with version 1.1.0. Now, openjpa has the following javax.transaction imports: javax.transaction;version=1.1, javax.transaction.xa;version=1.1. On Felix, the container wires these imports using the system bundle since the system bundle exports these packages with higher version then the JTA bundle and that creates the NoClassDefFoundError problems. So, one would think that updating the version in our JTA spec bundle to something higher then 1.5 or 1.6 should work. And I think that should work but it doesn't seem to be working right on Felix. I don't know if this is a bug or if I'm just missing something or doing things wrong. When I install the openjpa bundle for the first time, its transaction imports get wired to our JTA bundle. But once I restart Felix, the openjpa transaction imports are wired to the system bundle maybe somebody knows what's going on here? Interestingly enough, Equinox exposes the JVM packages with version 0.0.0 and so I don't run into these NoClassDefFoundError errors there. One thing that worked for me reliably is when I updated the JTA spec bundle to be a fragment bundle (attaching itself to the system bundle). That way, the missing transaction classes can be loaded through the system bundle classloader. So, I'm wondering if we should turn the JTA spec bundle into a fragment bundle (just manifest updates) to deal with this problem? Jarek
[jira] Created: (GERONIMO-4683) Transaction.commit method signature isn't entirely correctly
Transaction.commit method signature isn't entirely correctly Key: GERONIMO-4683 URL: https://issues.apache.org/jira/browse/GERONIMO-4683 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Affects Versions: 2.1.4 Reporter: Lin Sun I found out the Transaction.commit method signature isn't entirely correct. Per JTA 1.1 for the Transaction interface: commit public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, IllegalStateException, SecurityException, SystemException geronimo-jta_1.1_spec has: void commit() throws HeuristicMixedException, HeuristicRollbackException, RollbackException, SecurityException, SystemException; which is missing the IllegalStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jta spec bundle issue in felix
Interesting prob... I wonder if you add the split-package (see http://www.aqute.biz/Code/Bnd) when you export the jta packages would solve the prob for you. This is what I have been using but I only tried Equinox so far. Export-Package = \ javax.transaction;version=1.1;-split-package:=first, \ javax.transaction.xa;version=1.1;-split-package:=first Lin On Wed, Jun 10, 2009 at 1:58 PM, Jarek Gaworjga...@gmail.com wrote: Hey all, I'm experimenting with JPA (OpenJPA specifically) in osgi environment and I ran into an interesting issue with the transaction API. The root of the problem is that the JDK provides a *subset* of the javax.transaction classes that the JTA specification defines. And that creates problems (i.e. java.lang.NoClassDefFoundError) at runtime depending on which bundle is used to wire in the transaction packages. The JVM transaction packages are exported via the system bundle (just like any other JVM package). On Felix, the JVM packages are exported with the version of the JVM you are running on (e.g. if you are running Java 5, the version attribute is set to 1.5.0). Our JTA spec bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API with version 1.1.0. Now, openjpa has the following javax.transaction imports: javax.transaction;version=1.1, javax.transaction.xa;version=1.1. On Felix, the container wires these imports using the system bundle since the system bundle exports these packages with higher version then the JTA bundle and that creates the NoClassDefFoundError problems. So, one would think that updating the version in our JTA spec bundle to something higher then 1.5 or 1.6 should work. And I think that should work but it doesn't seem to be working right on Felix. I don't know if this is a bug or if I'm just missing something or doing things wrong. When I install the openjpa bundle for the first time, its transaction imports get wired to our JTA bundle. But once I restart Felix, the openjpa transaction imports are wired to the system bundle maybe somebody knows what's going on here? Interestingly enough, Equinox exposes the JVM packages with version 0.0.0 and so I don't run into these NoClassDefFoundError errors there. One thing that worked for me reliably is when I updated the JTA spec bundle to be a fragment bundle (attaching itself to the system bundle). That way, the missing transaction classes can be loaded through the system bundle classloader. So, I'm wondering if we should turn the JTA spec bundle into a fragment bundle (just manifest updates) to deal with this problem? Jarek
Re: unable to start the blueprint sample bundle
I believe this is caused by the fact that config admin service is not
active yet when I attempted to start the bundleprint sample. After I
made sure config admin is active, this error doesn't appear.
Lin
On Wed, Jun 3, 2009 at 10:41 AM, Lin Sunlinsun@gmail.com wrote:
Hi,
I followed the instruction in the blueprint README and everything went
well till step 5a - start bundle id for blueprint-sample
- start 9
Bundle start
[org.apache.geronimo.blueprint.container.BlueprintExtender] : Scanning
bundle blueprint-sample for blueprint application
[org.apache.geronimo.blueprint.container.BlueprintExtender] : Found
blueprint application in bundle blueprint-sample with urls:
[bundle://9.0:0/OSGI-INF/blueprint/config.xml]
- [org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
Unknown
[org.apache.geronimo.blueprint.container.BlueprintEventDispatcher] :
Sending blueprint container event BlueprintEvent[type=CREATING] for
bundle blueprint-sample
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
WaitForNamespaceHandlers
[org.apache.geronimo.blueprint.ext.ExtNamespaceHandler] : Parsing
element
{http://geronimo.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0}property-placeholder
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Parsing element
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-service-factory
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Parsing element
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}property-placeholder
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Decorating node
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-properties
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Decorating node
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-properties
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Decorating node
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-properties
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
Populated
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Tracking service references: [#recipe-81, ref, ref-list,
blueprint.configadmin, ref2]
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
WaitForInitialReferences
[org.apache.geronimo.blueprint.container.BlueprintEventDispatcher] :
Sending blueprint container event BlueprintEvent[type=GRACE_PERIOD,
dependencies=[((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin))]] for bundle
blueprint-sample
- [org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Unable to start blueprint container for bundle blueprint-sample
java.util.concurrent.TimeoutException
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:247)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:613)
[org.apache.geronimo.blueprint.container.BlueprintEventDispatcher] :
Sending blueprint container event BlueprintEvent[type=FAILURE,
dependencies=[((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.apache.geronimo.blueprint.sample.InterfaceA)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.apache.geronimo.blueprint.sample.Foo)),
((objectClass=org.apache.geronimo.blueprint.sample.InterfaceA)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.apache.geronimo.blueprint.sample.InterfaceA))],
exception=null] for bundle blueprint-sample
The bundle state is Populated which seemed to cause the
unable to start the blueprint sample bundle
Hi,
I followed the instruction in the blueprint README and everything went
well till step 5a - start bundle id for blueprint-sample
- start 9
Bundle start
[org.apache.geronimo.blueprint.container.BlueprintExtender] : Scanning
bundle blueprint-sample for blueprint application
[org.apache.geronimo.blueprint.container.BlueprintExtender] : Found
blueprint application in bundle blueprint-sample with urls:
[bundle://9.0:0/OSGI-INF/blueprint/config.xml]
- [org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
Unknown
[org.apache.geronimo.blueprint.container.BlueprintEventDispatcher] :
Sending blueprint container event BlueprintEvent[type=CREATING] for
bundle blueprint-sample
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
WaitForNamespaceHandlers
[org.apache.geronimo.blueprint.ext.ExtNamespaceHandler] : Parsing
element
{http://geronimo.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0}property-placeholder
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Parsing element
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-service-factory
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Parsing element
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}property-placeholder
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Decorating node
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-properties
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Decorating node
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-properties
[org.apache.geronimo.blueprint.compendium.cm.CmNamespaceHandler] :
Decorating node
{http://www.osgi.org/xmlns/blueprint-cm/v1.0.0}managed-properties
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
Populated
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Tracking service references: [#recipe-81, ref, ref-list,
blueprint.configadmin, ref2]
[org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Running blueprint container for bundle blueprint-sample in state
WaitForInitialReferences
[org.apache.geronimo.blueprint.container.BlueprintEventDispatcher] :
Sending blueprint container event BlueprintEvent[type=GRACE_PERIOD,
dependencies=[((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin))]] for bundle
blueprint-sample
- [org.apache.geronimo.blueprint.container.BlueprintContainerImpl] :
Unable to start blueprint container for bundle blueprint-sample
java.util.concurrent.TimeoutException
at
org.apache.geronimo.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:247)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:613)
[org.apache.geronimo.blueprint.container.BlueprintEventDispatcher] :
Sending blueprint container event BlueprintEvent[type=FAILURE,
dependencies=[((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.apache.geronimo.blueprint.sample.InterfaceA)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.apache.geronimo.blueprint.sample.Foo)),
((objectClass=org.apache.geronimo.blueprint.sample.InterfaceA)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.osgi.service.cm.ConfigurationAdmin)),
((objectClass=org.apache.geronimo.blueprint.sample.InterfaceA))],
exception=null] for bundle blueprint-sample
The bundle state is Populated which seemed to cause the exception. Any ideas?
Thanks
Lin
Re: Possible for G to directly consume a Tomcat server config w/o changes?
One example that we did this is with the config-substitution property file where we allow users to specify configuration and the server reads the config-substitution property file during the startup of the server. If we more or less freeze the configuration, wouldn't this (reading data from server.xml and build the tomcat plugin) have to be done at the build time when we build the geronimo plugin for tomcat using maven2?I think the user would want to do this at runtime where the geronimo server is already prebuilt. On Wed, May 20, 2009 at 3:16 AM, David Jencks david_jen...@yahoo.com wrote: I'm not sure about this idea. It seems really contrary to how most of geronimo works where we take some kind of plan and more or less freeze the configuration while pre-deploying it into a pretty much immutable plugin. I'm not convinced that accepting a new kind of plan for a few gbeans requires adding this continual redeploy functionality to geronimo. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. config.xml doesn't have to contain any info on the tomcat server except that it ought to be started, i.e. listing the plugin. The gbean configurations are all serialized in the plugin. I'd generally prefer it if we dropped the ability to add gbeans to a plugin via config.xml. Again, this may be something that I don't understand well. If we don't configure it in config.xml, how do we allow users to drop in their tomcat server.xml without rebuilding the tomcat plugin? AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Adding this new namespace driven builder is entirely new functionality so there is not really any chance of regressions unless we decide to deploy the standard tomcat server this way, which is certainly not necessary to adding the feature. So, to me the only problems are actually writing the deployer and making sure it at least sort of works. To me, anything that has been changed needs to be tested somehow :) Regarding writing the deployer, I assume you meant the ability for G to deploy tomcat ready web archives. I think this can involve a large number of work, basically, we have to be able to generate geronimo-web.xml for the user's web archives, and deploy the web archive using the generated geronimo-web.xml file. Lin
Re: Possible for G to directly consume a Tomcat server config w/o changes?
One quick way would be allow users to start a tomcat server from a geronimo tomcat javaee5 assembly or little G tomcat assembly(say geronimo.sh start tomcatOnly=true). It is possible to just launch the tomcat server, and read the configuration files (conf/server.xml, etc) and start a tomcat server from a geronimo tomcat assembly, by using the Catalina.java provided by tomcat. But this server/app would have no relationship with geronimo, other than using the jars provided by the geronimo tomcat assembly. The deployed app would be tracked only by tomcat, and not by geronimo. We should be able to achieve this without adding any new jars. If we need more than that, I can for seen the following issues that need investigation - 1. We'll have to provide better server integration with tomcat and be able to read the server configuration from tomcat's server configuration files, along with using config.xml configurations. 2. We'll have to migrate user's app automatically for the user, when the user's app is a bit complicated that contains any need to require a geronimo-web.xml Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Re: Possible for G to directly consume a Tomcat server config w/o changes?
I am not a tomcat expert either... :-) I think we could also try the following approach: 1. figure out how to read tomcat server.xml like you described. Tomcat is using 2. at the G server startup, transform data in tomcat server.xml into G config.xml, if there is change to server.xml since last time server started. I think coming up for the mapping could be hard as configuring some features like valve or cluster requires documentation, time and experience. Also, there could be some functions/configurations in server.xml that we don't support in G yet. 3. During G startup, G can just build the embedded tomcat server by reading data from config.xml, like what it is doing today. AFAIK, server.xml doesn't contain any app info. I agree that this is a very big change and requires a lot of testing to make sure things are not regressed. Lin On Tue, May 19, 2009 at 6:09 PM, David Jencks david_jen...@yahoo.com wrote: I'm not enough of a tomcat expert to know exactly what information a server.xml contains so I'm not quite sure how much the following makes sense. I think I would approach this by building a namespace aware builder that can interpret documents following the server.xml schema and construct the entire tomcat server from it. In other words, instead of starting with our current tomcat6 plugin, the builder would construct a replacement for it from the server.xml. If server.xml contains info on apps that are deployed in the tomcat instance, this could perhaps hook into or extend the current TomcatModuleBuilder to also set up plugins for each web app involved. The first part here might not be too hard. IMO if we treat the server.xml as a geronimo plan that would be acceptable. I'd recommend trying jaxb rather than using xmlbeans. I don't know how practical this would turn out to be but it's worth starting with. I personally think this is too large an addition to plan to get into 2.2. However if a motivated person shows up with something working before we solve the other problems I think we could consider it. 2.2 is already so much later than we had planned I don't want to hold it up for any new features after the other problems have been solved. thanks david jencks Lin On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard wgstodd...@gmail.com wrote: I know G can't consume tomcat configs today, but is this a feature that could be developed for G 2.2? Say I have an application successfully deployed and running under Tomcat.. wouldn't it be nice if I were able to drop the tomcat server config into a Geronimo-Tomcat assembly, start the server, deploy the app and be up and running in seconds. I'm talking about a seamless, zero effort/zero touch migration from Tomcat to a Geronimo-Tomcat assembly. Is it possible? If not, what simplifying assumptions could be made to 'mostly' achieve a zero-touch migration? What are the primary challenges with consuming a tomcat config unchanged with a G-Tomcat assembly? Same Q's apply for Jetty... what's 'doable' with-in reason? Thanks, Bill
Transaction in OSGi (RFC 98) RI
Hi, In case you don't know, the OSGi Alliance has chosen to use the Geronimo txmanager to build the Reference Implementation of Transaction in OSGi (RFC 98). If you are interested in RFC 98, there is an early draft specification avail off the OSGi Alliance home page (go to http://www.osgi.org/Main/HomePage and search for Other 4.2 Early Draft Specifications). Thanks Lin
Re: Whence the geronimo kernel?
to not consider bundling dependency info with the artifact but to have a completely external specification. I don't know about p2 but since jason vanZyl seems to be looking at it I'd guess it is more maven friendly. If you don't bundle (2) with the artifacts then you need some kind of import-package to artifact map or resolution system. We sort of have some vestiges of this today: when you deploy a web app as a geronimo plugin (or export it from a server where it was deployed) it has picked up dependencies on jetty or tomcat based on which deployer you specified in the plugin project pom or which kind of server you deployed on. Another example is that the car-maven-plugin filters the view of the local maven repo so only the versions specified in the pom are visible to the geronimo server we run off the repo -- this allows you to build plugins for a 2.1.3 server even if you have 2.2-SNAPSHOT artifacts locally and some of the dependencies don't specify the version required. I don't know where the best balance for geronimo lies here. I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server. But on the other hand, I'd hate to have not using just Import-package as the starting point. Given how much it is assumed in the OSGi world, it would be best to assume its use and only step outside of that box once we've found the intractable problem that requires it. Starting outside of those limits means we're abandoning the things OSGi does straight off because their may be some places where the exception mechanisms are required. Aren't you exhibiting exactly the same attitude as the blog posters in saying the (2) is not really a problem we need to consider? Whereas all our work in getting geronimo to actually work has been focussed on solving (2). If we ditch our working system for (2) we won't have a server perhaps ever. In terms of assembling a server, without (2) the space of possible bundles to resolve to is the entire maven central repo. ( I anticipate that any working server is going to be able to convert plain jars to bundles on the fly. If not, no one who is not osgi-obsessed will be willing to use it) At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. However until we get something working we won't know much about whether this or any proposal is a good or workable choice. I'm still waiting for news of a working osgi system that is comparable in scale to eclipse that primarily uses import-package. thanks david jencks Rick thanks david jencks On Mar 13, 2009, at 7:10 AM, Lin Sun wrote: I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package lists. What I meant was that the reason why a lot of people are using Require-Bundle like David mentioned in his early notes is probably because it is a lot easier to use. I personally had to spend quite some time to figure out the prob I mentioned earlier - I was developing a bundle that needs to import the javax.transaction package from the transaction in OSGi bundle, but two bundles have it (the basic OSGi J2SE and the transaction in OSGi bundle).I was able to resolve this using Import-Package with the specific version of javax.transaction package that I need. I just tried to switch to use Require-Bundle, that is to have my bundle to depend on the transaction in OSGi bundle as it contains the right version of the javax.transaction package I need, but my bundle is broken completely due to CDNFE. I don't think the Require-Bundle offers the fine grain control that I needed for my bundle and I am sure Geronimo would have a lot more complicated bundles than what I was developing. BTW, there's a good discussion here: http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html - in particular in the first comment from Neil Bartlett and the limitations of Require-Bundle documented in the OSGi v 4.1 core spec (section 3.13.3). Lin On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun linsun@gmail.com wrote: Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
I think I was not too clear below. I didn't mean to say that I am in favor of Require-Bundle because it is a lot harder to come up with the right Import-Package lists. What I meant was that the reason why a lot of people are using Require-Bundle like David mentioned in his early notes is probably because it is a lot easier to use. I personally had to spend quite some time to figure out the prob I mentioned earlier - I was developing a bundle that needs to import the javax.transaction package from the transaction in OSGi bundle, but two bundles have it (the basic OSGi J2SE and the transaction in OSGi bundle).I was able to resolve this using Import-Package with the specific version of javax.transaction package that I need. I just tried to switch to use Require-Bundle, that is to have my bundle to depend on the transaction in OSGi bundle as it contains the right version of the javax.transaction package I need, but my bundle is broken completely due to CDNFE. I don't think the Require-Bundle offers the fine grain control that I needed for my bundle and I am sure Geronimo would have a lot more complicated bundles than what I was developing. BTW, there's a good discussion here: http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html - in particular in the first comment from Neil Bartlett and the limitations of Require-Bundle documented in the OSGi v 4.1 core spec (section 3.13.3). Lin On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun linsun@gmail.com wrote: Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
See comments below. Lin On Thu, Mar 12, 2009 at 1:51 AM, Jarek Gawor jga...@gmail.com wrote: The point I was trying to make is that with Geronimo the classloader hierarchy is pretty much created/setup at build time while in osgi if you are using Import-Package is at runtime. Here's an example. Say, we have configuration A that has dependency on configuration B and C. Both B and C have dependency on commons-logging.jar. In Geronimo it would be very likely that you would run into ClassCastExceptions with such configuration. And the only way to fix it, it would be to create a new configuration D that would have the dependency on commons-logging.jar and B and C configurations would have to be updated to have dependency on D. In osgi world, bundle B and C would define a Import-Package on the commons-logging package and the osgi system at runtime would figure out that B and C must be wired to the same bundle that provides the commons-logging library. So classloader-per-jar is important and so is the runtime dependency resolution to make sure that the same library is not loaded from two different classloaders within the hierarchy. Here is my understanding on this scenario. First, you don't really need to develop a bundle for commons-logging package(s). Bundle B and C can just have the commons-logging packages on their Import-Package attribute, with the specific versions they need, for example: Import-Package = \ org.apache.commons...;version=1.1, \ * When bundle A have Bundle B and C's APIs listed on Bundle A's Import-Package attribute, it won't see the commons-logging package at all. It would only see the package if Bundle B/C exports the commons-logging package on its Export-Package attribute, and Bundle A has commons-logging package explicitly on its Import-Package attribute. random thoughts Hmm... I'm not sure what would happen if B and C used Require-Bundle and specify two different bundle names for libraries that provide the commons-logging library. Would we would see ClassCastExceptions (same as in Geronimo right now) or would osgi just pick one of these bundles as the default? Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
I think this is a valid concern. My understanding is that the OSGi community is working hard on this as they are working on specifications for a Web Container in OSGi with requirements like Java EE compliant web container in OSGi. They are also working on specifications for JNDI in OSGi, transaction in OSGi, JPA in OSGi, etc. Lin Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ...
Re: Whence the geronimo kernel?
I think this is a fair requirement from.I also think the OSGi community is aware of this requirement. For example, the web container in OSGi spec that I am following, it requires the web container in OSGi to support deployment of traditional war file as well as the OSGi bundle war file. Lin On Fri, Mar 6, 2009 at 8:52 AM, Juergen Weber webe...@gmail.com wrote: Therefore the change to OSGI should be transparent to users, I wouldn't want to have to specify OSGI dependencies for JEE applications. If there is OSGI below, fine. If I can use it, fine. But it should not be necessary for standard JEE apps. Thanks, Juergen -- View this message in context: http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Welcome ivan Hai Hong Xu as a new committer
Congrats Ivan!!! Lin On Fri, Mar 6, 2009 at 12:06 PM, Donald Woods dwo...@apache.org wrote: I would like to welcome Ivan aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account was just created this morning (xuhaihong), so you should start seeing some commits from him soon. -Donald
Re: Whence the geronimo kernel?
Hi David, I think this is a good move and worthy investigation! I have some comments below. On Wed, Mar 4, 2009 at 7:56 PM, David Jencks david_jen...@yahoo.com wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. I have used the Import-Package function. The bundle I was trying to build can get javax.transaction pacakge from the J2SE or the geronimo's jta spec jar, so I had to specify the exact version of the javax.transaction package in the Import-Package attribute and let the bnd tool figure out the rest. This works well for me. The bnd tool cannot auto-discover this so this have to be done manually AFAIK. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories Osgi is building a bundle repository RFC (think it is rfc 112). I haven't looked into detail so not sure if it is related to maven at all, but you may want to check it out. at this point I think geronimo would be running on osgi, still using gbeans. Are you envisioning all the geronimo plugins converted to OSGi bundles to run in the OSGi based kernel? - look into relaxing the gbean framework so it is more plugin-at-a-time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean-spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks
Re: Cron jdil...@minotaur /home/jdillon/ws/site/bin/sync
Joe, I am very sure that I did that step, as I still have the terminal window from yesterday pm - Play nice. -- ASF Infrastructure (infrastruct...@apache.org) [lin...@minotaur ~]$ chgrp -R geronimo public_html/staging-site/txmanager [lin...@minotaur ~]$ pwd /home/linsun [lin...@minotaur ~]$ chmod -R g+w public_html/staging-site/txmanager [lin...@minotaur ~]$ ls public_html/staging-site/txmanager 2.1.2 [lin...@minotaur ~]$ cp -r public_html/staging-site/txmanager /www/geronimo.apache.org/maven I also found out that the two directories have different permission after the cp command: drwxrwxr-x public_html/staging-site/txmanager drwxr-xr-x /www/geronimo.apache.org/maven/txmanager Maybe it worked on your machine but I had to have the last step. Lin On Wed, Mar 4, 2009 at 1:46 PM, Joe Bohn joe.b...@earthlink.net wrote: Lin, The new step you added (after the copy) should not be necessary if you had performed the step immediately prior to the copy (chmod -R g+w public_html/staging-site/[siteId]). Are you sure you didn't just skip that step by mistake? Regards, Joe - Show quoted text - Lin Sun wrote: I hope I resolved this.. I also updated the component release wiki page for the step I missed. Thanks. Lin On Wed, Mar 4, 2009 at 9:15 AM, Jason Dillon ja...@planet57.com wrote: Some permission problems... --jason Begin forwarded message: From: jdil...@apache.org (Cron Daemon) Date: March 4, 2009 9:08:11 PM GMT+07:00 To: jdil...@apache.org Subject: Cron jdil...@minotaur /home/jdillon/ws/site/bin/sync chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/logos/maven-feather.png: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/logos: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/external.png: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_error_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_info_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_success_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_warning_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/newwindow.png: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/spacer.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/top_bgstretch_1x64.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/border_bottom.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/topleft_logo_437x64.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/maven-base.css: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/maven-theme.css: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/print.css: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/logos/maven-feather.png: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/logos: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/external.png: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_error_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_info_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_success_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_warning_sml.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/newwindow.png: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/spacer.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/top_bgstretch_1x64.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/border_bottom.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/topleft_logo_437x64.gif: Operation not permitted chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images: Operation not permitted chmod: /www
Re: [VOTE] Release Geronimo txmanager version 2.1.2
The vote passes with 7 +1 votes (all from PMC members) and no others. I'll push the binaries and site out today. Thanks! Lin On Wed, Feb 25, 2009 at 3:47 PM, Lin Sun linsun@gmail.com wrote: Hi, This is a vote for the geronimo txmanager version 2.1.2 release. The following changes are included for the txmanager 2.1.2 release: GERONIMO-4393 - Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy GERONIMO-4438 - TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread GERONIMO-4448 - TransactionManager resume method should only resume valid transaction GERONIMO-4461 - Improve exception during transaction manager one phase commit GERONIMO-4466 - Improve exception during transaction manager commit when there are multiple XAResources GERONIMO-4471 - improve heuristic exception handling in rollback when txmanager.commit is called GERONIMO-4449 - Transaction.rollback method also calls beforeCompletion GERONIMO-4478 - enhance exception handling during transaction rollback GERONIMO-4482 - a few improvements on XAExceptions during enlist resource, prepare, commit, rollback update to use slf4j license/notice update Staging repo: http://people.apache.org/~linsun/staging-repo/txmanager/ Staging site: http://people.apache.org/~linsun/staging-repo/txmanager/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks Lin
[jira] Created: (GERONIMO-4564) update to use transaction manager 2.1.2
update to use transaction manager 2.1.2 --- Key: GERONIMO-4564 URL: https://issues.apache.org/jira/browse/GERONIMO-4564 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Txmanager 2.1.2 is released. Let's update pom.xml to use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4564) update to use transaction manager 2.1.2
[ https://issues.apache.org/jira/browse/GERONIMO-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4564. --- Resolution: Fixed updated trunk and 2.1.4 server to use txmanager 2.1.2 (see subversion commit tab) update to use transaction manager 2.1.2 --- Key: GERONIMO-4564 URL: https://issues.apache.org/jira/browse/GERONIMO-4564 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Txmanager 2.1.2 is released. Let's update pom.xml to use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4564) update to use transaction manager 2.1.2
[ https://issues.apache.org/jira/browse/GERONIMO-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4564. - update to use transaction manager 2.1.2 --- Key: GERONIMO-4564 URL: https://issues.apache.org/jira/browse/GERONIMO-4564 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Txmanager 2.1.2 is released. Let's update pom.xml to use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Geronimo txmanager version 2.1.2
Hi, Many thanks to Joe and Donald for their votes! Anyone else wants to vote but hasn't had the time to do so? Let me know... I can extend the vote till end of Monday. Lin On Wed, Feb 25, 2009 at 3:47 PM, Lin Sun linsun@gmail.com wrote: Hi, This is a vote for the geronimo txmanager version 2.1.2 release. The following changes are included for the txmanager 2.1.2 release: GERONIMO-4393 - Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy GERONIMO-4438 - TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread GERONIMO-4448 - TransactionManager resume method should only resume valid transaction GERONIMO-4461 - Improve exception during transaction manager one phase commit GERONIMO-4466 - Improve exception during transaction manager commit when there are multiple XAResources GERONIMO-4471 - improve heuristic exception handling in rollback when txmanager.commit is called GERONIMO-4449 - Transaction.rollback method also calls beforeCompletion GERONIMO-4478 - enhance exception handling during transaction rollback GERONIMO-4482 - a few improvements on XAExceptions during enlist resource, prepare, commit, rollback update to use slf4j license/notice update Staging repo: http://people.apache.org/~linsun/staging-repo/txmanager/ Staging site: http://people.apache.org/~linsun/staging-repo/txmanager/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks Lin
[VOTE] Release Geronimo txmanager version 2.1.2
Hi, This is a vote for the geronimo txmanager version 2.1.2 release. The following changes are included for the txmanager 2.1.2 release: GERONIMO-4393 - Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy GERONIMO-4438 - TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread GERONIMO-4448 - TransactionManager resume method should only resume valid transaction GERONIMO-4461 - Improve exception during transaction manager one phase commit GERONIMO-4466 - Improve exception during transaction manager commit when there are multiple XAResources GERONIMO-4471 - improve heuristic exception handling in rollback when txmanager.commit is called GERONIMO-4449 - Transaction.rollback method also calls beforeCompletion GERONIMO-4478 - enhance exception handling during transaction rollback GERONIMO-4482 - a few improvements on XAExceptions during enlist resource, prepare, commit, rollback update to use slf4j license/notice update Staging repo: http://people.apache.org/~linsun/staging-repo/txmanager/ Staging site: http://people.apache.org/~linsun/staging-repo/txmanager/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks Lin
Re: [VOTE] Release Geronimo txmanager version 2.1.2
Here is my +1 too Lin On Wed, Feb 25, 2009 at 3:47 PM, Lin Sun linsun@gmail.com wrote: Hi, This is a vote for the geronimo txmanager version 2.1.2 release. The following changes are included for the txmanager 2.1.2 release: GERONIMO-4393 - Duplicate Xid with multiple JVMs on single host - default impl needs some 'random' entropy GERONIMO-4438 - TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread GERONIMO-4448 - TransactionManager resume method should only resume valid transaction GERONIMO-4461 - Improve exception during transaction manager one phase commit GERONIMO-4466 - Improve exception during transaction manager commit when there are multiple XAResources GERONIMO-4471 - improve heuristic exception handling in rollback when txmanager.commit is called GERONIMO-4449 - Transaction.rollback method also calls beforeCompletion GERONIMO-4478 - enhance exception handling during transaction rollback GERONIMO-4482 - a few improvements on XAExceptions during enlist resource, prepare, commit, rollback update to use slf4j license/notice update Staging repo: http://people.apache.org/~linsun/staging-repo/txmanager/ Staging site: http://people.apache.org/~linsun/staging-repo/txmanager/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks Lin
[jira] Resolved: (GERONIMO-4506) switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch
[ https://issues.apache.org/jira/browse/GERONIMO-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4506. --- Resolution: Fixed Fix Version/s: 2.2 resolved - see subversion commit tab switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch Key: GERONIMO-4506 URL: https://issues.apache.org/jira/browse/GERONIMO-4506 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Attachments: G4506.patch This patch prepares the geronimo server 2.1 branch to use the new txmanager 2.1.2-snapshot. With this patch, I am able to build branch 2.1 successfully with all of the testsuites passing. If there is no objection, I'd like to commit this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r740002 - in /geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2: ./ geronimo-connector/pom.xml geronimo-transaction/pom.xml pom.xml
Ok, I thought it would not be long before I can start a vote on this. I'll revert this in case someone else wants to work on the txmanager 2.1.2 branch. Lin On Wed, Feb 4, 2009 at 11:25 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Feb 2, 2009, at 10:25 AM, lin...@apache.org wrote: Author: linsun Date: Mon Feb 2 15:25:54 2009 New Revision: 740002 URL: http://svn.apache.org/viewvc?rev=740002view=rev Log: [maven-release-plugin] copy for tag geronimo-txmanager-parent-2.1.2 Added: geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/ - copied from r739997, geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/ geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/geronimo-connector/pom.xml - copied unchanged from r740001, geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/geronimo-connector/pom.xml geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/geronimo-transaction/pom.xml - copied unchanged from r740001, geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/geronimo-transaction/pom.xml geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.2/pom.xml - copied unchanged from r740001, geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/pom.xml Lin, Unless you're starting up a vote, I wouldn't be creating this tag. If you need to free up trunk for other development, you can create a branches/geronimo-txmanager-2.1.2. --kevan
[jira] Resolved: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
[ https://issues.apache.org/jira/browse/GERONIMO-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4519. --- Resolution: Invalid mark as invalid (see subversion commit tab) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource -- Key: GERONIMO-4519 URL: https://issues.apache.org/jira/browse/GERONIMO-4519 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 as titled, when XAException is XA_RBROLLBACK from XAResource.end, which indicates that XAResource has already rolled back the transaction, there is no need to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4506) switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch
[ https://issues.apache.org/jira/browse/GERONIMO-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4506. - switch to use txmanager 2.1.2-snapshot in geronimo server 2.1 branch Key: GERONIMO-4506 URL: https://issues.apache.org/jira/browse/GERONIMO-4506 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Attachments: G4506.patch This patch prepares the geronimo server 2.1 branch to use the new txmanager 2.1.2-snapshot. With this patch, I am able to build branch 2.1 successfully with all of the testsuites passing. If there is no objection, I'd like to commit this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Time for Geronimo 2.1.4 release?
+1 Thanks for volunteering to be the release manager! Lin On Tue, Feb 3, 2009 at 2:43 PM, Jarek Gawor jga...@gmail.com wrote: Hi, I think it's time for Geronimo 2.1.4 release. We've had a lot of important fixes since 2.1.3 and we should get them out to our users. And if we agree, I would also like to volunteer to be a release manager for this release. Looking at the current status for 2.1.4 there are still a few things that we need to do before we can go ahead with the release. I updated the http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.1.4+Release+Status page with some of these items. If there are any open bugs that _need_ to be fixed for 2.1.4 or if I missed anything in that list please just update that wiki page. Thanks, Jarek
[jira] Commented: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
[ https://issues.apache.org/jira/browse/GERONIMO-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666594#action_12666594 ] Lin Sun commented on GERONIMO-4519: --- I have been reading the XA spec again on this topic today.I have to say the spec is rather confusing. Initially, I interpreted XA_RBROLLBACK as transaction has already been rolled back by the XAResource when the XAResource returns XA_RBROLLBACK as the result of XAResource.end() method. However when I read the spec again today, I think that is not a safe conclusion. Here is what I conclude: If XA_RBROLLBACK arisen from XAResource.end() method, it means The resource manager marked the transaction branch rollback-only for an unspecified reason., per page 80 of XA+ spec, version 2 from the open group. If XA_RBROLLBACK arisen from XAResource.commit() method, it means The resource manager rolled back the transaction branch for an unspecified reason., per page 73 of XA spec. The spec gave the same explanation for XA_RBROLLBACK when arisen from XAResource.rollback() or prepare() method. So when TM calls XAResource.end() method with TMFAIL flag and got a XA_RBROLLBACK exception, I think TM should continue with the rollback method and call the XAResource.rollback() explicitly to ensure the transaction is rolled back.Comments? When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource -- Key: GERONIMO-4519 URL: https://issues.apache.org/jira/browse/GERONIMO-4519 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 as titled, when XAException is XA_RBROLLBACK from XAResource.end, which indicates that XAResource has already rolled back the transaction, there is no need to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource -- Key: GERONIMO-4519 URL: https://issues.apache.org/jira/browse/GERONIMO-4519 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4 as titled, when XAException is XA_RBROLLBACK from XAResource.end, which indicates that XAResource has already rolled back the transaction, there is no need to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
[ https://issues.apache.org/jira/browse/GERONIMO-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4519: -- Affects Version/s: 2.2 Fix Version/s: 2.2 When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource -- Key: GERONIMO-4519 URL: https://issues.apache.org/jira/browse/GERONIMO-4519 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 as titled, when XAException is XA_RBROLLBACK from XAResource.end, which indicates that XAResource has already rolled back the transaction, there is no need to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [discuss] release txmanager 2.1.2
Good point - I agree the vote only passes if it doesn't cause any tck prob. Lin On Fri, Jan 16, 2009 at 9:50 AM, Donald Woods dwo...@apache.org wrote: Would like to see a full run of the TCK to make sure there are no regressions before we release it -Donald Lin Sun wrote: Hi, I 'd like to release txmanager 2.1.2 as I made some changes to it recently. I am going to work on putting a vote out if there is no objection by end of tomorrow. If you are interested in the details of the changes, I think most of them are recorded as JIRAs: GERONIMO-4438 GERONIMO-4448 GERONIMO-4461 GERONIMO-4466 GERONIMO-4471 GERONIMO-4449 GERONIMO-4478 GERONIMO-4482 Thanks Lin
[jira] Updated: (GERONIMO-4448) TransactionManager resume method should only resume valid transaction
[
https://issues.apache.org/jira/browse/GERONIMO-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun updated GERONIMO-4448:
--
Affects Version/s: 2.1.4
Fix Version/s: 2.1.4
TransactionManager resume method should only resume valid transaction
-
Key: GERONIMO-4448
URL: https://issues.apache.org/jira/browse/GERONIMO-4448
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 2.1.4, 2.2
Reporter: Lin Sun
Assignee: Lin Sun
Fix For: 2.1.4, 2.2
Currently, the resume manager resumes pretty much any transaction as long as
the transaction is not null and is an instance of TransactionImpl.
I think this is incorrect. Per the jTA 1.1 spec, page 13:
Suspending and Resuming a Transaction
A call to theTransactionManager.suspend method temporarily suspends the
transaction that is currently associated with the calling thread. If the
thread is not
associated with any transaction, anull object reference is returned;
otherwise, a valid
Transaction object is returned. TheTransactionobject can later be passed to
the
resume method to reinstate the transaction context association with the
calling thread.
TheTransactionManager.resumemethod re-associates the specified transaction
context with the calling thread. If the transaction specified is a valid
transaction, the
transaction context is associated with the calling thread; otherwise, the
thread is
associated with no transaction.
Transaction tobj = TransactionManager.suspend();
..
TransactionManager.resume(tobj);
A simple test below would reveal the prob:
{code}
public void testResume1() throws Exception {
Transaction tx;
assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
tm.begin();
assertEquals(Status.STATUS_ACTIVE, tm.getStatus());
tx = tm.getTransaction();
assertNotNull(tx);
assertEquals(Status.STATUS_ACTIVE, tx.getStatus());
tm.commit();
assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
assertNull(tm.getTransaction());
try {
tm.resume(tx);
fail();
} catch (InvalidTransactionException e) {
// expected
}
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4438) TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread
[ https://issues.apache.org/jira/browse/GERONIMO-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4438: -- Affects Version/s: 2.2 2.1.4 Fix Version/s: 2.1.4 TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread -- Key: GERONIMO-4438 URL: https://issues.apache.org/jira/browse/GERONIMO-4438 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.1.4, 2.2 per JTA 1.1 spec, the TransactionSynchronizationRegistry.getTransactionKey method should return null, if a transaction is not associated with the current thread. The Geronimo transaction impl (v2.1.1) throws an IllegalStateException which is incorrect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4461) Improve exception during transaction manager one phase commit
[ https://issues.apache.org/jira/browse/GERONIMO-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4461: -- Affects Version/s: 2.1.4 Improve exception during transaction manager one phase commit - Key: GERONIMO-4461 URL: https://issues.apache.org/jira/browse/GERONIMO-4461 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Currently, during transaction manager one phase commit, if there is XAException arise from XAResource.commit, the code just throws RollbackException. We should provide a more detailed Exceptions, that is: 1. If the XAException is XAException.XA_HEURRB, we throw HeuristicRollbackException, and call XAResource to forget 2. If the XAException is XAException.XA_HEURMIX, we throw HeuristicMixedException, and call XAResource to forget 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the transaction originator, but we want to call XAResource to forget. 4. Other XAException, throw RollbackException, same as the current code. Thoughts? Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4461) Improve exception during transaction manager one phase commit
[ https://issues.apache.org/jira/browse/GERONIMO-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4461. --- Resolution: Fixed Fix Version/s: 2.1.4 see subversion commits tab Improve exception during transaction manager one phase commit - Key: GERONIMO-4461 URL: https://issues.apache.org/jira/browse/GERONIMO-4461 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Currently, during transaction manager one phase commit, if there is XAException arise from XAResource.commit, the code just throws RollbackException. We should provide a more detailed Exceptions, that is: 1. If the XAException is XAException.XA_HEURRB, we throw HeuristicRollbackException, and call XAResource to forget 2. If the XAException is XAException.XA_HEURMIX, we throw HeuristicMixedException, and call XAResource to forget 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the transaction originator, but we want to call XAResource to forget. 4. Other XAException, throw RollbackException, same as the current code. Thoughts? Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4466) Improve exception during transaction manager commit when there are multiple XAResources
[ https://issues.apache.org/jira/browse/GERONIMO-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4466: -- Affects Version/s: 2.1.4 Fix Version/s: 2.1.4 Improve exception during transaction manager commit when there are multiple XAResources --- Key: GERONIMO-4466 URL: https://issues.apache.org/jira/browse/GERONIMO-4466 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 When tm.commit is invoked and there are multiple XAResources enlisted. if there are one or more XAExceptions arisen from one or more of these XAResources during commit, the code simply throws SystemException. I propose the following updates to provide more detailed exceptions: 1. If the XAException is XAException.XA_HEURRB from one XAResource and there is no other exceptions from other XAResources, we throw HeuristicMixedException (because there are heuristic conditions and some are committed some are rolled back), and call the XAResource to forget. 2. If all XAResources report XAException.XA_HEURRB, we throw HeuristicRollbackException, and call the these XAResources to forget 3. If the XAException is XAException.XA_HEURRB from one or more XAResources however one or more XAResource are able to commit something (either no exception during commit, or throw XAException.XA_HEURMIX /XAException.XA_HEURCOM to indicate something gets committed), we throw HeuristicMixedException, and call the XAResources to forget. 2. If the XAException is XAException.XA_HEURMIX from one XAResource, and no matter what other heuristic exceptions reported by other XAResources, we throw HeuristicMixedException, and call the XAResource to forget 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the transaction originator, but we want to call XAResource to forget. Comments welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4466) Improve exception during transaction manager commit when there are multiple XAResources
[ https://issues.apache.org/jira/browse/GERONIMO-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4466. --- Resolution: Fixed see subversion commits tab Improve exception during transaction manager commit when there are multiple XAResources --- Key: GERONIMO-4466 URL: https://issues.apache.org/jira/browse/GERONIMO-4466 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 When tm.commit is invoked and there are multiple XAResources enlisted. if there are one or more XAExceptions arisen from one or more of these XAResources during commit, the code simply throws SystemException. I propose the following updates to provide more detailed exceptions: 1. If the XAException is XAException.XA_HEURRB from one XAResource and there is no other exceptions from other XAResources, we throw HeuristicMixedException (because there are heuristic conditions and some are committed some are rolled back), and call the XAResource to forget. 2. If all XAResources report XAException.XA_HEURRB, we throw HeuristicRollbackException, and call the these XAResources to forget 3. If the XAException is XAException.XA_HEURRB from one or more XAResources however one or more XAResource are able to commit something (either no exception during commit, or throw XAException.XA_HEURMIX /XAException.XA_HEURCOM to indicate something gets committed), we throw HeuristicMixedException, and call the XAResources to forget. 2. If the XAException is XAException.XA_HEURMIX from one XAResource, and no matter what other heuristic exceptions reported by other XAResources, we throw HeuristicMixedException, and call the XAResource to forget 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the transaction originator, but we want to call XAResource to forget. Comments welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4449) Transaction.rollback method also calls beforeCompletion
[
https://issues.apache.org/jira/browse/GERONIMO-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun updated GERONIMO-4449:
--
Affects Version/s: 2.1.4
Fix Version/s: 2.2
2.1.4
Transaction.rollback method also calls beforeCompletion
---
Key: GERONIMO-4449
URL: https://issues.apache.org/jira/browse/GERONIMO-4449
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 2.1.4, 2.2
Reporter: Lin Sun
Assignee: Lin Sun
Fix For: 2.1.4, 2.2
Per JTA 1.1 spec, page 33:
The beforeCompletion method is called by the transaction manager prior to the
start of the two-phase
transaction commit process.This call is executed with the transaction context
of the transaction that is being
committed. An unchecked exception thrown by a registered Synchronization
object causes the transaction to
be aborted. That is, upon encountering an unchecked exception thrown by a
registered synchronization
object, the transaction manager must mark the transaction for rollback.
The spec seems to indicate that beforeCompletion is not called during
rollback, but afterCompletion is called during(or after) both rollback and
commit.
So I expect the following to pass:
{code}
public void testNormalSynchIsNotCalledOnRollback() throws Exception {
normalSync = new CountingSync();
tm.begin();
tm.getTransaction().registerSynchronization(normalSync);
tm.rollback();
assertFalse(normalSync.beforeCompletionCalled());
assertTrue(normalSync.afterCompletionCalled());
}
{code}
In geronimo, we call beforeCompletion inside of the rollback method in
TransactionImpl.java, which seems incorrect to me.
Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4471) improve heuristic exception handling in rollback when txmanager.commit is called
[ https://issues.apache.org/jira/browse/GERONIMO-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4471. --- Resolution: Fixed see subversion commits tab improve heuristic exception handling in rollback when txmanager.commit is called Key: GERONIMO-4471 URL: https://issues.apache.org/jira/browse/GERONIMO-4471 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Improve heuristic exception handling during rollback, when txmanager.commit is called by providing a rollbackResourcesDuringCommit method to throw appropriate heuristic exceptions. The logic is: 1. If XAException.XA_HEURRB arisen from XAResource rollback, this means transaction has been heuristically rolled back, thus we just throw normal RollbackException. 2. If XAException.XA_HEURMIX arisen from XAResource rollback, this means transaction has been heuristically rolled back and committed, thus we just throw HeuristicMixedException. 3. If XAException.XA_HEURCOM arisen from XAResource rollback, this means transaction has been heuristically committed. In this case, if transaction has ever been committed (via other XAResources enlisted), then we throw HeuristicMixedException. 4. Other XAExceptions, throw SystemExceptions. 5. If no specific XAException or only XAException.XA_HEURRB, throw RollbackException. The rollbackResourcesDuringCommit method will be used during the commit context instead of the current rollbackResources method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4478) enhance exception handling during transaction rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4478. --- Resolution: Fixed Fix Version/s: 2.1.4 see subversion commits. enhance exception handling during transaction rollback -- Key: GERONIMO-4478 URL: https://issues.apache.org/jira/browse/GERONIMO-4478 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Currently, for any XAException arisen, we convert it to SystemException. 1. If the exception is XAException.XA_HEURRB (which means transcation has been heuristically rolled back), we should not throw any exception as the resulting behavior is same as expected behavior. 2. JTA seems to assume that exceptions are not possible to be HEURMIX or HEURCOM or HEURHAZ (JTA doesn't define any heursitic exceptions thrown from the tm.rollback() method) so we'll just convert them to SystemException as it is today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4478) enhance exception handling during transaction rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4478: -- Affects Version/s: 2.1.4 enhance exception handling during transaction rollback -- Key: GERONIMO-4478 URL: https://issues.apache.org/jira/browse/GERONIMO-4478 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Currently, for any XAException arisen, we convert it to SystemException. 1. If the exception is XAException.XA_HEURRB (which means transcation has been heuristically rolled back), we should not throw any exception as the resulting behavior is same as expected behavior. 2. JTA seems to assume that exceptions are not possible to be HEURMIX or HEURCOM or HEURHAZ (JTA doesn't define any heursitic exceptions thrown from the tm.rollback() method) so we'll just convert them to SystemException as it is today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4482) a few improvements on XAExceptions during enlist resource, prepare, commit, rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4482. --- Resolution: Fixed Fix Version/s: 2.1.4 see subversion commits tab a few improvements on XAExceptions during enlist resource, prepare, commit, rollback Key: GERONIMO-4482 URL: https://issues.apache.org/jira/browse/GERONIMO-4482 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 1. during enlist resource, if there is XAException arisen, we should mark status as rollback only because the enlist resource failed. 2. during commit, convert XAER_RMERR, XAER_PROTO XAER_INVAL to system exceptions. 3. if system exceptions arisen during internal prepare, we should roll back the resource(s). 4. during rollback, if XA_RBROLLBACK, XAER_RMERR,XAER_NOTA XAER_RMFAIL arisen, we expect the transaction to be rolled back eventually thus don't throw anything. During commit, we throw rollback exceptions for these. 5. if XAER_NOTA arisen from forget, means the resource already forgot the transaction, thus we don't throw any exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4482) a few improvements on XAExceptions during enlist resource, prepare, commit, rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4482: -- Affects Version/s: 2.1.4 a few improvements on XAExceptions during enlist resource, prepare, commit, rollback Key: GERONIMO-4482 URL: https://issues.apache.org/jira/browse/GERONIMO-4482 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 1. during enlist resource, if there is XAException arisen, we should mark status as rollback only because the enlist resource failed. 2. during commit, convert XAER_RMERR, XAER_PROTO XAER_INVAL to system exceptions. 3. if system exceptions arisen during internal prepare, we should roll back the resource(s). 4. during rollback, if XA_RBROLLBACK, XAER_RMERR,XAER_NOTA XAER_RMFAIL arisen, we expect the transaction to be rolled back eventually thus don't throw anything. During commit, we throw rollback exceptions for these. 5. if XAER_NOTA arisen from forget, means the resource already forgot the transaction, thus we don't throw any exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4471) improve heuristic exception handling in rollback when txmanager.commit is called
[ https://issues.apache.org/jira/browse/GERONIMO-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4471: -- Affects Version/s: 2.1.4 Fix Version/s: 2.1.4 improve heuristic exception handling in rollback when txmanager.commit is called Key: GERONIMO-4471 URL: https://issues.apache.org/jira/browse/GERONIMO-4471 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.1.4, 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4, 2.2 Improve heuristic exception handling during rollback, when txmanager.commit is called by providing a rollbackResourcesDuringCommit method to throw appropriate heuristic exceptions. The logic is: 1. If XAException.XA_HEURRB arisen from XAResource rollback, this means transaction has been heuristically rolled back, thus we just throw normal RollbackException. 2. If XAException.XA_HEURMIX arisen from XAResource rollback, this means transaction has been heuristically rolled back and committed, thus we just throw HeuristicMixedException. 3. If XAException.XA_HEURCOM arisen from XAResource rollback, this means transaction has been heuristically committed. In this case, if transaction has ever been committed (via other XAResources enlisted), then we throw HeuristicMixedException. 4. Other XAExceptions, throw SystemExceptions. 5. If no specific XAException or only XAException.XA_HEURRB, throw RollbackException. The rollbackResourcesDuringCommit method will be used during the commit context instead of the current rollbackResources method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[discuss] release txmanager 2.1.2
Hi, I 'd like to release txmanager 2.1.2 as I made some changes to it recently. I am going to work on putting a vote out if there is no objection by end of tomorrow. If you are interested in the details of the changes, I think most of them are recorded as JIRAs: GERONIMO-4438 GERONIMO-4448 GERONIMO-4461 GERONIMO-4466 GERONIMO-4471 GERONIMO-4449 GERONIMO-4478 GERONIMO-4482 Thanks Lin
Re: svn commit: r733836 - /geronimo/server/trunk/pom.xml
Kevan, Thanks for resolving this. I haven't thought of those SNAPSHOTS were dated, as changes have been there for quite a few days. Lin On Tue, Jan 13, 2009 at 12:31 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Jan 12, 2009, at 9:08 PM, Lin Sun wrote: Donald, I performed a complete build (mvn clean install) last Friday with this change. There were only a few web services test failure but my test server appeared to hang. So I reran these failed web services tests individually and they all passed. I think the geronimo-txmanager/geronimo-connector SNAPSHOTS were dated. I've deployed new SNAPS. Hoping that this fixes the problem... --kevan
Re: svn commit: r733836 - /geronimo/server/trunk/pom.xml
Donald, I performed a complete build (mvn clean install) last Friday with this change. There were only a few web services test failure but my test server appeared to hang. So I reran these failed web services tests individually and they all passed. Lin On Mon, Jan 12, 2009 at 5:25 PM, Donald Woods dwo...@apache.org wrote: Lin, I'm now seeing some testsuite failures in - enterprise-testsuite/jms-tests enterprise-testsuite/jpa-tests enterprise-testsuite/sec-tests after updating to the latest trunk code Did you perform a complete build+testsuite (with a clean repo) with the latest txmanager code? Or is this related to an updated OpenEJB 3.1.1 SNAPSHOT? Sample jms-tests failure - ---Test set: TestSuite ---Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.472 sec FA ILURE!sendRequests(org.apache.geronimo.testsuite.enterprise.jms.MessageSenderTest) Ti me elapsed: 0.773 sec FAILURE! javax.ejb.EJBException: Container has suffered a SystemException at org.apache.openejb.client.EJBObjectHandler._invoke(EJBObjectHandler.j ava:178)at org.apache.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHa ndler.java:117)at org.apache.openejb.client.proxy.Jdk13InvocationHandler.invoke(Jdk13In vocationHandler.java:52) ... Caused by: javax.transaction.SystemException: Error during two phase commit at org.apache.geronimo.transaction.manager.TransactionImpl.commitResources(TransactionImpl.java:812) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:319) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit (TransactionManagerImpl.java:250) at org.apache.openejb.core.transaction.JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:291) ... Caused by: javax.transaction.xa.XAException: Transaction 'XID:1197822575:6f0047544d49440 0:010047544d4944 00' has not been started.at org.apache.activemq.TransactionContext.toXAException(TransactionConte xt.java:619)at org.apache.activemq.TransactionContext.commit(TransactionContext.java :464)at org.apache.activemq.ra.LocalAndXATransaction.commit(LocalAndXATransac tion.java:85)at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.commit (WrapperNamedXAResource.java:47) at org.apache.geronimo.transaction.manager.TransactionImpl.commitResources(TransactionImpl.java:760) ... 20 more -Donald lin...@apache.org wrote: Author: linsun Date: Mon Jan 12 08:39:22 2009 New Revision: 733836 URL: http://svn.apache.org/viewvc?rev=733836view=rev Log: GERONIMO-4506 switch to use txmanager 2.1.2-snapshot in geronimo server trunk Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=733836r1=733835r2=733836view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Mon Jan 12 08:39:22 2009 @@ -96,7 +96,7 @@ !--connectorSuffix-1_6/connectorSuffix-- connectorSpecgeronimo-j2ee-connector_1.5_spec/connectorSpec !--connectorSpecgeronimo-j2ee-connector_1.6_spec/connectorSpec-- -txmanagerVersion2.1.1/txmanagerVersion +txmanagerVersion2.1.2-SNAPSHOT/txmanagerVersion !--txmanagerVersion2.2-SNAPSHOT/txmanagerVersion-- monitoringConsoleVersion2.2-SNAPSHOT/monitoringConsoleVersion
[jira] Commented: (GERONIMO-4486) Custom server assembly portlet doesn't filter specific word
[ https://issues.apache.org/jira/browse/GERONIMO-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662397#action_12662397 ] Lin Sun commented on GERONIMO-4486: --- Hi Janet, thanks for the feedback! Interesting, doesn't work with IE. This may just be a limitation as I don't know if we'll be able fix that in time for 2.2. Regarding the other prob related to Chinese admin console, yes please open a new jira on that. However, I dont have such an env. Maybe you could look into submitting a patch? Thanks Lin Custom server assembly portlet doesn't filter specific word --- Key: GERONIMO-4486 URL: https://issues.apache.org/jira/browse/GERONIMO-4486 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.2 Environment: - IBM SDK 1.6 - Windows XP SP2 English Reporter: Han Hong Fang Assignee: Lin Sun Priority: Critical Fix For: 2.2 In Custom server assebmly portlet, the function Filter by category and name seems stop working when I type console, but it works well on other words like tomcat, dojo, etc. I test in both IE 7 and firefox 3.0.4. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
