Re: [DISCUSS] G 2.0.2 Release plan
On Sep 24, 2007, at 8:52 AM, Anita Kulshreshtha wrote: --- Kevan Miller <[EMAIL PROTECTED]> wrote: On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: I see that Anita has attached some patches for the MEJB problem. We need to get some eyes on these... David J's changes to openejb and geronimo-openejb-builder [1] are required for MEJB to work on trunk. I will commit MEJB stuff after these changes are committed. I opened a new jira 3484 for the specific openejb-deployer to openejb dependency problem and committed my fix in trunk. i expect to commit it in branches/2.0 sometime tuesday. thanks david jencks [1] https://issues.apache.org/jira/browse/GERONIMO-3481 Thanks Anita __ __ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
[jira] Commented: (GERONIMO-3484) openejb-deployer should not require openejb to be running
[ https://issues.apache.org/jira/browse/GERONIMO-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530042 ] David Jencks commented on GERONIMO-3484: geronimo trunk fixed in rev 579069, small openejb trunk change in rev 579046 > openejb-deployer should not require openejb to be running > - > > Key: GERONIMO-3484 > URL: https://issues.apache.org/jira/browse/GERONIMO-3484 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.0.2, 2.1 > > > The fix for this was worked out under GERONIMO-3481 but the title there isn't > clear that this is the cause and there is another proposed change there that > should not be mixed up with this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3484) openejb-deployer should not require openejb to be running
openejb-deployer should not require openejb to be running - Key: GERONIMO-3484 URL: https://issues.apache.org/jira/browse/GERONIMO-3484 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.2, 2.1 The fix for this was worked out under GERONIMO-3481 but the title there isn't clear that this is the cause and there is another proposed change there that should not be mixed up with this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-221) J2G: Update groupId to be a subproject under devtools
J2G: Update groupId to be a subproject under devtools -- Key: GERONIMODEVTOOLS-221 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-221 Project: Geronimo-Devtools Issue Type: Bug Components: J2G Affects Versions: 1.0.0 Reporter: Donald Woods Fix For: 1.0.0 Need to change the groupId in all of the pom.xml files from org.apache.geronimo.tools to the expected org.apache.geronimo.devtools.j2g -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-218) Update J2G to use the released Eclipse v3.3 release
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMODEVTOOLS-218. - Resolution: Fixed Committed revision 578938 > Update J2G to use the released Eclipse v3.3 release > --- > > Key: GERONIMODEVTOOLS-218 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-218 > Project: Geronimo-Devtools > Issue Type: Bug > Components: J2G >Affects Versions: 1.0.0 >Reporter: Donald Woods >Assignee: Donald Woods > Fix For: 1.0.0 > > > Need to upgrade the J2G build to use Eclipse 3.3 instead of 3.3RC2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-218) Update J2G to use the released Eclipse v3.3 release
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMODEVTOOLS-218: - Assignee: Donald Woods > Update J2G to use the released Eclipse v3.3 release > --- > > Key: GERONIMODEVTOOLS-218 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-218 > Project: Geronimo-Devtools > Issue Type: Bug > Components: J2G >Affects Versions: 1.0.0 >Reporter: Donald Woods >Assignee: Donald Woods > Fix For: 1.0.0 > > > Need to upgrade the J2G build to use Eclipse 3.3 instead of 3.3RC2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1080) JDBC binding component (provider and consumer) added
JDBC binding component (provider and consumer) added Key: SM-1080 URL: https://issues.apache.org/activemq/browse/SM-1080 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.2 Reporter: Przemyslaw Budzik Priority: Minor Attachments: servicemix-jdbc.patch This is a foundation for DB related BC. At the moment it has two very simple endpoints: 1) provider - that can put inserts to database 2) consumer - that can query db with given interval and send marshaled rows to bus. It can work in queue-like manner (record is deleted after consuming) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MEJB Question
On Sep 20, 2007, at 8:56 AM, Anita Kulshreshtha wrote: I am leaning towards deploying MEJB as an EJBModule. To auto deploy this I will be adding an mejb config. Are there any objections? no :-) I've been wondering if we should try to separate mejb security from other security somehow and thought perhaps we should use a GeronimoGroupPrincipal named mejb or mejb-admin. I think this would make it easier to e.g. give someone access to the web console but not the mejb or vice-versa. If we wanted to be even fancier we could try mejb-read and mejb-write. Would this improve modularity or just create more difficult configuration? thanks david jencks Thanks Anita --- Anita Kulshreshtha <[EMAIL PROTECTED]> wrote: Is there a reason for not deploying MEJB as an application and hard coding it in g-openejb? Thanks Anita __ __ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 __ __ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
[jira] Closed: (GERONIMO-3423) Ensure that users can change the ejb jndi name format
[ https://issues.apache.org/jira/browse/GERONIMO-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins closed GERONIMO-3423. --- Resolution: Fixed > Ensure that users can change the ejb jndi name format > - > > Key: GERONIMO-3423 > URL: https://issues.apache.org/jira/browse/GERONIMO-3423 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.0, 2.0.x >Reporter: David Blevins >Assignee: David Blevins > Fix For: 2.0.x, 2.1 > > > Right now OpenEjbSystemGBean is hard coded to always set a value for > "openejb.jndiname.format". We should check to see if it's set first and if > so, not reset it. We should log a warning message if it's changed that > javaee app client's will not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
LinuxWorld Open Solutions Conference 2007 in Tokyo
All, I'm going to be giving a Geronimo talk at the LinuxWorld Open Solutions Conference, in Tokyo on Thursday of this week. The talk is from 11:00-11:45. Here are the conference details -- http://www.idg.co.jp/expo/lwe/index.html --kevan
Re: Can anyone start servers built from trunk?
I just built from trunk and it started OK (Tomcat dist) Cheers! Hernan David Jencks wrote: I can't and I wonder if I broke something locally or in svn... For me gbean-deployer car gets a NCDFE for an xml stream class. I fixed it locally but would like to know if it works for others as is before making more possibly half-baked changes. thanks david jencks
Should the geronimo-activation module be rolled into the javamail providers?
I ran into a situation where somebody wishing to use the Geronimo javamail implementation also need to extract the geroinimo-activation jar file from the server assembly. This was needed because the various activation datahandlers are not included in the mail uber-jar that gets built. I thought this problem had been fixed when the uber jar had been created, but there were other classes I didn't really know about until this came up. So, currently, to using the Sun javamail implementation requires 2 jar files, mail.jar and activation .jar. To use the Geronimo version with equivalent function, you need the Geronimo activation spec jar, the Geronimo javamail mail jar (which includes the javamail spec and javamail providers), AND the geronimo-activation-1.0 jar, which adds in data source handlers that that Sun includes in their mail.jar. This is a bit awkward, as the spec jars and the provider jars are built outside of Geronimo, while the geronimo-activation module is part of the server build, even though it is code that's completely independent of Geronimo (no dependencies on Geronimo code at all). Based on Sun's precedent, and what we did earlier with the javamail provider code (formerly the geronimo-javamail-transport module), the code in the current geronimo-activation module should be moved to the javamail provider code tree so that all of these classes get bundled in the jar file that makes up the javamail implementation. Are there any objects to doing this? Rick
Can anyone start servers built from trunk?
I can't and I wonder if I broke something locally or in svn... For me gbean-deployer car gets a NCDFE for an xml stream class. I fixed it locally but would like to know if it works for others as is before making more possibly half-baked changes. thanks david jencks
Re: Anyone want to smoke test tranql adapters?
I can help with the oracle adapter since I've got the env. on that. (send me the rar files...) Lin David Jencks wrote: I made one code change and a whole lot of build cleanup in the tranql adapters and I'd like to release them, but I'm not set up to try most of them out at all. Is anyone able to give any of them a try? We have.. generic db2 derby mysql oracle postgres IIUC Matt's going to try to do at least the db2 connectors and maybe mysql. If anyone want to try out one of the others let me know and I'll send them to you (or you can build from trunk, although the sequence of stuff to build may be a bit hard to figure out) thanks david jencks
Anyone want to smoke test tranql adapters?
I made one code change and a whole lot of build cleanup in the tranql adapters and I'd like to release them, but I'm not set up to try most of them out at all. Is anyone able to give any of them a try? We have.. generic db2 derby mysql oracle postgres IIUC Matt's going to try to do at least the db2 connectors and maybe mysql. If anyone want to try out one of the others let me know and I'll send them to you (or you can build from trunk, although the sequence of stuff to build may be a bit hard to figure out) thanks david jencks
[jira] Commented: (GERONIMO-3425) Add deployment plan schemas to geronimo web site
[ https://issues.apache.org/jira/browse/GERONIMO-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529895 ] Hernan Cunico commented on GERONIMO-3425: - Target namespace and actual schema file names are not the same. For example geronimo-web-2.0.xsd -> targetNamespace="http://geronimo.apache.org/xml/ns/j2ee/web-2.0"; Ideas to make them match? Cheers! Hernan > Add deployment plan schemas to geronimo web site > > > Key: GERONIMO-3425 > URL: https://issues.apache.org/jira/browse/GERONIMO-3425 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: website >Reporter: Kevan Miller >Assignee: Hernan Cunico > > I seem to recall this being raised, some time ago. I thought it had been > addressed, but does not seem to be the case. > It's really convenient if the xmlns url would actually contain the schemas > for our deployment plans. That way some ide's (e.g. Eclipse) will > automatically load the schemas. For example > http://geronimo.apache.org/xml/ns/j2ee/application-2.0 should serve the > schema for our application deployment plan. > We should do the same for OpenEJB (e.g. > http://www.openejb.org/xml/ns/openejb-jar-2.1). > An overview of our deployment plan schemas at > http://geronimo.apache.org/xml/ns/ would also be useful. > See http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd and > http://java.sun.com/xml/ns/javaee/ for examples how other organizations have > handled this... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: testsuite cleanup (in trunk)
> deployment-testsuite > o deploy-tests The 1 error in deployment-testsuite/deploy-tests is caused by this JIRA. https://issues.apache.org/jira/browse/GERONIMO-3199 > enterprise-testsuite > o ejbcontainer-tests We had a full good run of ejbcontainer tests when we had Openejb 2.1. We need to do something similar by getting their new 3.0 itests-webapp to deploy on Geronimo. Cheers Prasad On 9/21/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > Some of the tests in testsuite are broken and fail for one reason or > another. I tried to fix as many tests as I could but there is still a > bunch of them that I'm not sure how to fix. It would be great if > people could take a look at the tests that they are familiar with and > try to fix them (or disable/remove them if too outdated or whatever). > > Here's a list of the tests that fail for me: > > web-testsuite > o test-jetty > o test-tomcat > o test-security > > deployment-testsuite > o jca-cms-tests > > enterprise-testsuite > o ejbcontainer-tests > o jms-tests > o sec-tests > > Jarek >
[jira] Resolved: (SM-1078) CXFSE xbean.xml should allow the injection of the spring parent context, just like JSR181
[ https://issues.apache.org/activemq/browse/SM-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved SM-1078. -- Resolution: Duplicate > CXFSE xbean.xml should allow the injection of the spring parent context, just > like JSR181 > - > > Key: SM-1078 > URL: https://issues.apache.org/activemq/browse/SM-1078 > Project: ServiceMix > Issue Type: Improvement > Environment: Windows XP >Reporter: Ryan Moquin >Assignee: Freeman Fang > Fix For: 3.2 > > > It would be nice to be able to inject the ComponentContext into a CXF service > in servicemix like you can with jsr181 services. Without this, it makes it a > lot more difficult to access the bus and use it's services. > So in other words, a CXF version of this: > > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1078) CXFSE xbean.xml should allow the injection of the spring parent context, just like JSR181
[ https://issues.apache.org/activemq/browse/SM-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40171 ] Freeman Fang commented on SM-1078: -- duplicated with SM-1060, will close this one as a duplicated issue. Please refer SM-1060 > CXFSE xbean.xml should allow the injection of the spring parent context, just > like JSR181 > - > > Key: SM-1078 > URL: https://issues.apache.org/activemq/browse/SM-1078 > Project: ServiceMix > Issue Type: Improvement > Environment: Windows XP >Reporter: Ryan Moquin >Assignee: Freeman Fang > Fix For: 3.2 > > > It would be nice to be able to inject the ComponentContext into a CXF service > in servicemix like you can with jsr181 services. Without this, it makes it a > lot more difficult to access the bus and use it's services. > So in other words, a CXF version of this: > > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SM-1077) CXFSE should allow a proxy to another CXFSE service like jsr181 does.
[ https://issues.apache.org/activemq/browse/SM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned SM-1077: Assignee: Freeman Fang > CXFSE should allow a proxy to another CXFSE service like jsr181 does. > - > > Key: SM-1077 > URL: https://issues.apache.org/activemq/browse/SM-1077 > Project: ServiceMix > Issue Type: Improvement > Environment: Windows XP >Reporter: Ryan Moquin >Assignee: Freeman Fang > Fix For: 3.2 > > > With the JSR181 services with XFire, I was able to do this, per the > documentation: > > > > > type="test.Echo" /> > > > > > In order to create a proxy to another JSR181 service on the bus. I'm > currently not able to do this now that I'm using CXF. This means I have to > use spring to populate an instance of my service class on the service that I > want to access it. This leads to confusion since there is now the instance > of the target service that my service holds a reference to, and then there is > an instance of that target service that servicemix creates itself. It would > be nice to be able to have a service reference the actual endpoint on the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SM-1078) CXFSE xbean.xml should allow the injection of the spring parent context, just like JSR181
[ https://issues.apache.org/activemq/browse/SM-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned SM-1078: Assignee: Freeman Fang > CXFSE xbean.xml should allow the injection of the spring parent context, just > like JSR181 > - > > Key: SM-1078 > URL: https://issues.apache.org/activemq/browse/SM-1078 > Project: ServiceMix > Issue Type: Improvement > Environment: Windows XP >Reporter: Ryan Moquin >Assignee: Freeman Fang > Fix For: 3.2 > > > It would be nice to be able to inject the ComponentContext into a CXF service > in servicemix like you can with jsr181 services. Without this, it makes it a > lot more difficult to access the bus and use it's services. > So in other words, a CXF version of this: > > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3208) In-place deployment fails when renaming file
[
https://issues.apache.org/jira/browse/GERONIMO-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated GERONIMO-3208:
---
Fix Version/s: (was: 2.0.x)
2.0.2
Update fixed release to 2.0.2 so we can correctly list the changes in 2.0.2
> In-place deployment fails when renaming file
>
>
> Key: GERONIMO-3208
> URL: https://issues.apache.org/jira/browse/GERONIMO-3208
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.0-M6, 2.0.x, 2.1
> Environment: Windows XP SP2
>Reporter: Aman Nanner
>Assignee: Vamsavardhana Reddy
>Priority: Blocker
> Fix For: 2.0.2, 2.1
>
> Attachments: inplace-deployment-fails.ear.zip, nestedjarfile.patch
>
>
> I am using the latest SNAPSHOT of Geronimo.
> I was trying to deploy my custom application with Geronimo using "in-place"
> deployment, but it would fail with a ZipException and an "Access denied"
> message at the following line:
> {code}
> System Thread [RMI TCP Connection(189)-192.168.12.66] (Suspended (breakpoint
> at line 127 in InPlaceResourceContext))
> InPlaceResourceContext.flush() line: 127
> EARContext(DeploymentContext).flush() line: 428
> TomcatModuleBuilder(AbstractWebModuleBuilder).installModule(JarFile,
> EARContext, Module, Collection, ConfigurationStore, Collection) line: 312
> AbstractWebModuleBuilder$$FastClassByCGLIB$$8523248f.invoke(int,
> Object, Object[]) line: not available
> {code}
> So I tried creating a small EAR file for testing purposes, and deployment of
> it also failed but at a different point:
> {code}
> [java] Error: Unable to distribute testing.ear: Problem closing war
> context
> [java] Cannot rename file
> [java]
> D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war
> [java] to
> [java]
> D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war.saved
> {code}
> This failed at line 121 in the {{InPlaceResourceContext}} class. I've
> attached the sample EAR file that was causing me this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] G 2.0.2 Release plan
--- Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: > > > I see that Anita has attached some patches for the MEJB problem. We > need to get some eyes on these... > David J's changes to openejb and geronimo-openejb-builder [1] are required for MEJB to work on trunk. I will commit MEJB stuff after these changes are committed. [1] https://issues.apache.org/jira/browse/GERONIMO-3481 Thanks Anita Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
Re: [VOTE] Release ServiceMix 3.1.2
Btw, I think the KEYS file should be moved to http://svn.apache.org/repos/asf/incubator/servicemix/ instead of trunk + all branches. On 9/24/07, Freeman Fang <[EMAIL PROTECTED]> wrote: > Hi Dan, > > You can find my public key from > http://pgp.mit.edu:11371/pks/lookup?search=Freeman+Fang&op=vindex now, > signed by Bo. > Also I put it into KEYS. > > Since I generate new private and public key to sign and deploy it again, > so to verify the signature, you need download the kit and its .asc again. > > Best Regards > > > Freeman > > Daniel Kulp wrote: > > On Friday 21 September 2007, Guillaume Nodet wrote: > > > >> In theory, the public key should be in the web of trust. > >> See http://people.apache.org/~henkp/trust/ > >> > > > > Well, yes. But I need to see the key first to see if its been signed by > > anyone. Right now, we cannot even get that far > > > > Freeman: I assume you are sitting pretty close to Bo. The two of you > > should have a quick "key signing party" and get your keys signed. > > Then get the public key into the public keyservers and into the KEYS > > file. That would be a start (since Bo's key has been signed by other > > apache folks). > > > > Dan > > > > > > > >> On 9/21/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > >> > >>> Minor issue: > >>> Your GPG public key is not in the KEYS file. I also could not find > >>> it in the public keyserver at pgp.mit.edu. Thus, I could not > >>> verify the signatures. > >>> > >>> Dan > >>> > >>> Freeman Fang wrote: > >>> > Hi All, > > I have uploaded a version of ServiceMix 3.1.2 for you to review. > See http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.1.2 > for all the links and release notes. > > [ ] +1 Release ServiceMix 3.1.2 > [ ] ± 0 > [ ] -1 Do not release ServiceMix 3.1.2 > > Cheers > > Freeman > > >>> -- > >>> View this message in context: > >>> http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.2-tf4491617s1204 > >>> 9.html#a12824617 Sent from the ServiceMix - Dev mailing list archive > >>> at Nabble.com. > >>> > > > > > > > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: OSGifying org.apache.geronimo.specs
Did you compiled from trunk ? or just the activation spec tree ? You need a recent version of the parent pom which declares the bundle maven plugin. On 9/24/07, Rick McGuire <[EMAIL PROTECTED]> wrote: > I'm getting an error trying to build the javamail specs now, which > appears related to the OSGI changes: > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Cannot find lifecycle mapping for packaging: 'bundle'. > Component descriptor cannot be found in the component repository: > org.apache.mav > en.lifecycle.mapping.LifecycleMappingbundle. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Mon Sep 24 05:47:05 EDT 2007 > [INFO] Final Memory: 4M/254M > [INFO] > > > > Rick > > > Guillaume Nodet wrote: > > Yeah, good point. > > I've managed to somehow include both versions in the manifest. > > The specification version (javamail 1.4) goes into the package version > > for OSGi, whereas the maven version (1.2-SNAPSHOT) goes into the > > Bundle-Version manifest entry. > > I suppose this is the right way to deal with that, but the OSGi expert > > may be able to confirm that. > > > > On 9/21/07, Rick McGuire <[EMAIL PROTECTED]> wrote: > > > >> For the specs, there are generally 2 version identifiers. The first > >> level is the implementation level the spec is supposed to be at. For > >> example, javamail 1.4 or javamail 1.3.1. The second is the Geronimo > >> release version of that specification. For example, the javamail 1.4 > >> spec in trunk is currently at the 1.2-SNAPSHOT level. Does the > >> OSGIfication of these specs need to capture both levels? > >> > >> Also, for the javamail spec, there's a separate subtree for the Provider > >> implementation, which also includes an uber jar that bundles the > >> provider and spec classes in one jar file. I suspect these should also > >> have OSGI bundles too. The SVN tree for these packages can be found here: > >> > >> https://svn.apache.org/repos/asf/geronimo/javamail > >> > >> Rick > >> > >> Guillaume Nodet wrote: > >> > >>> So I've just commited a patch for everybody to review. > >>> I have tested some of the bundles inside servicemix 4.0, so at least > >>> i'm confident it won't break servicemix ;-) > >>> Seriously, they seem to be ok, though i had to limit the exported > >>> package from stax-api to javax.xml.stream* to not clash with other > >>> packages from the system bundle (I suppose this is the reason). > >>> See http://svn.apache.org/repos/asf/geronimo/specs/trunk/ > >>> > >>> On 9/21/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > >>> > >>> > For ServiceMix 4.0, which will be based on OSGi, I will need to have > OSGified versions of some of the spec jars that geronimo provides. > It's quite easy to do in ServiceMix (see > http://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0/bundles/ > for servlet, j2ee-management, jms mainly), but I think it would be > more useful for other projects if the specs jars were bundles > themselves. > > This is quite a simple process that can be done incrementally without > any real side effect and low risk of regression. So unless someone > objects, I'd like to start working on that. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > > > >>> > >>> > >> > > > > > > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Closed: (GERONIMO-3477) Transaction recovery broken for resource adapter
[ https://issues.apache.org/jira/browse/GERONIMO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Vaughton closed GERONIMO-3477. -- Separate JAR file sent to me works on top of 2.0.1 ok. The snapshot driver JNDI lookups from a J2SE client aren't working so I couldn't test the snapshot driver > Transaction recovery broken for resource adapter > > > Key: GERONIMO-3477 > URL: https://issues.apache.org/jira/browse/GERONIMO-3477 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.0.1 > Environment: GA version of Geronimo 2.0.1 running under Windows XP on > Intel machine >Reporter: Matthew Vaughton >Assignee: Kevan Miller > Fix For: 2.0.2, 2.1 > > > An external JMS Resource adapter is installed into Geronimo. > XA connections configured on the JMS resource adapter are used by a container > managed session EJB to connect and put a message onto two different remote > resource manager queues. Both resource managers XA resources receive a > preprere call and respond rc=0, ie ok. > The first resource manager is called to commit and it does so ok. > The second resource manager is called to commit at which point we kill the > Geronimo server process before the commit is processed. > After restarting the Geronimo server process recover is called on all XA > connections, the second resource manager responds to the recover call with > the indoubt transaction Xid but instead of the required commit call we > receive a rollback call - since the first resource manager has committed the > second resource manager must also be called to commit. > This problem was introduced into the Geronimo code base between M6-rc1 and > 2.0.1 as the transaction recovery scenario described worked fine in M6-rc1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
