Re: [VOTE] Apache XBean 4.24 release
+1 Le ven. 13 oct. 2023 à 16:42, fpapon a écrit : > Hi everyone, > > I submit Apache XBean 4.24 release to your vote. > > This release mainly includes (other issue description is available on > the release note): > > - ASM 9.6 update > > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312&version=12353264 > > > Staging Maven repository: > https://repository.apache.org/content/repositories/orgapachegeronimo-1162 > > Staging dist repository: > https://dist.apache.org/repos/dist/dev/geronimo/xbean/ > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > -- > -- > François > > -- > -- > François > > -- Guillaume Nodet
Re: [VOTE] Apache XBean 4.23 release
+1 Le ven. 13 oct. 2023 à 16:04, fpapon a écrit : > Hi everyone, > > I submit Apache XBean 4.24 release to your vote. > > This release mainly includes (other issue description is available on > the release note): > > - ASM 9.6 update > > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312&version=12353264 > > Staging Maven repository: > https://repository.apache.org/content/repositories/orgapachegeronimo-1162 > > Staging dist repository: > https://dist.apache.org/repos/dist/dev/geronimo/xbean/ > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > -- > -- > François > > -- Guillaume Nodet
Re: [VOTE] Apache XBean 4.23 release
+1 Le mar. 16 mai 2023 à 18:00, fpapon a écrit : > Hi everyone, > > I submit Apache XBean 4.23 release to your vote. > > This release mainly includes (other issue description is available on > the release note): > - ASM 9.5 update > > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312&version=12352402 > > Staging Maven repository: > https://repository.apache.org/content/repositories/orgapachegeronimo-1160 > > Staging dist repository: > https://dist.apache.org/repos/dist/dev/geronimo/xbean/ > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > -- > -- > François > > -- Guillaume Nodet
Re: [DISCUSS] graal tooling?
Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau a écrit : > > > Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet a > écrit : > >> >> >> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau >> a écrit : >> >>> >>> >>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet a >>> écrit : >>> >>>> >>>> >>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau >>>> a écrit : >>>> >>>>> Hi Raymond, >>>>> >>>>> What do you mean y "taking us down"? >>>>> To give some background, I have some use case where a k8s >>>>> orchestrator + native java run would be a good option compared to a long >>>>> running program (see it as lambda like archi). >>>>> I did some basic tooling - guess it is the same than you more or less >>>>> - and just would like a home for now. >>>>> Now I agree graal is not for all apps, it is not even possible to >>>>> compile a jdbc driver today - yes quarkus faked it ;). >>>>> >>>> >>>> I've been working on camel-quarkus recently and we do have integration >>>> tests that use JDBC and that are compiled to native mode. >>>> Not sure what you mean when you say it's not possible to compile a jdbc >>>> driver. I'd be interested in understanding what you mean here. >>>> >>> >>> It is going a bit off topic and guess if arthur has no strong objection >>> we'll discuss it a bit in other threads but long story short,if you dont >>> replace a bunch of code the driver will not work. Quarkus h2 kept only >>> client mode to simplify part of it. H2 by itself works in client, file and >>> mem if you do the reflection work but then if the jdbc pool or app uses >>> DriverManager, most codepath will require to load all the driver at build >>> time and often end up on some blocker you need to cut like natives or >>> unsupported api. I got the same experience with derby. It is not the driver >>> by itself but the SPI + common driver/jdbc usages which make it often hard >>> to use without forking part of the libs. >>> Fun fact is hikari is broken by that but not tomcat-jdbc cause their >>> load(driver)/DriverManager chain is opposed. >>> >> >> That's nothing related to Quarkus but just the effect of native code >> compilation I think. >> The limitation comes from compiling to native: the whole world has to be >> known at compile time, so dynamic class loading is not feasible. Loading a >> "new" jdbc driver dynamically will never work in native mode. However, the >> SPIs (be it xml, jaxb, jdbc or whatever) usually rely on loading a >> properties file and instantiating the class name found in it. This part >> can be made to work in native mode, but it has to be known at build time >> and taken care of. In this case, one needs to instruct the native compiler >> about the properties file (so that it's included in the native binary) and >> about the reflection needed for the driver class (so that it can be >> instantiated using its class name). >> So the short answer is : if you try to take any complex application and >> compile it to native mode, it won't work as is. And that's the reason why >> all libraries need to be "validated" before being usable in a native >> compilation : each limitation of the graal vm needs to be worked around, >> things explicited, reflection known before hand, etc... Quarkus, amongst >> other things, helps doing that and provides a set of "validated" components. >> > > I didnt say quarkus was guilty, point was that even the very high > investment ibm/redhat did, h2 is not supported by their stack except in > client mode which is not a simplicity sign. Sorry if it was ambiguous, my > point was not to blame but to highlight I agreee with Ray we must not > emphasis the simplicity of graal but only enable the build to be less hard. > Ok. What do you have in mind exactly ? At first glance, it seems you want to scan and register all classes for reflection and all resources to be included ? If that's what you have mind, I think it can cause some problems: the graal vm heavily rely on dead code elimination (because the world is known and it can analyse all the code paths). I fear that registering all classes for full reflection may have a very bad effect of actually killing any dead code elimination, because all methods / classes will have to be present in the compiled code.
Re: [DISCUSS] graal tooling?
Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau a écrit : > > > Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet a > écrit : > >> >> >> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau >> a écrit : >> >>> Hi Raymond, >>> >>> What do you mean y "taking us down"? >>> To give some background, I have some use case where a k8s orchestrator + >>> native java run would be a good option compared to a long running program >>> (see it as lambda like archi). >>> I did some basic tooling - guess it is the same than you more or less - >>> and just would like a home for now. >>> Now I agree graal is not for all apps, it is not even possible to >>> compile a jdbc driver today - yes quarkus faked it ;). >>> >> >> I've been working on camel-quarkus recently and we do have integration >> tests that use JDBC and that are compiled to native mode. >> Not sure what you mean when you say it's not possible to compile a jdbc >> driver. I'd be interested in understanding what you mean here. >> > > It is going a bit off topic and guess if arthur has no strong objection > we'll discuss it a bit in other threads but long story short,if you dont > replace a bunch of code the driver will not work. Quarkus h2 kept only > client mode to simplify part of it. H2 by itself works in client, file and > mem if you do the reflection work but then if the jdbc pool or app uses > DriverManager, most codepath will require to load all the driver at build > time and often end up on some blocker you need to cut like natives or > unsupported api. I got the same experience with derby. It is not the driver > by itself but the SPI + common driver/jdbc usages which make it often hard > to use without forking part of the libs. > Fun fact is hikari is broken by that but not tomcat-jdbc cause their > load(driver)/DriverManager chain is opposed. > That's nothing related to Quarkus but just the effect of native code compilation I think. The limitation comes from compiling to native: the whole world has to be known at compile time, so dynamic class loading is not feasible. Loading a "new" jdbc driver dynamically will never work in native mode. However, the SPIs (be it xml, jaxb, jdbc or whatever) usually rely on loading a properties file and instantiating the class name found in it. This part can be made to work in native mode, but it has to be known at build time and taken care of. In this case, one needs to instruct the native compiler about the properties file (so that it's included in the native binary) and about the reflection needed for the driver class (so that it can be instantiated using its class name). So the short answer is : if you try to take any complex application and compile it to native mode, it won't work as is. And that's the reason why all libraries need to be "validated" before being usable in a native compilation : each limitation of the graal vm needs to be worked around, things explicited, reflection known before hand, etc... Quarkus, amongst other things, helps doing that and provides a set of "validated" components. > > Romain > > > >> Guillaume >> >> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> Le ven. 25 oct. 2019 à 16:02, Raymond Auge a >>> écrit : >>> >>>> I'm not vehemently opposed as I have done my own graal salivating and >>>> not that I think anyone would care much even if I was completely opposed; >>>> but I will caution that this whole graal thing is a dangerous path that >>>> Oracle (and seemingly Redhat is just as happy to do it) are taking us all >>>> down. >>>> >>>> Anyway +0.5 >>>> >>>> Sincerely, >>>> - Ray >>>> >>>> On Fri, Oct 25, 2019 at 2:21 PM Francois Papon < >>>> francois.pa...@openobject.fr> wrote: >>>> >>>>> Hi Romain! >>>>> >>>>> I think it's a great idea, it make sense to have tooling around >>>>> graalvm. >>>>> >>>>> I will be more than happy to contribute ;) >>>>> >>>>> "arthur"
Re: [DISCUSS] graal tooling?
Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau a écrit : > Hi Raymond, > > What do you mean y "taking us down"? > To give some background, I have some use case where a k8s orchestrator + > native java run would be a good option compared to a long running program > (see it as lambda like archi). > I did some basic tooling - guess it is the same than you more or less - > and just would like a home for now. > Now I agree graal is not for all apps, it is not even possible to compile > a jdbc driver today - yes quarkus faked it ;). > I've been working on camel-quarkus recently and we do have integration tests that use JDBC and that are compiled to native mode. Not sure what you mean when you say it's not possible to compile a jdbc driver. I'd be interested in understanding what you mean here. Guillaume > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le ven. 25 oct. 2019 à 16:02, Raymond Auge a > écrit : > >> I'm not vehemently opposed as I have done my own graal salivating and not >> that I think anyone would care much even if I was completely opposed; but I >> will caution that this whole graal thing is a dangerous path that Oracle >> (and seemingly Redhat is just as happy to do it) are taking us all down. >> >> Anyway +0.5 >> >> Sincerely, >> - Ray >> >> On Fri, Oct 25, 2019 at 2:21 PM Francois Papon < >> francois.pa...@openobject.fr> wrote: >> >>> Hi Romain! >>> >>> I think it's a great idea, it make sense to have tooling around graalvm. >>> >>> I will be more than happy to contribute ;) >>> >>> "arthur" looks good to me :) >>> >>> regards, >>> >>> Françoisfpa...@apache.org >>> >>> Le 25/10/2019 à 09:00, Romain Manni-Bucau a écrit : >>> >>> Hi everyone, >>> >>> Wonder if we want to create a small project to simplify graalvm builds? >>> What I have in mind is basically a kind of main (+ maven wrapper) which >>> enables to use scanning at build time to prepare a binary, do the right >>> RuntimeReflection.register and set the right configuration for proxies, >>> resources etc. >>> It would be a companion of XBean finder - which is a perfect fit for >>> this phase - but likely outside of XBean since the project will likely >>> require to use docker for tests - since we go native, otherwise we wouldn't >>> build portably - and creates its own ecosystem. >>> >>> Side note: if we go with it, I'm tempted to call it "arthur", if you +1 >>> the idea don't hesitate to also comment on the name >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> > -- Guillaume Nodet
Re: Major updates to XBean
Over the last years, I have hardly seen anyone using the xbean-spring stuff anymore. I think most of custom namespaces have been implemented using JAXB instead. I think one of the problem is that the xml tends to be ugly, so starting from the xml and using JAXB usually makes more sense. I guess if you plan to use it in ActiveMQ, the generated schema has to be compatible with the previous ones, right ? Is that the case with your changes ? Guillaume Le jeu. 2 août 2018 à 16:17, a écrit : > Ladies and gentlemen, > I started messing around XBean as its codebase is in moderate form. I’ve > run into multiple issues while trying to get it running under Karaf 4.1 > together with ActiveMQ and decided to push it forward. I spent last couple > of days cleaning up duplicated code and refactoring maven plugin so it does > not depend on any specific generator. There is still lots of things to do > as there are several Spring tests which are failing. Due to stronger schema > validation around 15 spring tests currently fails. This is because > generated schema works only for basic elements and fails with embedded > collections. I already started to reform that part and I should be able to > update XsdGenerator. > > I would like to submit PR once I solve all the issues and test it with > ActiveMQ would you accept my work? Due to amount of breaking changes I > started 5.0.x branch (which might be good to start support Spring 4 or 5). > There is one big commit so far in my GitHub fork: > https://github.com/splatch/geronimo-xbean/tree/xbean-5.0.x, which I can > chunk into smaller (yet non compilable) commits in order to make history a > bit clearer. > > Kind regards, > Łukasz > — > Apache Karaf Commiter & PMC member > l...@code-house.org > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > -- Guillaume Nodet
Re: [VOTE] XBean 4.8 release
+1
2018-04-15 12:01 GMT+02:00 Romain Manni-Bucau :
> Hi!
>
> Please VOTE for the release of Apache XBean-4.8.
>
> Main changes are:
> 1. enhancement of multi jar release support
> 2. upgrade of asm to 6.1.1 (note it doesn't enable directly java 11
> support but if you create a V11 = OpCodes.V10+1 you can read *current* java
> 11 bytecode, if your proxy generation has a "findjavaversion" logic before
> creating the proxy it is transparent)
>
> Side note: in terms of License/Notice, we are on the same state than for
> 4.7 release.
>
> Here is the staging repo: https://repository.apache.org/
> content/repositories/orgapachegeronimo-1054/
> The source distribution can be found here: https://repository.apache.org/
> content/repositories/orgapachegeronimo-1054/org/
> apache/xbean/xbean/4.8/xbean-4.8-source-release.zip
> sha1 is 64f049581900a100206fa065501c043de4f9dc46w
>
> [+1] Release it
> [-1] Don't release ${because}
>
> The VOTE is open for 72h as usual.
>
> Here is my own +1.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
--
Guillaume Nodet
Re: xbean release 4.8
I think there is a pending PR to open up the range on xbean-spring so that it can work with recent spring releases... If you could hold a bit until it's merged in, that would be nice... Guillaume 2018-04-14 17:47 GMT+02:00 Romain Manni-Bucau : > Hi guys, > > we upgraded xbean asm shade to asm 6.1.1 and projects will want to > start integrating with it. Some mjar enhancements are in as well. > > For these reasons I'd like to release xbean 4.8. > > I know Mark had some potential enhancement for ClasspathArchive but > I'm not sure we want to get them in for this one since they can need > some more thoughts - or just change the way OWB uses it. > > Anything else we want in before the release? > > @Mark: what about the issue ^^? Anything to hack before the release? > > If no objection I'll try to start the release tomorrow (before the > work week for me). > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book > -- Guillaume Nodet
Re: [VOTE] XBean 4.6 release
+1
2017-11-20 9:12 GMT+01:00 Romain Manni-Bucau :
> Hi,
>
> As mentionned weeks ago now, I'd like to call a VOTE for the release
> of Apache XBean-4.6. The major changes is the upgrade to asm6 and a
> partial support of multi-release jars.
>
> Tags is available at
> https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.6/
> Release note can be found at
> https://issues.apache.org/jira/projects/XBEAN/versions/12338392
> Staging repo can be found at:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1044/
> (sources being at
> https://repository.apache.org/content/repositories/
> orgapachegeronimo-1044/org/apache/xbean/xbean/4.6/xbean-
> 4.6-source-release.zip,
> sha1 = a85b99ac68bc2d67fed7101ee294896caadb6124)
> My key can be found in https://svn.apache.org/repos/asf/geronimo/KEYS
>
> [+1] release it, all my stack is waiting for it!
> [+0] don’t care, java you said?
> [-1] no because ${blocker}
>
> The VOTE is open for 72h.
>
> Here is my +1.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn
>
--
Guillaume Nodet
Re: xbean java 9 state
I've just uploaded a release at https://repository.apache.org/content/repositories/orgapachegeronimo-1045 but I think you managed to upload it too as I found https://repository.apache.org/content/repositories/orgapachegeronimo-1044 Guillaume 2017-11-19 9:56 GMT+01:00 Romain Manni-Bucau : > Hi guys, > > tried to do a release but got an issue on mvn release:perform (uploads > actually) - don't know if that's nexus or my connection. > > The tag is available at > https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.6/, > anyone can have a try to do the perform for me please? > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > 2017-11-05 10:52 GMT+01:00 Romain Manni-Bucau : > > Just pushed the ignoring of module-info and seems it works and our > > scanning fallback seems also ok so we are good to start from my side. > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > > > > 2017-11-05 0:19 GMT+01:00 Jean-Louis MONTEIRO : > >> Hey Romain. > >> > >> Thanks for the update. I'd be happy to help at any time this week. > >> > >> Jean Louis > >> > >> > >> Le sam. 4 nov. 2017 à 19:18, Romain Manni-Bucau > a > >> écrit : > >>> > >>> Hi guys, > >>> > >>> I plan to check if we can merge module-info properly for our shades on > >>> trunk of xbean then I think we are good to release. If maven shade > >>> plugin doesn't support it properly I plan to exclude the file as a > >>> short term workaround to not hold the release. > >>> > >>> Will try to do it tomorrow or on monday. > >>> > >>> wdyt? Any other blocker? > >>> > >>> PS: I have some net issues at home ATM so can need help for the > >>> upload, anyone would have some cycles next week? > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn > -- Guillaume Nodet
Re: [VOTE] Release Geronimo Config 1.0
+1 2017-09-10 19:02 GMT+02:00 John D. Ament : > Hi All, > > I was performing the necessary steps to get the first release of Geronimo > Config out the door. At this point I'd like to call for a vote. > > Release notes can be found at https://issues.apache.org/ > jira/secure/ReleaseNote.jspa?projectId=10220&version=12341589 > The source release can be found at: https://repository.apache. > org/content/repositories/orgapachegeronimo-1037/org/ > apache/geronimo/config/geronimo-config/1.0/geronimo- > config-1.0-source-release.zip (with asc/md5/sha1 files next to it) > The staging repo can be found at: https://repository.apache. > org/content/repositories/orgapachegeronimo-1037/ > > I'll leave this vote open at least 72 hours, hopefully get 3 binding +1's > by then. > > Here's my own +1 to release > > [ ] +1 ship it > [ ] +/- 0 don't care > [ ] -1 don't ship because... > -- Guillaume Nodet
Re: [VOTE] [RESULT] retire/EOL the Geronimo Server part?
That was my understanding too. Especially, the initial vote email says "Note that this vote is only about the Geroniom Server but NOT about the shared components. Those components will be further maintained - or moved to a different project later." Which to me goes against your point #3. 2017-09-08 23:10 GMT+02:00 David Blevins : > Moving the thread over here so we’re all on the same page. > > > On Sep 8, 2017, at 3:28 AM, John D. Ament wrote: > > > > On Fri, Sep 8, 2017 at 2:45 AM David Blevins > wrote: > > > On Aug 30, 2017, at 12:14 PM, Mark Struberg wrote: > > > > > > +1 for going forward > > > > > > Note that I also totally understand Davids concerns about the public > perception about Geronimo and that people still think we talk about the > G-Server. > > > To mitigate this problem I pushed forward with retiring the GServer > part and move the Geronimo project to become an umbrella for Enterprise > Java Components. And of course if the VOTE succeeds, then we will quickly > also pimp the geronimo.a.o site to reflect the EOL state of GServer. > > > > > > @David, is that fine for you? > > > > I’ll be honest and say I feel a bit steam rolled. The “is this ok with > you” sent 5 minutes after the vote already started. Vote closed sharply at > 72 hours almost to the minute. I was home in WI on labor day weekend > visiting family for the first time in 2 years. > > > > I'm a bit confused. Which vote are you referring to? The decision to > retire Geronimo Server did close that weekend, but that feels very straight > forward, were you saying we shouldn't have retired it? > > I’ll try to be as clear as possible, let me know if you understand even if > you don’t agree. I’m ok with disagreement as long as I know there’s > understanding. > > Effectively there were two things voted on, and to some an implied third. > > 1. Retire Geronimo Server. This is an easy +1 for me. We should have > been clear with users and done that years ago. > > 2. Make Geronimo an “EE Commons”. I’m +0 on that. Having battled to > change the perception of EJB for 15+ years, I’m sensitive to the cost and > not excited to repeat that over the next 5 years attempting to convince > people “Geronimo” isn’t an app server anymore. I understand others are up > for the challenge, so I won’t stand in the way, I even applaud the spirit, > so +0 rather than -0. It is zero, however, as I don’t plan personally to > start new projects here for the reasons stated. Despite not having it in > me to push heavily for a Geronimo rebirth, I’ll help with what I can and > want nothing but the best. It is, after all, a major part of my life and > history and more strong Apache projects is never a bad thing. > > 3. [implied] Block other projects from having reusable “EE Components”. > I’m -1 on that. Not everyone who voted has this in mind, but I am seeing > yield and stop signs being thrown up at attempts for people in TomEE to > create reusable EE components. The vote or discussions here being used to > more or less say “we” have decided for all of Apache that no other project > should be allowed to do anything similar and if they are they’re hurting > Apache. Paraphrasing, I’ve seen “we agreed to do it in Geronimo, why are > you attempting to move forward elsewhere” has been said to me at least 3 > times over the last 2 months, even before a vote. > > Everyone is entitled to their opinion. I would specifically like the > words “we agreed” to be avoided on #3. Per letter of the law, this was not > explicitly voted on and even if it was an agreement by the Geronimo PMC > does not translate to other PMCs. In spirit, I would really like the same > support shown by the 6 of you who voted yes to Geronimo becoming an EE > Commons. If you see people getting excited about something in TomEE, > please extend the same "I won’t stand in the way, I even applaud the > spirit” and "more strong Apache projects is never a bad thing” mentality. > > For the 6 that voted, is my perspective clear? Not trying to convince > anyone as I understand everyone has their own perspective and vision. I > just want to make sure I’m communicating clearly as there are signs I am > not. > > > -David > > -- Guillaume Nodet
Re: [VOTE] retire/EOL the Geronimo Server part?
+1 2017-08-30 21:09 GMT+02:00 Mark Struberg : > Picking this up and pushing it further! > > After discussing this topic many times and finding no one willing to spend > time to actively evolve nor even maintain the Geronimo Server part I'd say > we should finally call a VOTE: > > This is a VOTE to announce the EOL the Geronimo Server parts, mostly > * https://svn.apache.org/repos/asf/geronimo/server/ > * https://svn.apache.org/repos/asf/geronimo/gshell/ > > We will also have to update our site, moving most of the current stuff to > a 'legacy' area and rework it to focus on the new project agenda: to serve > common EE components for other ASF projects. > > We also have a directory which contains binaries (jars) which don't even > have a license information. > We should absolutely get rid of them anyway from our repo! > https://svn.apache.org/repos/asf/geronimo/repository/ > > > Note that this vote is only about the Geroniom Server but NOT about the > shared components. > Those components will be further maintained - or moved to a different > project later. > > This includes, but is not limited to, the following Geronimo parts: > * the specs > * genesis (parents for xbean and specs) > * xbean > * the components javamail, transaction, config > Those parts WILL STAY, > > So please VOTE: > > [+1] Publicly announce that the Geroniom Server is EOL (End of Life) and > will not further be maintained but that the Geronimo Project will from now > on focus on reusable Java Enterprise components. > > [+0] meh, I don't care > > [-1] Nope, stop I need the Geronimo Server and I will ACTIVELY help to > maintain and evolve it in the future! > > > > Here is my +1 > > LieGrue, > strub > > > > Am 11.05.2017 um 22:09 schrieb Kevan Miller : > > > > There should be a public vote. > > > > On Wed, Apr 26, 2017 at 9:13 PM, Jean-Louis MONTEIRO > wrote: > > I think we came to an agreement so far > > > > > > Le mar. 25 avr. 2017 à 00:21, Mark Struberg a écrit > : > > Or do we need another formal vote? > > > > If we are all on the same boat, when, how and who is drafting the > Announcement? > > > > LieGrue, > > strub > > > > > > -- Guillaume Nodet
Re: [VOTE] geronimo-jcdi_2.0 spec jar
Well, I'm willing to fix some OSGi issues... and I was thinking about Geronimo, not all OSGi related issues in the world ;-) In particular, ensuring OWB works in OSGi is a big task, for which I don't have enough time unfortunately... I did some work some time ago on pax-cdi RC2, but the OSGi EEG is going a simplistic way for the CDI/OSGi integration (well, simplistic in terms of OSGi capabilities) and the RI is developped at Aries, though I think it's currently using Weld. Anyway, I'll have a closer look this very bundle soon. If you have pointers to other individual jars you want me to look at, let me know. 2017-06-27 14:55 GMT+02:00 Jean-Louis MONTEIRO : > I agree. If you could fixing the OSGi issues that'd be great. > > In addition to OWB, Meecrowave could also benefit from it. > BTW, if we could check and validate the transaction spec, that'd be > fantastic. > > > Le mar. 27 juin 2017 à 14:38, Mark Struberg a écrit : > >> txs and ping :D >> >> Nah, seriously, we are in the process of releasing OWB-2.0 _very_ soon. >> OWB already passes the CDI 2.0 TCK! >> >> So it would be really great if you could take a look and help us with >> OSGi support! >> It would be awesome if OWB would 'just work' in Karaf and other ASF OSGi >> projects! >> >> txs and LieGrue, >> strub >> >> >> > Am 27.06.2017 um 14:32 schrieb Guillaume Nodet : >> > >> > Changing my vote to +1. >> > >> > And feel free to ping me when preparing a release so that I can have a >> look at the OSGi stuff. >> > >> > 2017-06-27 14:16 GMT+02:00 Mark Struberg : >> > +1 >> > >> > We should also fix the point John raised. >> > John, you should now have committer rights, could you plz raise a >> ticket and commit it? :D >> > >> > @Guillaume, I think we currently only have 2 binding votes (Romain and >> me), so any 'help' would be appreciated ;) >> > >> > >> > That reminds we that the osgi module in OWB surely also needs some >> proper review. >> > It used to work in 2010 on Equinox, but never used it ever since. >> > So it might be good to check whether it is a.) still needed and b.) >> works at all these days ;) >> > >> > txs and LieGrue, >> > strub >> > >> > > Am 27.06.2017 um 14:03 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com>: >> > > >> > > well ServiceLoader doesn't work in OSGi in general - that's why we >> had that old ProviderLocator but this one has the issue to not always be >> well shaded making classes duplicated and leadind to issues too. >> > > >> > > I propose we let this vote pass and see if we can do better with more >> recent versions of OSGi? Any OSGi guru able to help on it? >> > > >> > > >> > > Romain Manni-Bucau >> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory >> > > >> > > 2017-06-27 14:00 GMT+02:00 John D. Ament : >> > > I just looked, the implementation of ServiceLoader is different for >> SeContainerInitializer and CDIProvider. >> > > >> > > https://github.com/apache/geronimo-specs/blob/trunk/ >> geronimo-jcdi_2.0_spec/src/main/java/javax/enterprise/inject/se/ >> SeContainerInitializer.java#L47 >> > > >> > > https://github.com/apache/geronimo-specs/blob/trunk/ >> geronimo-jcdi_2.0_spec/src/main/java/javax/enterprise/ >> inject/spi/CDI.java#L54 >> > > >> > > I know the latter does not work on OSGi environments, it relies on >> TCCL. >> > > >> > > John >> > > >> > > >> > > On Tue, Jun 27, 2017 at 7:38 AM Mark Struberg >> wrote: >> > > Hi Guillaume! >> > > >> > > I totally agree, but does this really block this release? >> > > I just moved over the OSGi setup from jcdi-1.1 and changed the >> versions. >> > > Is there any OSGi related bug I did overlook or is the support so far >> not enough? >> > > >> > > Would it work for you to get this version out of the door and then >> ship some patches which improve OSGi support? >> > > I'd happy to also work on improved OSGi support over at OpenWebBeans. >> > > But that's kind of 'improvement' and not a blocker for a release >> again imo, isn't? >> > > >> > > LieGrue, >> > > strub >> > > >> > > >
Re: [VOTE] geronimo-jcdi_2.0 spec jar
Changing my vote to +1.
And feel free to ping me when preparing a release so that I can have a look
at the OSGi stuff.
2017-06-27 14:16 GMT+02:00 Mark Struberg :
> +1
>
> We should also fix the point John raised.
> John, you should now have committer rights, could you plz raise a ticket
> and commit it? :D
>
> @Guillaume, I think we currently only have 2 binding votes (Romain and
> me), so any 'help' would be appreciated ;)
>
>
> That reminds we that the osgi module in OWB surely also needs some proper
> review.
> It used to work in 2010 on Equinox, but never used it ever since.
> So it might be good to check whether it is a.) still needed and b.) works
> at all these days ;)
>
> txs and LieGrue,
> strub
>
> > Am 27.06.2017 um 14:03 schrieb Romain Manni-Bucau >:
> >
> > well ServiceLoader doesn't work in OSGi in general - that's why we had
> that old ProviderLocator but this one has the issue to not always be well
> shaded making classes duplicated and leadind to issues too.
> >
> > I propose we let this vote pass and see if we can do better with more
> recent versions of OSGi? Any OSGi guru able to help on it?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> > 2017-06-27 14:00 GMT+02:00 John D. Ament :
> > I just looked, the implementation of ServiceLoader is different for
> SeContainerInitializer and CDIProvider.
> >
> > https://github.com/apache/geronimo-specs/blob/trunk/
> geronimo-jcdi_2.0_spec/src/main/java/javax/enterprise/inject/se/
> SeContainerInitializer.java#L47
> >
> > https://github.com/apache/geronimo-specs/blob/trunk/
> geronimo-jcdi_2.0_spec/src/main/java/javax/enterprise/
> inject/spi/CDI.java#L54
> >
> > I know the latter does not work on OSGi environments, it relies on TCCL.
> >
> > John
> >
> >
> > On Tue, Jun 27, 2017 at 7:38 AM Mark Struberg wrote:
> > Hi Guillaume!
> >
> > I totally agree, but does this really block this release?
> > I just moved over the OSGi setup from jcdi-1.1 and changed the versions.
> > Is there any OSGi related bug I did overlook or is the support so far
> not enough?
> >
> > Would it work for you to get this version out of the door and then ship
> some patches which improve OSGi support?
> > I'd happy to also work on improved OSGi support over at OpenWebBeans.
> > But that's kind of 'improvement' and not a blocker for a release again
> imo, isn't?
> >
> > LieGrue,
> > strub
> >
> > > Am 27.06.2017 um 13:29 schrieb Guillaume Nodet :
> > >
> > > -0
> > >
> > > It would be nice to have all the new specs released in an OSGi
> compatible way or not include OSGi support. The current state (OSGi
> metadata, but no way to find the provider) is not very satisfying imho.
> > >
> > > 2017-06-27 11:16 GMT+02:00 Mark Struberg :
> > > Hi!
> > >
> > > I'd like to call a VOTE on releasing our geronimo-jcdi_2.0 spec jar in
> version 1.0
> > > This is the API for CDI-2.0. The artifact does pass the CDI TCK and is
> binary compatible with the official artifact (signature comparison passed).
> > >
> > > The staging repo is:
> > > https://repository.apache.org/content/repositories/
> orgapachegeronimo-1034/
> > >
> > > The source release and binary is here:
> > > https://repository.apache.org/content/repositories/
> orgapachegeronimo-1034/org/apache/geronimo/specs/
> geronimo-jcdi_2.0_spec/1.0/
> > >
> > > Please VOTE:
> > >
> > > [+1] yeah, let's ship it!
> > > [+0] meh, don't care
> > > [-1] nope, because ${showstopper}
> > >
> > > The VOTE is open for 72h
> > >
> > > Here is my own +1
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Guillaume Nodet
> > >
> >
> >
>
>
--
Guillaume Nodet
Re: [VOTE] geronimo-jcdi_2.0 spec jar
2017-06-27 13:38 GMT+02:00 Mark Struberg :
> Hi Guillaume!
>
> I totally agree, but does this really block this release?
> I just moved over the OSGi setup from jcdi-1.1 and changed the versions.
> Is there any OSGi related bug I did overlook or is the support so far not
> enough?
>
> Would it work for you to get this version out of the door and then ship
> some patches which improve OSGi support?
> I'd happy to also work on improved OSGi support over at OpenWebBeans.
> But that's kind of 'improvement' and not a blocker for a release again
> imo, isn't?
>
Definitely, that's why I haven't voted -1 ;-)
I think there are enough votes already, but if not, I can change it to +1.
What I meant, is that I would rather have left the OSGi metadata out to not
lead people into thinking that it can actually be used in OSGi.
> LieGrue,
> strub
>
> > Am 27.06.2017 um 13:29 schrieb Guillaume Nodet :
> >
> > -0
> >
> > It would be nice to have all the new specs released in an OSGi
> compatible way or not include OSGi support. The current state (OSGi
> metadata, but no way to find the provider) is not very satisfying imho.
> >
> > 2017-06-27 11:16 GMT+02:00 Mark Struberg :
> > Hi!
> >
> > I'd like to call a VOTE on releasing our geronimo-jcdi_2.0 spec jar in
> version 1.0
> > This is the API for CDI-2.0. The artifact does pass the CDI TCK and is
> binary compatible with the official artifact (signature comparison passed).
> >
> > The staging repo is:
> > https://repository.apache.org/content/repositories/
> orgapachegeronimo-1034/
> >
> > The source release and binary is here:
> > https://repository.apache.org/content/repositories/
> orgapachegeronimo-1034/org/apache/geronimo/specs/
> geronimo-jcdi_2.0_spec/1.0/
> >
> > Please VOTE:
> >
> > [+1] yeah, let's ship it!
> > [+0] meh, don't care
> > [-1] nope, because ${showstopper}
> >
> > The VOTE is open for 72h
> >
> > Here is my own +1
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
> >
> > --
> >
> > Guillaume Nodet
> >
>
>
--
Guillaume Nodet
Re: [VOTE] geronimo-annotation_1.3 spec jar
+1
2017-06-26 22:57 GMT+02:00 Mark Struberg :
> Hi!
>
> I'd like to call a VOTE on our version of common-annoations 1.3.
> We need this for CDI-2.0. The only change is that @Priority is now also
> applicable to methods.
>
> Please VOTE for releasing geronimo-annotation_1.3_spec
>
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachegeronimo-1033
>
> The source zip is available at
> https://repository.apache.org/content/repositories/
> orgapachegeronimo-1033/org/apache/geronimo/specs/
> geronimo-annotation_1.3_spec/1.0/
>
>
> [+1] go for it
> [+0] don't care
> [-1] stop there is a ${showstopper}
>
>
> Here is my own +1
>
> txs and LieGrue,
> strub
--
Guillaume Nodet
Re: [VOTE] geronimo-jcdi_2.0 spec jar
-0
It would be nice to have all the new specs released in an OSGi compatible
way or not include OSGi support. The current state (OSGi metadata, but no
way to find the provider) is not very satisfying imho.
2017-06-27 11:16 GMT+02:00 Mark Struberg :
> Hi!
>
> I'd like to call a VOTE on releasing our geronimo-jcdi_2.0 spec jar in
> version 1.0
> This is the API for CDI-2.0. The artifact does pass the CDI TCK and is
> binary compatible with the official artifact (signature comparison passed).
>
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1034/
>
> The source release and binary is here:
> https://repository.apache.org/content/repositories/
> orgapachegeronimo-1034/org/apache/geronimo/specs/
> geronimo-jcdi_2.0_spec/1.0/
>
> Please VOTE:
>
> [+1] yeah, let's ship it!
> [+0] meh, don't care
> [-1] nope, because ${showstopper}
>
> The VOTE is open for 72h
>
> Here is my own +1
>
> txs and LieGrue,
> strub
>
>
--
Guillaume Nodet
Re: [VOTE] fold the various Geronimo subproject mailing lists to the main lists
+1 2017-04-21 15:24 GMT+02:00 Mark Struberg : > Hi! > > We currently have quite a few lists which have very low traffic. > > My findings are a result of browsing lists.a.o. > > > user@g.a.o -> merge into dev@g.a.o We only had 2 messages in the whole > last year! > > xbean-dev@g.a.o -> move to dev@g.a.o > > xbean-user@g.a.o -> move to dev@g.a.o > > xbean-scm@g.a.o -> move to scm@g.a.o > > geronimo-tck@g.a.o -> Last mail on Feb 2015. Traffic might to to > jcp-private@a.o; With Geronimo server getting discontinued we don't need > the TCK over here anyway > > pmc@g.a.o -> close it; hmm is this still alive? Should all go to > private@g.a.o; > > servicemix-tck@g.a.o -> close it; > > tck-committs@g.a.o -> close it; > > security@g.a.o -> full of spam! hell, this is a mess, we should drop it > and use private@g.a.o for handling security related things. wdyt? > > --- > > As a result we would keep the following lists: > > dev@g.a.o > private@g.a.o > scm@g.a.o (might eventually get renamed to committs@g.a.o to fit other > ASF projects, but that not urgent) > > > Any objections? > > The VOTE is open for 72h, after that I'll trigger the infra work. > > Here is my +1 > > txs and LieGrue, > strub > > > > -- Guillaume Nodet
Re: [VOTE] Release geroniom-jsonp_1.1 API.jar
+1
2017-04-17 0:08 GMT+02:00 Mark Struberg :
> Hi!
>
> Please VOTE on releasing version 1.0 of the Geronimo JSONP 1.1 API.
>
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachegeronimo-1031/
>
> The source package can be found at:
> https://repository.apache.org/content/repositories/
> orgapachegeronimo-1031/org/apache/geronimo/specs/
> geronimo-json_1.1_spec/1.0/
>
>
> I've verified the signature by comparing it to the official spec API jar.
>
> Please VOTE
>
> [+1] ship it!
> [+0] meh, don't care
> [-1] stop, because there is a ${showstopper}
>
>
> The VOTE is open for 72h min.
>
> Here is my own +1
>
> txs and LieGrue,
> strub
--
Guillaume Nodet
Re: [VOTE] geronimo-jsonb_1.0 v 1.0 API jar
+1
2017-04-21 17:16 GMT+02:00 Mark Struberg :
> Hi!
>
> Please VOTE on releasing version 1.0 of the Geronimo JSONB 1.0 API (JSON
> Binding).
>
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachegeronimo-1033/
>
> The source package can be found at:
> https://repository.apache.org/content/repositories/
> orgapachegeronimo-1032/org/apache/geronimo/specs/
> geronimo-jsonb_1.0_spec/1.0/
>
> I've verified the signature by comparing it to the official spec PFD API
> jar which got released today.
>
> Please VOTE
>
> [+1] ship it!
> [+0] meh, don't care
> [-1] stop, because there is a ${showstopper}
>
>
> The VOTE is open for 72h min.
>
> Here is my own +1
>
> txs and LieGrue,
> strub
--
Guillaume Nodet
Re: [VOTE] Release transaction manager 3.1.4
Thx ! 2016-11-22 22:50 GMT+01:00 Mark Struberg : > Just saw that Guillaume IS a geronimo PMC member. > > Thus we have 3 binding +1 and no -1 > > txs 2 all who voted! > > I gonna continue with the release. > > LieGrue, > strub > > > > > Am 22.11.2016 um 12:25 schrieb Mark Struberg : > > > > folks, we still need another VOTE! > > > > txs and LieGrue, > > strub > > > > > >> Am 10.11.2016 um 11:29 schrieb Guillaume Nodet : > >> > >> The release is staged at > >> https://repository.apache.org/content/repositories/ > orgapachegeronimo-1028 > >> > >> The only change is the fix for GERONIMO-4576: > >> https://issues.apache.org/jira/browse/GERONIMO-4576 > >> http://svn.apache.org/viewvc?view=revision&revision=1769063 > >> > >> Please review and vote, > >> > >> -- > >> > >> Guillaume Nodet > >> > >> Red Hat, Open Source Integration > >> > >> Email: gno...@redhat.com > >> Web: http://fusesource.com > >> Blog: http://gnodet.blogspot.com/ > >> > > > > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release transaction manager 3.1.4
+1 2016-11-10 11:29 GMT+01:00 Guillaume Nodet : > The release is staged at > https://repository.apache.org/content/repositories/ > orgapachegeronimo-1028 > > The only change is the fix for GERONIMO-4576: > https://issues.apache.org/jira/browse/GERONIMO-4576 > http://svn.apache.org/viewvc?view=revision&revision=1769063 > > Please review and vote, > > -- > ---- > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
[VOTE] Release transaction manager 3.1.4
The release is staged at https://repository.apache.org/content/repositories/orgapachegeronimo-1028 The only change is the fix for GERONIMO-4576: https://issues.apache.org/jira/browse/GERONIMO-4576 http://svn.apache.org/viewvc?view=revision&revision=1769063 Please review and vote, -- ---- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
[jira] [Resolved] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-4576. --- Resolution: Fixed Sending geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java Transmitting file data .done Committing transaction... Committed revision 1769063. > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Assignee: Guillaume Nodet >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-4576: -- Component/s: (was: persistence) transaction manager > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Assignee: Guillaume Nodet >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-4576: - Assignee: Guillaume Nodet > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Assignee: Guillaume Nodet >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release geronimo-validation 1.0 of the 1.1 spec version
+1
2016-10-06 14:37 GMT+02:00 Romain Manni-Bucau :
> Hi again,
>
> I'd still like to release a 1.0 of our validation jar.
>
> After having checked with gunnar the jar and removed the @Deprecated we
> had our jar should be fine (see https://github.com/beanva
> lidation/beanvalidation.org/issues/35#issuecomment-251938455 for the
> conversation on that) so I staged a 1.0 (yeah!).
>
> Here is the staging repo: https://repository.apache.org/content/
> repositories/orgapachegeronimo-1027/
>
> And the source jar is at:
> *https://repository.apache.org/content/repositories/orgapachegeronimo-1027/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1027/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip>*
>
>
> My key can be found at
> *https://dist.apache.org/repos/dist/release/tomee/KEYS
> <https://dist.apache.org/repos/dist/release/tomee/KEYS>*
>
> please VOTE
> [+1] all fine
> [+0] don't care
> [-1] stop, because ${good.reason}
>
> here is my +1
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [VOTE] XBean 4.5 release
+1
2015-11-23 11:51 GMT+01:00 Romain Manni-Bucau :
> Hi,
>
> Please VOTE for the release of Apache XBean-4.5.
>
> Here is the staging repo:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1025
>
> The source distribution can be found here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1025/org/apache/xbean/xbean/4.5/xbean-4.5-source-release.zip
> sha1 is 6ceb92588716ae848e3703533f4b83fe33efbde4
>
> The issue contained in this version is the string<->char[] conversion (
> https://issues.apache.org/jira/browse/XBEAN-290).
>
> [+1] release it
> [+0] don’t care
> [-1] no cause ${reason}
>
> The VOTE is open for 72h.
>
> Here is my +1.
>
> Romain Manni-Bucau
> @rmannibucau | http://rmannibucau.wordpress.com |
> https://github.com/rmannibucau
>
[RESULT] [VOTE] Release Transaction Manager 3.1.3
Closing this vote with 5 +1s. Thx to all ! Cheers, Guillaume Nodet 2015-06-13 8:31 GMT+02:00 Mark Struberg : > +1 > > LieGrue, > strub > > > Am 09.06.2015 um 09:24 schrieb Guillaume Nodet : > > > > I've uploaded a 3.1.3 release of the transaction manager component at > > > https://repository.apache.org/content/repositories/orgapachegeronimo-1020 > > > > This fixes the following issues: > > • GERONIMO-6543: Aries/Geronimo XA transaction recovery not > working for heuristically completed transactions > > > > Please review and vote ! > > > > Cheers, > > Guillaume Nodet > > > >
Re: [VOTE] Reease Transaction Manager 3.1.3
+1 2015-06-09 9:24 GMT+02:00 Guillaume Nodet : > I've uploaded a 3.1.3 release of the transaction manager component at > > https://repository.apache.org/content/repositories/orgapachegeronimo-1020 > > This fixes the following issues: > >- GERONIMO-6543: Aries/Geronimo XA transaction recovery not working >for heuristically completed transactions > > > Please review and vote ! > > Cheers, > Guillaume Nodet > >
[VOTE] Reease Transaction Manager 3.1.3
I've uploaded a 3.1.3 release of the transaction manager component at https://repository.apache.org/content/repositories/orgapachegeronimo-1020 This fixes the following issues: - GERONIMO-6543: Aries/Geronimo XA transaction recovery not working for heuristically completed transactions Please review and vote ! Cheers, Guillaume Nodet
[jira] [Resolved] (GERONIMO-6543) Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
[
https://issues.apache.org/jira/browse/GERONIMO-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved GERONIMO-6543.
---
Resolution: Fixed
svn commit -m "[GERONIMO-6543] Aries/Geronimo XA transaction recovery not
working for heuristically completed transactions"
Sending
geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java
Transmitting file data .
Committed revision 1684215.
> Aries/Geronimo XA transaction recovery not working for heuristically
> completed transactions
> ---
>
> Key: GERONIMO-6543
> URL: https://issues.apache.org/jira/browse/GERONIMO-6543
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Environment: Apache Karaf 2.3.0, JBoss Fuse 6.1-redhat-610379
>Reporter: Jörn Gersdorf
>Assignee: Guillaume Nodet
> Attachments: GERONIMO-6543.patch
>
>
> We´re facing a problem with XA transaction recovery when a resource manager
> (like in our case Websphere MQ) is reporting heuristically completed
> transactions.
> The flow goes like that (see
> {{org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(NamedXAResource)}}):
> • We´re starting JBoss Fuse, data/txlog/* has been deleted before start.
> • {{GenericResourceManager}} is starting recovery
> • The {{NamedXAResourceFactory}} is enlisted
> • Geronimo calls {{xa_recover(TM_STARTRSCAN | TMENDRSCAN)}} on the XA
> Resource (Websphere MQ)
> • Websphere MQ reports a XID which is to be recovered, Aries TxManager
> does not know about the XID so it tries to send xa_rollback to MQ
> • MQ already had the XID heuristically rolled back before, so it answers
> with {{XA_HEURRB (6)}}.
> • Geronimo logs the exception, but does not do anything about it
> Since Geronimo does not do anything about the pending transaction, it stays
> pending withing Websphere MQ, and the same error will occur upon next restart.
> What´s missing here from our perspective is a call to xa_forget after
> receiving a XA_HEURB.
> Btw, in {{org.apache.geronimo.transaction.manager.RollbackTask.run()}}
> {{XA_HEURRB}} seems to be handled correctly by sending an xa_forget.
> Stack trace below.
> We´re using following bundles:
> {noformat}
> [ 281] [Active ] [] [ ] [ 50]
> mvn:org.apache.geronimo.components/geronimo-connector/3.1.1
> [ 116] [Active ] [] [ ] [ 30]
> mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.1.redhat-610379
> [ 118] [Active ] [] [ ] [ 30]
> mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/1.0.1.redhat-610379
> [ 569] [Active ] [Created ] [ ] [ 50]
> mvn:org.apache.activemq/activemq-osgi/5.9.0.redhat-610379
> {noformat}
> Looking at the upstream source code the problem exists there, too:
> https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java#L127.
> {noformat}
> 2015-04-29 11:55:28,184 | TRACE | FelixStartLevel | WrapperNamedXAResource |
> 116 | Recover called on XAResource wmq-wpreconXA
> flags: TMENDRSCAN TMSTARTRSCAN remaining: 25165824
> 2015-04-29 11:55:28,187 | TRACE | FelixStartLevel | WrapperNamedXAResource |
> 116 | Rollback called on XAResource wmq-wpreconXA
> Xid: {JmqiXid@545310144: formatId(4765526f),
> gtrid(8df91ce04c016f72672e6170616368652e61726965732e7472616e73616374696f6e),
>
> bqual(0100308807e04c016170616368652e61726965732e7472616e73616374696f6e)}
> 2015-04-29 11:55:28,190 | ERROR | FelixStartLevel | Recovery | 116 | Could
> not roll back
> javax.transaction.xa.XAException: Methode 'xa_rollback' ist mit Fehlercode
> '6' fehlgeschlagen.
> at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:861)
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:100)
> at
> org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(RecoveryImpl.java:127)
> at
> org.apache.geronimo.transaction.manager.RecoverTask.run(RecoverTask.java:52)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.registerNamedXAResourceFactory(TransactionManagerI
Re: [VOTE] Release XBean-4.3
+1
2015-05-31 10:54 GMT+02:00 Mark Struberg :
> Hi!
>
> Please VOTE for the release of Apache XBean-4.3.
>
> Here is the staging repo:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1019/
>
> The source distribution can be found here:
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-1019/org/apache/xbean/xbean/4.3/xbean-4.3-source-release.zip
> sha1 is 950f7aa235662b7507c7f241bbe12dcec5330f55
>
>
> We fixed 5 issues, most notably the upgrade to ASM-5.0.4 and fixing the
> NOTICE and LICENSE for xbean-asm5-shaded.
>
> Bug
> • [XBEAN-282] - ClassLoaders.findUrls() can get duplicated when
> there is <= 1 urls (shades)
> • [XBEAN-283] - add a NOTICE file for xbean-asm5-shaded
> • [XBEAN-284] - code doesn't compile under Java6 anymore
>
> Improvement
> • [XBEAN-256] - Update apache-rat-plugin to exclude .git and
> .gitignore files
>
> Task
> • [XBEAN-285] - upgrade ASM to 5.0.4
>
>
> [+1] ship it
> [+0] meh, don’t care
> [-1] nope, stop because ${reason}
>
> The VOTE is open for 72h.
>
> Here is my +1.
>
> LieGrue,
> strub
[jira] [Updated] (GERONIMO-6543) Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
[
https://issues.apache.org/jira/browse/GERONIMO-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated GERONIMO-6543:
--
Attachment: GERONIMO-6543.patch
Possible patch ...
> Aries/Geronimo XA transaction recovery not working for heuristically
> completed transactions
> ---
>
> Key: GERONIMO-6543
> URL: https://issues.apache.org/jira/browse/GERONIMO-6543
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Environment: Apache Karaf 2.3.0, JBoss Fuse 6.1-redhat-610379
>Reporter: Jörn Gersdorf
>Assignee: Guillaume Nodet
> Attachments: GERONIMO-6543.patch
>
>
> We´re facing a problem with XA transaction recovery when a resource manager
> (like in our case Websphere MQ) is reporting heuristically completed
> transactions.
> The flow goes like that (see
> {{org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(NamedXAResource)}}):
> • We´re starting JBoss Fuse, data/txlog/* has been deleted before start.
> • {{GenericResourceManager}} is starting recovery
> • The {{NamedXAResourceFactory}} is enlisted
> • Geronimo calls {{xa_recover(TM_STARTRSCAN | TMENDRSCAN)}} on the XA
> Resource (Websphere MQ)
> • Websphere MQ reports a XID which is to be recovered, Aries TxManager
> does not know about the XID so it tries to send xa_rollback to MQ
> • MQ already had the XID heuristically rolled back before, so it answers
> with {{XA_HEURRB (6)}}.
> • Geronimo logs the exception, but does not do anything about it
> Since Geronimo does not do anything about the pending transaction, it stays
> pending withing Websphere MQ, and the same error will occur upon next restart.
> What´s missing here from our perspective is a call to xa_forget after
> receiving a XA_HEURB.
> Btw, in {{org.apache.geronimo.transaction.manager.RollbackTask.run()}}
> {{XA_HEURRB}} seems to be handled correctly by sending an xa_forget.
> Stack trace below.
> We´re using following bundles:
> {noformat}
> [ 281] [Active ] [] [ ] [ 50]
> mvn:org.apache.geronimo.components/geronimo-connector/3.1.1
> [ 116] [Active ] [] [ ] [ 30]
> mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.1.redhat-610379
> [ 118] [Active ] [] [ ] [ 30]
> mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/1.0.1.redhat-610379
> [ 569] [Active ] [Created ] [ ] [ 50]
> mvn:org.apache.activemq/activemq-osgi/5.9.0.redhat-610379
> {noformat}
> Looking at the upstream source code the problem exists there, too:
> https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java#L127.
> {noformat}
> 2015-04-29 11:55:28,184 | TRACE | FelixStartLevel | WrapperNamedXAResource |
> 116 | Recover called on XAResource wmq-wpreconXA
> flags: TMENDRSCAN TMSTARTRSCAN remaining: 25165824
> 2015-04-29 11:55:28,187 | TRACE | FelixStartLevel | WrapperNamedXAResource |
> 116 | Rollback called on XAResource wmq-wpreconXA
> Xid: {JmqiXid@545310144: formatId(4765526f),
> gtrid(8df91ce04c016f72672e6170616368652e61726965732e7472616e73616374696f6e),
>
> bqual(0100308807e04c016170616368652e61726965732e7472616e73616374696f6e)}
> 2015-04-29 11:55:28,190 | ERROR | FelixStartLevel | Recovery | 116 | Could
> not roll back
> javax.transaction.xa.XAException: Methode 'xa_rollback' ist mit Fehlercode
> '6' fehlgeschlagen.
> at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:861)
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:100)
> at
> org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(RecoveryImpl.java:127)
> at
> org.apache.geronimo.transaction.manager.RecoverTask.run(RecoverTask.java:52)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.registerNamedXAResourceFactory(TransactionManagerImpl.java:353)
> at
> Proxyc5f66ef2_fefc_4587_80b8_fb531eb6b156.registerNamedXAResourceFactory(Unknown
> Source)
> at
> org.apache.activemq.jms.pool.GenericResourceManager$Recovery.recover(GenericResourceManager.java:144)
> at
> org.apache.activ
[jira] [Assigned] (GERONIMO-6543) Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
[
https://issues.apache.org/jira/browse/GERONIMO-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned GERONIMO-6543:
-
Assignee: Guillaume Nodet
> Aries/Geronimo XA transaction recovery not working for heuristically
> completed transactions
> ---
>
> Key: GERONIMO-6543
> URL: https://issues.apache.org/jira/browse/GERONIMO-6543
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
> Environment: Apache Karaf 2.3.0, JBoss Fuse 6.1-redhat-610379
>Reporter: Jörn Gersdorf
>Assignee: Guillaume Nodet
>
> We´re facing a problem with XA transaction recovery when a resource manager
> (like in our case Websphere MQ) is reporting heuristically completed
> transactions.
> The flow goes like that (see
> {{org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(NamedXAResource)}}):
> • We´re starting JBoss Fuse, data/txlog/* has been deleted before start.
> • {{GenericResourceManager}} is starting recovery
> • The {{NamedXAResourceFactory}} is enlisted
> • Geronimo calls {{xa_recover(TM_STARTRSCAN | TMENDRSCAN)}} on the XA
> Resource (Websphere MQ)
> • Websphere MQ reports a XID which is to be recovered, Aries TxManager
> does not know about the XID so it tries to send xa_rollback to MQ
> • MQ already had the XID heuristically rolled back before, so it answers
> with {{XA_HEURRB (6)}}.
> • Geronimo logs the exception, but does not do anything about it
> Since Geronimo does not do anything about the pending transaction, it stays
> pending withing Websphere MQ, and the same error will occur upon next restart.
> What´s missing here from our perspective is a call to xa_forget after
> receiving a XA_HEURB.
> Btw, in {{org.apache.geronimo.transaction.manager.RollbackTask.run()}}
> {{XA_HEURRB}} seems to be handled correctly by sending an xa_forget.
> Stack trace below.
> We´re using following bundles:
> {noformat}
> [ 281] [Active ] [] [ ] [ 50]
> mvn:org.apache.geronimo.components/geronimo-connector/3.1.1
> [ 116] [Active ] [] [ ] [ 30]
> mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.1.redhat-610379
> [ 118] [Active ] [] [ ] [ 30]
> mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/1.0.1.redhat-610379
> [ 569] [Active ] [Created ] [ ] [ 50]
> mvn:org.apache.activemq/activemq-osgi/5.9.0.redhat-610379
> {noformat}
> Looking at the upstream source code the problem exists there, too:
> https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java#L127.
> {noformat}
> 2015-04-29 11:55:28,184 | TRACE | FelixStartLevel | WrapperNamedXAResource |
> 116 | Recover called on XAResource wmq-wpreconXA
> flags: TMENDRSCAN TMSTARTRSCAN remaining: 25165824
> 2015-04-29 11:55:28,187 | TRACE | FelixStartLevel | WrapperNamedXAResource |
> 116 | Rollback called on XAResource wmq-wpreconXA
> Xid: {JmqiXid@545310144: formatId(4765526f),
> gtrid(8df91ce04c016f72672e6170616368652e61726965732e7472616e73616374696f6e),
>
> bqual(0100308807e04c016170616368652e61726965732e7472616e73616374696f6e)}
> 2015-04-29 11:55:28,190 | ERROR | FelixStartLevel | Recovery | 116 | Could
> not roll back
> javax.transaction.xa.XAException: Methode 'xa_rollback' ist mit Fehlercode
> '6' fehlgeschlagen.
> at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:861)
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:100)
> at
> org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(RecoveryImpl.java:127)
> at
> org.apache.geronimo.transaction.manager.RecoverTask.run(RecoverTask.java:52)
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.registerNamedXAResourceFactory(TransactionManagerImpl.java:353)
> at
> Proxyc5f66ef2_fefc_4587_80b8_fb531eb6b156.registerNamedXAResourceFactory(Unknown
> Source)
> at
> org.apache.activemq.jms.pool.GenericResourceManager$Recovery.recover(GenericResourceManager.java:144)
> at
> org.apache.activemq.jms.pool.GenericResourceMan
[RESULT] [VOTE] Release Transaction Manager 3.1.2
Closing this vote with 5 +1s (4 bindings). I'll publish the repository asap. Thx for voting ! Guillaume Nodet 2015-04-17 13:24 GMT+02:00 Guillaume Nodet : > I've uploaded a 3.1.2 release of the transaction manager component at > > https://repository.apache.org/content/repositories/orgapachegeronimo-1018 > > This fixes the following issues: > * GERONIMO-6541: NPE during XAResource recovery with invalid Xids > * GERONIMO-6372: RecoveryImpl completing in-progress transactions, > XidFactoryImpl needs to be smarter with matching > * GERONIMO-6373: Expose HOWL flushPartialBuffer config via HOWLLog - > useful under low concurrency > > Please review and vote ! > > Cheers, > Guillaume Nodet > >
Re: [VOTE] Release Transaction Manager 3.1.2
+1 2015-04-17 13:24 GMT+02:00 Guillaume Nodet : > I've uploaded a 3.1.2 release of the transaction manager component at > > https://repository.apache.org/content/repositories/orgapachegeronimo-1018 > > This fixes the following issues: > * GERONIMO-6541: NPE during XAResource recovery with invalid Xids > * GERONIMO-6372: RecoveryImpl completing in-progress transactions, > XidFactoryImpl needs to be smarter with matching > * GERONIMO-6373: Expose HOWL flushPartialBuffer config via HOWLLog - > useful under low concurrency > > Please review and vote ! > > Cheers, > Guillaume Nodet > >
Re: [VOTE] Release Transaction Manager 3.1.2
I'll close the vote on monday, I was in vacation for the whole week... 2015-04-22 21:51 GMT+02:00 Mark Struberg : > Do you like to close this VOTE, Guillaume? > > LieGrue, > strub > > > Am 17.04.2015 um 13:24 schrieb Guillaume Nodet : > > > > I've uploaded a 3.1.2 release of the transaction manager component at > > > https://repository.apache.org/content/repositories/orgapachegeronimo-1018 > > > > This fixes the following issues: > > * GERONIMO-6541: NPE during XAResource recovery with invalid Xids > > * GERONIMO-6372: RecoveryImpl completing in-progress transactions, > XidFactoryImpl needs to be smarter with matching > > * GERONIMO-6373: Expose HOWL flushPartialBuffer config via HOWLLog - > useful under low concurrency > > > > Please review and vote ! > > > > Cheers, > > Guillaume Nodet > > > >
[VOTE] Release Transaction Manager 3.1.2
I've uploaded a 3.1.2 release of the transaction manager component at https://repository.apache.org/content/repositories/orgapachegeronimo-1018 This fixes the following issues: * GERONIMO-6541: NPE during XAResource recovery with invalid Xids * GERONIMO-6372: RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching * GERONIMO-6373: Expose HOWL flushPartialBuffer config via HOWLLog - useful under low concurrency Please review and vote ! Cheers, Guillaume Nodet
[DISCUSS] Release Transaction manager 3.1.2
I've fixed a small bug in the transaction manager this week, and there are one or two others fixed in the current trunk, so I was wondering about releasing this component. Any objection ? Cheers, Guillaume Nodet
[jira] [Resolved] (GERONIMO-6541) NPE during XAResource recovery with invalid Xids
[ https://issues.apache.org/jira/browse/GERONIMO-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-6541. --- Resolution: Fixed http://svn.apache.org/viewvc?view=revision&revision=1673231 > NPE during XAResource recovery with invalid Xids > > > Key: GERONIMO-6541 > URL: https://issues.apache.org/jira/browse/GERONIMO-6541 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager > Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > > In rare cases, the Oracle database may return Xid with null global > transaction id. While those are clearly invalid, it can cause NPE in the > transaction manager during the recovery phase, causing the application to not > restart properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GERONIMO-6541) NPE during XAResource recovery with invalid Xids
[ https://issues.apache.org/jira/browse/GERONIMO-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-6541: -- Summary: NPE during XAResource recovery with invalid Xids (was: NPE during XAResource recovery) > NPE during XAResource recovery with invalid Xids > > > Key: GERONIMO-6541 > URL: https://issues.apache.org/jira/browse/GERONIMO-6541 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager > Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > > In rare cases, the Oracle database may return Xid with null global > transaction id. While those are clearly invalid, it can cause NPE in the > transaction manager during the recovery phase, causing the application to not > restart properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GERONIMO-6541) NPE during XAResource recovery
Guillaume Nodet created GERONIMO-6541: - Summary: NPE during XAResource recovery Key: GERONIMO-6541 URL: https://issues.apache.org/jira/browse/GERONIMO-6541 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Reporter: Guillaume Nodet Assignee: Guillaume Nodet In rare cases, the Oracle database may return Xid with null global transaction id. While those are clearly invalid, it can cause NPE in the transaction manager during the recovery phase, causing the application to not restart properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GERONIMO-6532) Oracle does not support xa_end(TMFAIL)
Guillaume Nodet created GERONIMO-6532: - Summary: Oracle does not support xa_end(TMFAIL) Key: GERONIMO-6532 URL: https://issues.apache.org/jira/browse/GERONIMO-6532 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Reporter: Guillaume Nodet See http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_xa.htm#CHDEHGCJ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] XBean 3.18
+1 2014-05-20 22:56 GMT+02:00 Romain Manni-Bucau : > Hi, > > I'm starting a vote for xbean 3.18 release. > > The main changes are: > 1) removing asm5 from xbean-reflect > 2) more consistent for descriptor in AnnotationFinder (to let guy > extending it get more consistent information, mainly descriptors) > > Binaries: > https://repository.apache.org/content/repositories/orgapachegeronimo-1001/ > > Tag: > http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.18/ > > Vote open 72h. > > [ ] +1 release this > [ ] 0 don't care > [ ] -1 don't release this (please explain) > > > Here is my +1 > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau >
Re: [VOTE] XBean 3.17
+1 2014-03-31 21:54 GMT+02:00 Romain Manni-Bucau : > Hi, > > I'm starting a vote for an xbean 3.17 release. > > The main change is the removing of asm3 and 4 shades and the > replacement with asm5 one to be able to be compatible with java 8. > > Binaries: > > https://repository.apache.org/content/repositories/orgapachegeronimo-1000/ > (yeah this number is awesome ;)) > > Tag: > > http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.17/ > > Hope I didn't do something wrong since I'm not yet really familiar > with releases. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau >
[RESULT] [VOTE] Release stax-api-1.2 spec v 1.2
Closing this vote with 6 +1 votes (3 bindings). Thx to the reviewers, I'll promote this release now. Cheers, Guillaume 2013/11/27 Guillaume Nodet > I've uploaded a release at > > https://repository.apache.org/content/repositories/orgapachegeronimo-014/ > to fix the following issue: > https://issues.apache.org/jira/browse/GERONIMO-6509 > > Please review and vote, > > Cheers, > Guillaume > > -- --- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release stax-api-1.2 spec v 1.2
+1 I think we're still a bit short of binding votes ... 2013/11/27 Guillaume Nodet > I've uploaded a release at > > https://repository.apache.org/content/repositories/orgapachegeronimo-014/ > to fix the following issue: > https://issues.apache.org/jira/browse/GERONIMO-6509 > > Please review and vote, > > Cheers, > Guillaume > > -- --- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
[VOTE] Release stax-api-1.2 spec v 1.2
I've uploaded a release at https://repository.apache.org/content/repositories/orgapachegeronimo-014/ to fix the following issue: https://issues.apache.org/jira/browse/GERONIMO-6509 Please review and vote, Cheers, Guillaume
[jira] [Resolved] (GERONIMO-6509) XMLStreamException not calling "super(th)" in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-6509. --- Resolution: Fixed > XMLStreamException not calling "super(th)" in constructors > -- > > Key: GERONIMO-6509 > URL: https://issues.apache.org/jira/browse/GERONIMO-6509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Daniel Kulp >Assignee: Guillaume Nodet > > The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or > super(msg, th) for the constructors that take a throwable. There are two > problems this causes: > 1) The "cause" is never set so the exception.getCause() always returns null > and potentially important information in the cause is discarded. > 2) For the super(th) one, no message is set at all.Thus, all information > that could be useful is lost unless I specifically cast the exception to an > XMLStreamException and call the getNestedException(). Any generic exception > handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (GERONIMO-6509) XMLStreamException not calling "super(th)" in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-6509: - Assignee: Guillaume Nodet > XMLStreamException not calling "super(th)" in constructors > -- > > Key: GERONIMO-6509 > URL: https://issues.apache.org/jira/browse/GERONIMO-6509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Daniel Kulp >Assignee: Guillaume Nodet > > The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or > super(msg, th) for the constructors that take a throwable. There are two > problems this causes: > 1) The "cause" is never set so the exception.getCause() always returns null > and potentially important information in the cause is discarded. > 2) For the super(th) one, no message is set at all.Thus, all information > that could be useful is lost unless I specifically cast the exception to an > XMLStreamException and call the getNestedException(). Any generic exception > handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (GERONIMO-6509) XMLStreamException not calling "super(th)" in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833866#comment-13833866 ] Guillaume Nodet commented on GERONIMO-6509: --- Sendingsrc/main/java/javax/xml/stream/XMLStreamException.java Transmitting file data . Committed revision 1546066. > XMLStreamException not calling "super(th)" in constructors > -- > > Key: GERONIMO-6509 > URL: https://issues.apache.org/jira/browse/GERONIMO-6509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Daniel Kulp >Assignee: Guillaume Nodet > > The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or > super(msg, th) for the constructors that take a throwable. There are two > problems this causes: > 1) The "cause" is never set so the exception.getCause() always returns null > and potentially important information in the cause is discarded. > 2) For the super(th) one, no message is set at all.Thus, all information > that could be useful is lost unless I specifically cast the exception to an > XMLStreamException and call the getNestedException(). Any generic exception > handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (GERONIMO-6509) XMLStreamException not calling "super(th)" in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-6509: - Assignee: Guillaume Nodet > XMLStreamException not calling "super(th)" in constructors > -- > > Key: GERONIMO-6509 > URL: https://issues.apache.org/jira/browse/GERONIMO-6509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Daniel Kulp >Assignee: Guillaume Nodet > > The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or > super(msg, th) for the constructors that take a throwable. There are two > problems this causes: > 1) The "cause" is never set so the exception.getCause() always returns null > and potentially important information in the cause is discarded. > 2) For the super(th) one, no message is set at all.Thus, all information > that could be useful is lost unless I specifically cast the exception to an > XMLStreamException and call the getNestedException(). Any generic exception > handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (GERONIMO-6509) XMLStreamException not calling "super(th)" in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833867#comment-13833867 ] Guillaume Nodet commented on GERONIMO-6509: --- Sendingsrc/main/java/javax/xml/stream/FactoryConfigurationError.java Transmitting file data . Committed revision 1546068. > XMLStreamException not calling "super(th)" in constructors > -- > > Key: GERONIMO-6509 > URL: https://issues.apache.org/jira/browse/GERONIMO-6509 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Daniel Kulp >Assignee: Guillaume Nodet > > The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or > super(msg, th) for the constructors that take a throwable. There are two > problems this causes: > 1) The "cause" is never set so the exception.getCause() always returns null > and potentially important information in the cause is discarded. > 2) For the super(th) one, no message is set at all.Thus, all information > that could be useful is lost unless I specifically cast the exception to an > XMLStreamException and call the getNestedException(). Any generic exception > handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[RESULT] [VOTE] XBean 3.16 release
Closing this vote with 6 +1s (4 bindings) and no other votes. I'll publish the binaries asap. Thx to everyone for voting. 2013/11/13 Guillaume Nodet > I'm starting a vote for an xbean 3.16 release. > The 3.15 of last week is unusable in OSGi due to some OSGi metadata > problems. > See https://issues.apache.org/jira/browse/XBEAN-258 > > Binaries: > > https://repository.apache.org/content/repositories/orgapachegeronimo-130/ > > Tag: > > http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.16/ > > Please review and vote. > > > -- > --- > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > -- --- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [VOTE] XBean 3.16 release
+1 2013/11/13 Guillaume Nodet > I'm starting a vote for an xbean 3.16 release. > The 3.15 of last week is unusable in OSGi due to some OSGi metadata > problems. > See https://issues.apache.org/jira/browse/XBEAN-258 > > Binaries: > > https://repository.apache.org/content/repositories/orgapachegeronimo-130/ > > Tag: > > http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.16/ > > Please review and vote. > > > -- > --- > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > -- --- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
[VOTE] XBean 3.16 release
I'm starting a vote for an xbean 3.16 release. The 3.15 of last week is unusable in OSGi due to some OSGi metadata problems. See https://issues.apache.org/jira/browse/XBEAN-258 Binaries: https://repository.apache.org/content/repositories/orgapachegeronimo-130/ Tag: http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.16/ Please review and vote. -- --- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [VOTE] (take 2) Release genesis-2.1 and xbean-3.13
+1 for both On Fri, Mar 8, 2013 at 9:12 PM, Mark Struberg wrote: > > > Hi! > > I'd like to call a VOTE for the re-roll on genesis-2.1 and xbean-3.13. > I fixed the issues catched by Jarek, txs 4 the catch! > > > The Maven Staging Repo which contains both releases (xbean needs genesis): > https://repository.apache.org/content/repositories/orgapachegeronimo-004/ > > > SVN source tag for genesis: > https://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-2.1/ > > SVN source tag for xbean: > https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.13/ > > Source releases (plus hashes) are available under: > > https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/geronimo/genesis/genesis/2.1/ > > https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/xbean/xbean/3.13/ > > > > My PGP release key 2FDB81B1 is available at > https://svn.apache.org/repos/asf/geronimo/KEYS > > Kevan is so kind and will collect the JIRA bits (I have absolutely no > oversight about how to gather all the needed infos there). > > The VOTE will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 veto (and reason why) > > > There is a small (and old) guide for testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > In practice it's as easy as adding a profile to your ~/.m2/settings.xml > which contains the with the URL pointing to the > staging repo as posted above. > > > txs and LieGrue, > strub > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
[RESULT] [VOTE] Release XBean 3.12
Closing this vote with 3 binding +1s. I'll publish the artifacts asap. On Wed, Oct 10, 2012 at 2:28 PM, Ivan wrote: > +1, thanks, Guilaume ;-) > > > 2012/10/10 Jean-Baptiste Onofré > >> +1 (non binding) >> >> Regards >> JB >> >> >> On 10/03/2012 01:47 PM, Guillaume Nodet wrote: >> >>> I've staged a release of bean at: >>> https://repository.apache.org/**content/repositories/** >>> orgapachegeronimo-088/<https://repository.apache.org/content/repositories/orgapachegeronimo-088/> >>> >>> Tag: >>> http://svn.apache.org/repos/**asf/geronimo/xbean/tags/xbean-**3.12/<http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.12/>, >>> revision 1393394 >>> >>> Release notes: >>> >>> ** Bug >>> * [XBEAN-119] - ContextUtil$ReadOnlyBinding#**isRelative() always >>> returns false >>> * [XBEAN-121] - Constructor injection doesn't work with constructor >>> argument of type array >>> * [XBEAN-146] - xsd for list elements should be unbounded, not max=1 >>> * [XBEAN-190] - XBeanNamespaceHandler does not close resource input >>> streams >>> >>> ** Improvement >>> * [XBEAN-187] - SVN:IGNORE is missing for beanutils >>> * [XBEAN-200] - be able to use annotationfinder for non runtime >>> retention annotation >>> * [XBEAN-203] - Performance improvement by adding local cache for >>> MultiParentClassLoader#**loadClass >>> * [XBEAN-207] - FileArchive doesn't have a way to specify the base >>> package >>> * [XBEAN-208] - DelegatingBundle performance issues >>> * [XBEAN-227] - Add support for Spring 3.1 bean profiles >>> * [XBEAN-228] - Support aries blueprint 1.0 >>> * [XBEAN-229] - Make jexl an optional import on xbean-blueprint >>> >>> Please review and vote: >>>[ ] +1 release xbean 3.12 >>>[ ] -1 do not release >>> >>> -- >>> >>> Guillaume Nodet >>> >>> Blog: http://gnodet.blogspot.com/ >>> >>> FuseSource, Integration everywhere >>> http://fusesource.com >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > > -- > Ivan > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: [VOTE] Release XBean 3.12
+1 On Wed, Oct 3, 2012 at 1:47 PM, Guillaume Nodet wrote: > I've staged a release of bean at: > > https://repository.apache.org/content/repositories/orgapachegeronimo-088/ > > Tag: > http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.12/ , > revision 1393394 > > Release notes: > > ** Bug > * [XBEAN-119] - ContextUtil$ReadOnlyBinding#isRelative() always > returns false > * [XBEAN-121] - Constructor injection doesn't work with constructor > argument of type array > * [XBEAN-146] - xsd for list elements should be unbounded, not max=1 > * [XBEAN-190] - XBeanNamespaceHandler does not close resource input > streams > > ** Improvement > * [XBEAN-187] - SVN:IGNORE is missing for beanutils > * [XBEAN-200] - be able to use annotationfinder for non runtime > retention annotation > * [XBEAN-203] - Performance improvement by adding local cache for > MultiParentClassLoader#loadClass > * [XBEAN-207] - FileArchive doesn't have a way to specify the base > package > * [XBEAN-208] - DelegatingBundle performance issues > * [XBEAN-227] - Add support for Spring 3.1 bean profiles > * [XBEAN-228] - Support aries blueprint 1.0 > * [XBEAN-229] - Make jexl an optional import on xbean-blueprint > > Please review and vote: > [ ] +1 release xbean 3.12 > [ ] -1 do not release > > -- > > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > FuseSource, Integration everywhere > http://fusesource.com > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
[VOTE] Release XBean 3.12
I've staged a release of bean at: https://repository.apache.org/content/repositories/orgapachegeronimo-088/ Tag: http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.12/ , revision 1393394 Release notes: ** Bug * [XBEAN-119] - ContextUtil$ReadOnlyBinding#isRelative() always returns false * [XBEAN-121] - Constructor injection doesn't work with constructor argument of type array * [XBEAN-146] - xsd for list elements should be unbounded, not max=1 * [XBEAN-190] - XBeanNamespaceHandler does not close resource input streams ** Improvement * [XBEAN-187] - SVN:IGNORE is missing for beanutils * [XBEAN-200] - be able to use annotationfinder for non runtime retention annotation * [XBEAN-203] - Performance improvement by adding local cache for MultiParentClassLoader#loadClass * [XBEAN-207] - FileArchive doesn't have a way to specify the base package * [XBEAN-208] - DelegatingBundle performance issues * [XBEAN-227] - Add support for Spring 3.1 bean profiles * [XBEAN-228] - Support aries blueprint 1.0 * [XBEAN-229] - Make jexl an optional import on xbean-blueprint Please review and vote: [ ] +1 release xbean 3.12 [ ] -1 do not release -- ---- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
[jira] [Resolved] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
[
https://issues.apache.org/jira/browse/GERONIMO-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved GERONIMO-6372.
---
Resolution: Fixed
Not sure which version I should put. djencks ?
> RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be
> smarter with matching
> --
>
> Key: GERONIMO-6372
> URL: https://issues.apache.org/jira/browse/GERONIMO-6372
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.2
> Environment: Aries, OSGI, camel, activemq
>Reporter: Gary Tully
>Assignee: Guillaume Nodet
> Attachments: GERONIMO-6372.patch
>
>
> Given a camel route with from("activemq:a").to("activemq:b") in a Geronimo
> managed XA transaction. On start/restart new transactions are created in
> parallel with recovery of the jms components.
> There are two issues:
> * The Recovery processing can match new transactions through the
> XidFactory.matchXX methods and rollback new work in error. (Note: a
> xa_recover of activemq correctly returns *all* prepared transactions)
> * The XidFactoryImpl(byte[] seed) can create duplicate xids which could
> potentially interfere with recovering transactions and makes it impossible to
> determine from the logs what is going on.
> Xids should be globally unique and recoverable. So they need a persistent
> unique seed (provided through configuration) and an ever increasing id.
> The current time provides a simple approach to an increasing id that negates
> the need to persist the last used id in the transaction recovery log.
> (It has the downside of regressing if the XidFactory is recreated in the same
> millisecond, but I think this is in practice improbable outside unit tests.)
> If the id component is keyed of the epoch, a recovering XidFactory can match
> only old Xids, ones created by it in a previous incarnation. In this way it
> can avoid completing newly created transactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6373) Expose HOWL flushPartialBuffer config via HOWLLog - useful under low concurrency
[
https://issues.apache.org/jira/browse/GERONIMO-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved GERONIMO-6373.
---
Resolution: Fixed
Not sure which version I should put. djencks ?
> Expose HOWL flushPartialBuffer config via HOWLLog - useful under low
> concurrency
>
>
> Key: GERONIMO-6373
> URL: https://issues.apache.org/jira/browse/GERONIMO-6373
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.2.1
>Reporter: Gary Tully
>Assignee: Guillaume Nodet
> Attachments: GERONIMO-6372.patch
>
>
> HOWL XALogger supports flushPartialBuffers which is not configurable via
> Geronimo HOWLLog. It is useful in the case of low concurrency.
> It would be great to have this exposed in the HOWLLog constructor so that it
> be be configured.
> {code} /**
>* Indicates whether LogBufferManager should flush buffers
>* before they are full.
>*
>* Normally, buffers are flushed to disk only when
>* they become full. In lightly loaded situations,
>* one or more threads may have to wait until the
>* flushSleepTime expires before the buffer is written.
>* In the worst case, a single thread is using the
>* log, and every put() with sync requested will
>* be delayed flushSleepTime ms before the buffer is
>* written.
>*
>* Setting flushPartialBuffers true will allow
>* the LogBufferManager to flush buffers to disk
>* any time the channel is not busy. This improves
>* throughput in single threaded and lightly loaded
>* environments.
>*
>* By default, this feature is disabled (false) to
>* provide compatability with earlier versions of
>* this library.
>*/
> private boolean flushPartialBuffers = false;{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
[
https://issues.apache.org/jira/browse/GERONIMO-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned GERONIMO-6372:
-
Assignee: Guillaume Nodet
> RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be
> smarter with matching
> --
>
> Key: GERONIMO-6372
> URL: https://issues.apache.org/jira/browse/GERONIMO-6372
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.2
> Environment: Aries, OSGI, camel, activemq
>Reporter: Gary Tully
>Assignee: Guillaume Nodet
> Attachments: GERONIMO-6372.patch
>
>
> Given a camel route with from("activemq:a").to("activemq:b") in a Geronimo
> managed XA transaction. On start/restart new transactions are created in
> parallel with recovery of the jms components.
> There are two issues:
> * The Recovery processing can match new transactions through the
> XidFactory.matchXX methods and rollback new work in error. (Note: a
> xa_recover of activemq correctly returns *all* prepared transactions)
> * The XidFactoryImpl(byte[] seed) can create duplicate xids which could
> potentially interfere with recovering transactions and makes it impossible to
> determine from the logs what is going on.
> Xids should be globally unique and recoverable. So they need a persistent
> unique seed (provided through configuration) and an ever increasing id.
> The current time provides a simple approach to an increasing id that negates
> the need to persist the last used id in the transaction recovery log.
> (It has the downside of regressing if the XidFactory is recreated in the same
> millisecond, but I think this is in practice improbable outside unit tests.)
> If the id component is keyed of the epoch, a recovering XidFactory can match
> only old Xids, ones created by it in a previous incarnation. In this way it
> can avoid completing newly created transactions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6373) Expose HOWL flushPartialBuffer config via HOWLLog - useful under low concurrency
[
https://issues.apache.org/jira/browse/GERONIMO-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned GERONIMO-6373:
-
Assignee: Guillaume Nodet (was: David Jencks)
> Expose HOWL flushPartialBuffer config via HOWLLog - useful under low
> concurrency
>
>
> Key: GERONIMO-6373
> URL: https://issues.apache.org/jira/browse/GERONIMO-6373
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.2.1
>Reporter: Gary Tully
>Assignee: Guillaume Nodet
> Attachments: GERONIMO-6372.patch
>
>
> HOWL XALogger supports flushPartialBuffers which is not configurable via
> Geronimo HOWLLog. It is useful in the case of low concurrency.
> It would be great to have this exposed in the HOWLLog constructor so that it
> be be configured.
> {code} /**
>* Indicates whether LogBufferManager should flush buffers
>* before they are full.
>*
>* Normally, buffers are flushed to disk only when
>* they become full. In lightly loaded situations,
>* one or more threads may have to wait until the
>* flushSleepTime expires before the buffer is written.
>* In the worst case, a single thread is using the
>* log, and every put() with sync requested will
>* be delayed flushSleepTime ms before the buffer is
>* written.
>*
>* Setting flushPartialBuffers true will allow
>* the LogBufferManager to flush buffers to disk
>* any time the channel is not busy. This improves
>* throughput in single threaded and lightly loaded
>* environments.
>*
>* By default, this feature is disabled (false) to
>* provide compatability with earlier versions of
>* this library.
>*/
> private boolean flushPartialBuffers = false;{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release xbean 3.11.1
+1 On Fri, Jun 8, 2012 at 11:33 AM, Forrest Xia wrote: > This is a minor fix release for GERONIMO-6358 and XBean-203 > > > *The artifacts up for vote are:* > > https://repository.apache.org/content/repositories/orgapachegeronimo-211/org/apache/xbean/xbean/3.11.1/xbean-3.11.1-source-release.tar.gz > > https://repository.apache.org/content/repositories/orgapachegeronimo-211/org/apache/xbean/xbean/3.11.1/xbean-3.11.1-source-release.zip > > > *The tag is:* > https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.11.1/ > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > -- > Thanks! > > Regards, Forrest > > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: [VOTE] Release xbean 3.11.1
Fwiw, it also includes the fix for XBEAN-203. I was planning to do a bit more work before releasing, such as reviewing the existing liras and review attached patches, but it can wait. +1 On Fri, Jun 8, 2012 at 4:24 AM, Forrest Xia wrote: > This is a minor fix release for GERONIMO-6358. > > > The artifacts up for vote are: > https://repository.apache.org/content/repositories/orgapachegeronimo-205/org/apache/xbean/xbean/3.11.1/xbean-3.11.1-source-release.tar.gz > https://repository.apache.org/content/repositories/orgapachegeronimo-205/org/apache/xbean/xbean/3.11.1/xbean-3.11.1-source-release.zip > > > The tag is: > https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.11.1/ > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > -- > Thanks! > > Regards, Forrest > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Geronimo & Karaf & OpenEJB
Submit a patch ? ;-) Seriously, just look at your Java 7 implementation and come up with a list of packages. I don't think there's much more to do. Given it hasn't been released yet, I'm not sure a lot of people are using it (I don't have it installed myself) ... but it's better to be prepared. On Thu, Jul 28, 2011 at 08:40, pif wrote: > Hi Kevan, > > do you know when Karaf will support Java 7 or how can I fix > etc/config.properties # Standard package set. jre-1.6= for set. jre-1.7? > > Regards > Frank > > -- > View this message in context: > http://apache-geronimo.328035.n3.nabble.com/Geronimo-Karaf-OpenEJB-tp3151146p3205873.html > Sent from the Development mailing list archive at Nabble.com. > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: svn commit: r1055251 - in /geronimo/sandbox/djencks/txmanager: ./ geronimo-transaction/ geronimo-transaction/src/main/java/org/apache/geronimo/transaction/ geronimo-transaction/src/main/java/org/a
On Wed, Jan 5, 2011 at 06:46, David Jencks wrote: > Hi Guillaume, > > First of all note that this is in my sandbox and is to a large extent an > attempt to evaluate DS. It looks to me as if karaf does not include DS, is > there a reason you know of not to use it? While there are some odd bits it > looks pretty useful to me so far. The main odd bit I've found is I haven't > found a way to have a single-use factory that creates the service(s) that get > registered but is not registered itself. > > I hadn't looked closely but remembered, apparently wrongly, that the aries tm > used blueprint and didn't have a log. I'll certainly take a closer look. > Was there ever a discussion of developing or moving this osgi code to > geronimo? Neither the jta nor j2ca specs use the osgi enhancements AFAIK so > it seems like an independent issue to the spec enhancements. The goal was to implement the Spec coming out of the OSGi EEG around Transaction, so Aries seemed like a good fit. Note that the spec is mostly about registering the TransactonManager as an OSGi service, so not much here, I agree. As I said, I don't really care about where the code is, it has already moved around a few times, I won't object to a new move if it makes sense. > > I agree duplicating work between projects is a bad idea. It was a long time > ago and I may be mis-remembering but IIRC I didn't understand the objections > to the osgi enhancements to the specs. I didn't work on the geronimo osgi > spec enhancements but I believe they started from the servicemix versions but > Rick found that most of them didn't follow the spec requirements closely so > made a lot of changes. > > IIUC Rick has also come up with a replacement service locator that is osgi > friendly. It requires installation on the boot classpath, but for those > specs that can just use the built in service locator I think it might be > worth changing them back and relying on this somewhat more general solution. I agree, but the ServiceMix community was not really involved in the process, leading to a duplication of efforts, since the Servicemix community still work on the specs and that lots of specs we need aren't provided by the geronimo ones, so we can't really migrate anyway. > > thanks > david jencks > > On Jan 4, 2011, at 5:12 PM, Guillaume Nodet wrote: > >> On Wed, Jan 5, 2011 at 02:00, David Jencks wrote: >>> 1. I wanted to learn about DS >>> 2. I wanted to use config admin which I don't think is really ready in >>> blueprint >> >> The Aries Transaction manager does not use blueprint, just plain OSGi, >> so no DS dependency even. >> The current implementation uses a ManagedServiceFactory and is fully >> configured using config admin. >> >>> 3. I don't think the aries tm has a tx log nor exposes many of the >>> interfaces we need. >> >> It has the tx log configured and exposes the following interfaces: >> clazzes.add(TransactionManager.class.getName()); >> clazzes.add(TransactionSynchronizationRegistry.class.getName()); >> clazzes.add(UserTransaction.class.getName()); >> clazzes.add(RecoverableTransactionManager.class.getName()); >> If any are missing, a simple additional line should work. >> >>> 4. the tx manager is a geronimo project, we should be the ones making it >>> osgi-friendly. >> >> I don't have any problems moving OSGi related things back to Geronimo, >> but this project started in ServiceMix even before Geronimo considered >> OSGi at all. >> The project moved to Aries and it may make sense to move it back to >> Geronimo, but please don't duplicate the work if there's no real >> reason. >> The same thing already happened with the osgi enabled specs that have >> been duplicated from ServiceMix to Geronimo instead of collaborating >> on some enhancements (if you remember, those enhancements had first >> been rejected the geronimo community when I tried to introduce those a >> few years ago). >> >>> >>> david jencks >>> >>> On Jan 4, 2011, at 4:44 PM, Guillaume Nodet wrote: >>> >>>> Why not reusing the Aries one ? >>>> >>>> On Wed, Jan 5, 2011 at 01:28, wrote: >>>>> Author: djencks >>>>> Date: Wed Jan 5 00:28:20 2011 >>>>> New Revision: 1055251 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1055251&view=rev >>>>> Log: >>>>> set up our tm as an osgi DS >>>>> >>>>> Added: >>&
Re: svn commit: r1055251 - in /geronimo/sandbox/djencks/txmanager: ./ geronimo-transaction/ geronimo-transaction/src/main/java/org/apache/geronimo/transaction/ geronimo-transaction/src/main/java/org/a
On Wed, Jan 5, 2011 at 02:00, David Jencks wrote: > 1. I wanted to learn about DS > 2. I wanted to use config admin which I don't think is really ready in > blueprint The Aries Transaction manager does not use blueprint, just plain OSGi, so no DS dependency even. The current implementation uses a ManagedServiceFactory and is fully configured using config admin. > 3. I don't think the aries tm has a tx log nor exposes many of the interfaces > we need. It has the tx log configured and exposes the following interfaces: clazzes.add(TransactionManager.class.getName()); clazzes.add(TransactionSynchronizationRegistry.class.getName()); clazzes.add(UserTransaction.class.getName()); clazzes.add(RecoverableTransactionManager.class.getName()); If any are missing, a simple additional line should work. > 4. the tx manager is a geronimo project, we should be the ones making it > osgi-friendly. I don't have any problems moving OSGi related things back to Geronimo, but this project started in ServiceMix even before Geronimo considered OSGi at all. The project moved to Aries and it may make sense to move it back to Geronimo, but please don't duplicate the work if there's no real reason. The same thing already happened with the osgi enabled specs that have been duplicated from ServiceMix to Geronimo instead of collaborating on some enhancements (if you remember, those enhancements had first been rejected the geronimo community when I tried to introduce those a few years ago). > > david jencks > > On Jan 4, 2011, at 4:44 PM, Guillaume Nodet wrote: > >> Why not reusing the Aries one ? >> >> On Wed, Jan 5, 2011 at 01:28, wrote: >>> Author: djencks >>> Date: Wed Jan 5 00:28:20 2011 >>> New Revision: 1055251 >>> >>> URL: http://svn.apache.org/viewvc?rev=1055251&view=rev >>> Log: >>> set up our tm as an osgi DS >>> >>> Added: >>> >>> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/DSTransactionManager.java >>> (with props) >>> Modified: >>> geronimo/sandbox/djencks/txmanager/geronimo-transaction/pom.xml >>> >>> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/GeronimoTransactionManager.java >>> geronimo/sandbox/djencks/txmanager/pom.xml >>> >>> Modified: geronimo/sandbox/djencks/txmanager/geronimo-transaction/pom.xml >>> URL: >>> http://svn.apache.org/viewvc/geronimo/sandbox/djencks/txmanager/geronimo-transaction/pom.xml?rev=1055251&r1=1055250&r2=1055251&view=diff >>> == >>> --- geronimo/sandbox/djencks/txmanager/geronimo-transaction/pom.xml >>> (original) >>> +++ geronimo/sandbox/djencks/txmanager/geronimo-transaction/pom.xml Wed Jan >>> 5 00:28:20 2011 >>> @@ -67,25 +67,64 @@ >>> >>> >>> >>> + org.apache.felix >>> + org.apache.felix.scr.annotations >>> + >>> + >>> + org.osgi >>> + org.osgi.core >>> + >>> + >>> junit >>> junit >>> test >>> >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> >>> >>> >>> >>> >>> org.apache.felix >>> + maven-scr-plugin >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> >>> + >>> >>> + >>> >>> + >>> + >>> + >>> + >>> + >>> + org.apache.felix >>> maven-bundle-plugin >>> >>> >>> >>> org.apache.geronimo.transaction*;version=3.0 >>>
Re: svn commit: r1055251 - in /geronimo/sandbox/djencks/txmanager: ./ geronimo-transaction/ geronimo-transaction/src/main/java/org/apache/geronimo/transaction/ geronimo-transaction/src/main/java/org/a
dXAResourceFactory(namedXAResourceFactory);
> + }
> +
> + public void unregisterNamedXAResourceFactory(String
> namedXAResourceFactoryName) {
> +
> delegate.unregisterNamedXAResourceFactory(namedXAResourceFactoryName);
> + }
> +
> + public Map getExternalXids() {
> + return delegate.getExternalXids();
> + }
> +
> + public void addTransactionAssociationListener(TransactionManagerMonitor
> listener) {
> + delegate.addTransactionAssociationListener(listener);
> + }
> +
> + public void
> removeTransactionAssociationListener(TransactionManagerMonitor listener) {
> + delegate.removeTransactionAssociationListener(listener);
> + }
> +
> + public void commit(Xid xid, boolean onePhase) throws XAException {
> + delegate.commit(xid, onePhase);
> + }
> +
> + public void forget(Xid xid) throws XAException {
> + delegate.forget(xid);
> + }
> +
> + public int prepare(Xid xid) throws XAException {
> + return delegate.prepare(xid);
> + }
> +
> + public Xid[] recover(int flag) throws XAException {
> + return delegate.recover(flag);
> + }
> +
> + public void rollback(Xid xid) throws XAException {
> + delegate.rollback(xid);
> + }
> +
> + public void begin(Xid xid, long txTimeoutMillis) throws XAException,
> InvalidTransactionException, SystemException,
> ImportedTransactionActiveException {
> + delegate.begin(xid, txTimeoutMillis);
> + }
> +
> + public void end(Xid xid) throws XAException, SystemException {
> + delegate.end(xid);
> + }
> +}
>
> Propchange:
> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/DSTransactionManager.java
> --
> svn:eol-style = native
>
> Propchange:
> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/DSTransactionManager.java
> --
> svn:keywords = Date Revision
>
> Propchange:
> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/DSTransactionManager.java
> --
> svn:mime-type = text/plain
>
> Modified:
> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/GeronimoTransactionManager.java
> URL:
> http://svn.apache.org/viewvc/geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/GeronimoTransactionManager.java?rev=1055251&r1=1055250&r2=1055251&view=diff
> ==
> ---
> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/GeronimoTransactionManager.java
> (original)
> +++
> geronimo/sandbox/djencks/txmanager/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/GeronimoTransactionManager.java
> Wed Jan 5 00:28:20 2011
> @@ -16,10 +16,10 @@
> */
> package org.apache.geronimo.transaction.manager;
>
> -import java.util.Collection;
> import java.util.HashMap;
> import java.util.Iterator;
> import java.util.Map;
> +
> import javax.resource.spi.XATerminator;
> import javax.transaction.InvalidTransactionException;
> import javax.transaction.Status;
>
> Modified: geronimo/sandbox/djencks/txmanager/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/sandbox/djencks/txmanager/pom.xml?rev=1055251&r1=1055250&r2=1055251&view=diff
> ==
> --- geronimo/sandbox/djencks/txmanager/pom.xml (original)
> +++ geronimo/sandbox/djencks/txmanager/pom.xml Wed Jan 5 00:28:20 2011
> @@ -26,7 +26,7 @@
> org.apache.geronimo.genesis
> genesis-java5-flava
> 2.0
> -
> +
>
>
> org.apache.geronimo.components
> @@ -89,7 +89,7 @@
> geronimo-j2ee-connector_1.6_spec
> 1.0
>
> -
> +
>
> org.apache.geronimo.specs
> geronimo-validation_1.0_spec
> @@ -110,6 +110,16 @@
> test
>
>
> +
> + org.apache.felix
> + org.apache.felix.scr.annotations
> + 1.4.0
> +
> +
> + org.osgi
> + org.osgi.core
> + 4.2.0
> +
>
>
>
> @@ -129,6 +139,22 @@
>
>
>
> +
> + org.apache.felix
> + maven-scr-plugin
> + 1.6.0
> +
> +
> + generate-scr-scrdescriptor
> +
> + scr
> +
> +
> +
> +
> + 1.1
> +
> +
>
>
>
>
>
>
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: [Discussion] Upgrade org.eclipse.osgi from 3.5.1.v20090827 to 3.6.0
Yeah, sorry, that's the one i was thinking about. Actually, the workaround is the following: https://github.com/apache/karaf/commit/4ed4d1f38569be52f79e9f114d2706b9a76477b9 On Wed, Nov 17, 2010 at 11:22, viola lu wrote: > Thanks. but i found there is only a karaf-jaas-boot.jar which already under > lib/ folder, no karaf-boot.jar. I also downloaded a > apache-karaf-2.1.1.zip, i only found a karaf-jaas-boot.jar, no > karaf-boot.jar:(. Where can i find karaf-boot.jar? > Thanks in advance! > On Wed, Nov 17, 2010 at 6:07 PM, Guillaume Nodet wrote: >> >> We have a problem with 2.1.1 and we will roll out a karaf 2.1.2 this >> week or next. >> A simple workaround is to change the startup script so that >> karaf-boot.jar is included in the boot classpath. >> >> On Wed, Nov 17, 2010 at 10:59, viola lu wrote: >> > Thanks Rex and Shawn. >> > I tried to upgrade karaf and org.eclipse.osgi as below: >> > framework/pom.xml >> > >> > org.eclipse >> > osgi >> > 3.6.0.v20100517 >> > >> > framework/config/karaf-framework/pom.xml >> > 2.1.1 >> > 3.6.0.v20100517 >> > Build successfully, but fail to login admin console. "Invalid >> > username/password".:( >> > Working on why this happened. >> > On Wed, Nov 17, 2010 at 11:28 AM, Rex Wang wrote: >> >> >> >> I prefer to update karaf to 2.2.1 and together with equinox >> >> 3.6.0.v20100517... >> >> >> >> 2010/11/17 viola lu >> >>> >> >>> Hi, Dev: >> >>> When i fix the jira >> >>> https://issues.apache.org/jira/browse/GERONIMO-5615, >> >>> found that it's a bug in org.eclipse.osgi v3.5 which cann't support >> >>> bundle >> >>> file path containing %20 instead of space very well.From eclipse >> >>> bugzillia >> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=290193, eclipse 3.6 has >> >>> already fixed this problem. So post here to get your feedback about >> >>> whether >> >>> it's ok to upgrade org.eclipse.osgi from 3.5.1.v20090827 to 3.6? I >> >>> already >> >>> opened a jira: https://issues.apache.org/jira/browse/GERONIMO-5699 to >> >>> track >> >>> this upgrade problem, if upgrade is OK, i will upload a patch for it. >> >>> Appreciate your response! >> >>> >> >>> -- >> >>> viola >> >> >> >> >> >> >> >> -- >> >> Lei Wang (Rex) >> >> rwonly AT apache.org >> > >> > >> > >> > -- >> > viola >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com > > > > -- > viola > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Discussion] Upgrade org.eclipse.osgi from 3.5.1.v20090827 to 3.6.0
We have a problem with 2.1.1 and we will roll out a karaf 2.1.2 this week or next. A simple workaround is to change the startup script so that karaf-boot.jar is included in the boot classpath. On Wed, Nov 17, 2010 at 10:59, viola lu wrote: > Thanks Rex and Shawn. > I tried to upgrade karaf and org.eclipse.osgi as below: > framework/pom.xml > > org.eclipse > osgi > 3.6.0.v20100517 > > framework/config/karaf-framework/pom.xml > 2.1.1 > 3.6.0.v20100517 > Build successfully, but fail to login admin console. "Invalid > username/password".:( > Working on why this happened. > On Wed, Nov 17, 2010 at 11:28 AM, Rex Wang wrote: >> >> I prefer to update karaf to 2.2.1 and together with equinox >> 3.6.0.v20100517... >> >> 2010/11/17 viola lu >>> >>> Hi, Dev: >>> When i fix the jira https://issues.apache.org/jira/browse/GERONIMO-5615, >>> found that it's a bug in org.eclipse.osgi v3.5 which cann't support bundle >>> file path containing %20 instead of space very well.From eclipse bugzillia >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=290193, eclipse 3.6 has >>> already fixed this problem. So post here to get your feedback about whether >>> it's ok to upgrade org.eclipse.osgi from 3.5.1.v20090827 to 3.6? I already >>> opened a jira: https://issues.apache.org/jira/browse/GERONIMO-5699 to track >>> this upgrade problem, if upgrade is OK, i will upload a patch for it. >>> Appreciate your response! >>> >>> -- >>> viola >> >> >> >> -- >> Lei Wang (Rex) >> rwonly AT apache.org > > > > -- > viola > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Specs jars in OSGi
Is there a description about how the spec jars work in OSGi ? I recall some discussion a long time ago, but i'd like to undestand what he main differences wrt the ServiceMix Specs jars are? Should we (ServiceMix) start to use the Geronimo ones instead ? That's the question I'd like to have an answer at. In which case, should we start pushing out from Geronimo non-j2ee specs like javax.scripting and others ... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] release geronimo txmanager and connector components 2.2
+1 On Fri, Sep 24, 2010 at 15:30, Rick McGuire wrote: > This is a new release that will be used for the Geronimo server 2.2.1 and > 2.1.7 releases. The major updates are improved transaction recovery support > and improved logging. The following Jiras are included in this update. > > GERONIMO-5558 Transaction Commit status is not configured correctly > GERONIMO-5152 fix potential NPE, if a null xaResource is returned > GERONIMO-5530 Only recover if there's a non-null XAResource > GERONIMO-5152 fix some java 5 compile issues > GERONIMO-5152 port the fix about heuristic rollback on first resource from > txmanager trunk > GERONIMO-5519 match up the xid with the name during recovery. Add some > more tracing > GERONIMO-5189 allow share method to accept any ConnectorInstanceContext > implementors > > The components up for vote are: > > > org/apache/geronimo/components/geronimo-txmanager-parent/2.2/geronimo-txmanager-parent-2.2-source-release.tar.gz > > org/apache/geronimo/components/geronimo-txmanager-parent/2.2/geronimo-txmanager-parent-2.2-source-release.zip > > from the staging repository at: > > https://repository.apache.org/content/repositories/orgapachegeronimo-011/ > > The source repo is: > > > https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.2 > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > Rick > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Use Truezip in Geronimo deployment
I'd rather use a deployment which can handle unpacked archives and zip them on the fly. The karaf deployer supports that (if you're in Geronimo 3). It may even work with symlinks (not sure though) so you could link to the output of your build directly. Just my 2 cents. On Wed, Sep 29, 2010 at 10:40, Ivan wrote: > Hi, > While looking at the deployment codes, I was tired of packing/unpacking > the application package, actually, what we do is just to add some Geronimo > specific configuration files, updating some configuration files. > IIRC, in one deployment process, we need to > a. copy the jar file to a temp folder > b. extract the zip file > c. package the directory for the application analysis > d. repackage the directory for the final installation. > > How about using the TrueZip, it is a ASL 2.0 opensource project, and seems > it supports updating the zip file virtually, even the nested zip file. > Project URL : https://truezip.dev.java.net/ > > Any comment ? thanks. > -- > Ivan > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Shared bundle repository
Yeah, I wasn't suggesting a subproject of SMX or Geronimo. I think there are other projects like Ace, Sling, Aries that could contribute to that too. So definitely a common ground would be a good idea. I'm not sure if the board would approve a project solely for releasing third party libraries though ... On Tue, Jul 13, 2010 at 12:28 PM, Adrian Trenaman wrote: > Hi Guillaume, > > I think a shared repository for OSGi bundles at Apache would be great; far > better to have one well-known place with lots of activity around it rather > than have multiple repositories each being only partly maintained in an > ad-hoc manner. > > Rather than have this as a sub-project of either SMX or Geronimo, why not > create a new Apache project for this? > > Best, > Ade. > > > ________ > From: Guillaume Nodet [gno...@gmail.com] > Sent: 13 July 2010 11:05 > To: dev; dev > Subject: Shared bundle repository > > I guess we're not the only projects at Apache doing that, but at least > we do it the same way. > I wonder if we could cooperate more closely and have a common ground > for releasing such bundles and making them available to others. > I think having a single point to find OSGi bundles would be a great > benefit for all OSGi-fied projects at Apache and also for the > downstream users. > > Thoughts ? > > Btw, I'm just starting this thread because I've seen Rick is in the > process of releasing some bundles in Geronimo ... > > -- > Cheers, > Guillaume Nodet > ---- > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Shared bundle repository
I guess we're not the only projects at Apache doing that, but at least we do it the same way. I wonder if we could cooperate more closely and have a common ground for releasing such bundles and making them available to others. I think having a single point to find OSGi bundles would be a great benefit for all OSGi-fied projects at Apache and also for the downstream users. Thoughts ? Btw, I'm just starting this thread because I've seen Rick is in the process of releasing some bundles in Geronimo ... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Runtime entity enhancement for OSGi applications
It does not look like the patch has been applied. You'd have to comment on it and push for a solution if you want it to be included somehow. On Wed, May 19, 2010 at 23:34, Jarek Gawor wrote: > Btw, I was referring to > https://issues.apache.org/jira/browse/FELIX-2197. I thought parts of > the patch were applied to Felix but I guess I was wrong. > > Jarek > > On Wed, May 19, 2010 at 5:15 PM, Guillaume Nodet wrote: >> FWIW, I would think #3 is a good option, but I don't think Felix has >> anything to support that (but I may be wrong). >> >> On Wed, May 19, 2010 at 04:41, Jarek Gawor 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 >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Runtime entity enhancement for OSGi applications
FWIW, I would think #3 is a good option, but I don't think Felix has anything to support that (but I may be wrong). On Wed, May 19, 2010 at 04:41, Jarek Gawor 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 > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release XBean 3.7 - second attempt
+1 On Fri, May 14, 2010 at 16:36, Rick McGuire wrote: > Please vote for the geronimo xbean 3.7 release > > The major changes to this release are: > - xbean-blueprint subproject to provide support for Aries blueprint > component assembly > - xbean-bundleutils subproject to provide useful common utilities for > dealing with OSGi bundles. > > Differences from the 1st attempt: > > 1) KEYS file has been deleted > 2) copyright date in NOTICE file has been updated > 3) test properties files have had ASL license headers added. > > The xbean-finder-shaded license issue that Kevan raised turned out to not > be an issue, so no changes were required for that. > > > Staging repo is here: > > https://repository.apache.org/content/repositories/orgapachegeronimo-031/ > > tag is here: > > https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 > > Vote open 72 hours > > [ ] +1 release this > [ ] 0 don't care > [ ] -1 don't release this (please explain) > > Rick > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: OSGi version for Geronimo packages
Keep in mind that in osgi, 3.0.0.m1 > 3.0.0 !!! On Thu, May 6, 2010 at 15:24, Lin Sun 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 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: error starting the karaf shell when starting the server or deploy script
I've recently upgraded karaf to sshd 0.4.0-snaphot, so that may be the reason. On Wed, May 5, 2010 at 23:36, Joe Bohn wrote: > After recently updating and building Geronimo to rev. 941434 I'm seeing an > error starting the tomcat javaee6 assembly or the deploy script: > > Using JRE_HOME: > /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home > Artifact org/apache/sshd/sshd-core/0.3.0/sshd-core-0.3.0.jar not found > ERROR: Error starting > mvn:org.apache.felix.karaf.shell/org.apache.felix.karaf.shell.ssh/1.5.0-SNAPSHOT > (org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.felix.karaf.shell.ssh [47]: package; > (&(package=org.apache.sshd.common)(version>=0.4.0)(!(version>=1.0.0 > org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.felix.karaf.shell.ssh [47]: package; > (&(package=org.apache.sshd.common)(version>=0.4.0)(!(version>=1.0.0))) >at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3299) >at org.apache.felix.framework.Felix.startBundle(Felix.java:1657) >at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1128) >at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) >at java.lang.Thread.run(Thread.java:637) > > Aside from the error things seem to be mostly working. > > Joe > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Apache ActiveMQ 5.3.2
+1 On Tue, Apr 27, 2010 at 01:04, David Jencks wrote: > Hi, > > I've staged a release candidate for ActiveMQ 5.3.2. The main driver for > this is to get the osgi version range fixes into a release usable by the > upcoming geronimo 3.0 milestone. > > The changes since the recent 5.3.1: > > merging 881433 - jaxb plugin problem > changing activemq.version to match project version > AMQ-2501 Modify version range for camel imports > AMQ-2637 port osgi version range fixes from trunk > AMQ-2700 - code disclosure vunl > AMQ-2675 - web console topic form > > The staging repo is here: > > https://repository.apache.org/content/repositories/orgapacheactivemq-022/ > > The svn tag is here: > > https://svn.apache.org/repos/asf/activemq/tags/activemq-parent-5.3.2 > > This seems to be a different name format than the other tags. If people > want me to redo the release to fix this I will probably want to update the > build a little more such as using apache 7 parent pom and making the release > plugin defaults work. > > Please vote > > +1 Promote staging repo as amq 5.3.2 > -1 Drop staging repo and tag, try again (please provide specific comments) > > Many thanks > > david jencks > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Are the specs ready to go up for a release vote?
I'll update the specs wrt imported packages and version policy. Do you have a list of the specs that you intend to release ? On Mon, Apr 12, 2010 at 21:07, Guillaume Nodet wrote: > I also think all the osgi imported packages should have a version range up > to the next major version. Currently, those are defined as unbounded range > up to infinity is problematic if we have in the future a new incompatible > major version. > > Also, I wonder if the org.apache.geronimo.osgi.registry.api package is > really optional ? Will the specs still be usable if this package is not > present at all ? > > > On Mon, Apr 12, 2010 at 20:46, Guillaume Nodet wrote: > >> Have the specs jars been tested in both a non osgi environment and an osgi >> environment ? >> Also, i'd like to have the scripting api and rest api osgi-fied the same >> way. We'd need them in servicemix, and given you have rewritten the specs >> to support osgi, i don't see the need to maintain the servicemix ones >> anymore. >> Also, I think there is an unresolved JIRA issue (GERONIMO-3960) about the >> imported packages (they should not import their own packages). >> >> >> On Mon, Apr 12, 2010 at 19:30, Rick McGuire wrote: >> >>> If we wish to release a milestone soon, we need to start getting the >>> different subcomponents released fairly quickly. Here are the things I >>> believe we need to have release votes on: >>> >>> 1) New spec components. These need to be done first, and should >>> probably done as a single vote rather than trying to schedule a vote for >>> each of the jars. >>> 2) New javamail jar (should probably done concurrently with the javamail >>> spec). >>> 3) New xmlbeans schema jar releases (java ee 1.4, java ee 5, and java ee >>> 6 versions) >>> 4) New components jars >>> 5) New yoko jars >>> 6) New tomcat ext jars >>> >>> For 1), I think these are ready to go. I believe the issue of the >>> package exports has been resolved as far as it can be for the 3.1 M1 >>> release. The jpa and servlet specs will be exporting dual version levels >>> because the need to line up with different implementations that are not >>> conforming to the OSGi specs yet. This seems like a workable solution, at >>> least for the short term. I believe all of our specs are currently passing >>> the signature tests, so they look clean there. If I don't hear any >>> objections, I'll start staging these for release tomorrow morning. >>> >>> The one spec there might be a concern about is the ccpp spec jar. This >>> is used in the pluto support currently, but we don't currently have a TCK to >>> validate this one. I need some opinions on how to proceed with that jar. >>> For now, I'll not be submitting this one for a vote with the rest of the >>> specs. >>> >>> What state are the rest of these in? I suspect yoko is not stable enough >>> currently since David Jencks is currently working on getting the Corba >>> support working. We might want to delay the tomcat external release as long >>> as we can in case we require some patches. "As long as we can" is probably >>> not more than a week. The xmlbeans schema jars are probably pretty stable >>> and capable of being released now. >>> >>> Are the components in any shape that release votes can be started? Here >>> are the components we need to release: >>> >>> - geronimo-connector >>> - geronmo-transaction >>> - geronimo-jaspi >>> >>> This will need to be handled fairly soon too. >>> >>> Rick >>> >>> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> >> >> > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Are the specs ready to go up for a release vote?
I also think all the osgi imported packages should have a version range up to the next major version. Currently, those are defined as unbounded range up to infinity is problematic if we have in the future a new incompatible major version. Also, I wonder if the org.apache.geronimo.osgi.registry.api package is really optional ? Will the specs still be usable if this package is not present at all ? On Mon, Apr 12, 2010 at 20:46, Guillaume Nodet wrote: > Have the specs jars been tested in both a non osgi environment and an osgi > environment ? > Also, i'd like to have the scripting api and rest api osgi-fied the same > way. We'd need them in servicemix, and given you have rewritten the specs > to support osgi, i don't see the need to maintain the servicemix ones > anymore. > Also, I think there is an unresolved JIRA issue (GERONIMO-3960) about the > imported packages (they should not import their own packages). > > > On Mon, Apr 12, 2010 at 19:30, Rick McGuire wrote: > >> If we wish to release a milestone soon, we need to start getting the >> different subcomponents released fairly quickly. Here are the things I >> believe we need to have release votes on: >> >> 1) New spec components. These need to be done first, and should probably >> done as a single vote rather than trying to schedule a vote for each of the >> jars. >> 2) New javamail jar (should probably done concurrently with the javamail >> spec). >> 3) New xmlbeans schema jar releases (java ee 1.4, java ee 5, and java ee >> 6 versions) >> 4) New components jars >> 5) New yoko jars >> 6) New tomcat ext jars >> >> For 1), I think these are ready to go. I believe the issue of the package >> exports has been resolved as far as it can be for the 3.1 M1 release. The >> jpa and servlet specs will be exporting dual version levels because the need >> to line up with different implementations that are not conforming to the >> OSGi specs yet. This seems like a workable solution, at least for the short >> term. I believe all of our specs are currently passing the signature tests, >> so they look clean there. If I don't hear any objections, I'll start >> staging these for release tomorrow morning. >> >> The one spec there might be a concern about is the ccpp spec jar. This is >> used in the pluto support currently, but we don't currently have a TCK to >> validate this one. I need some opinions on how to proceed with that jar. >> For now, I'll not be submitting this one for a vote with the rest of the >> specs. >> >> What state are the rest of these in? I suspect yoko is not stable enough >> currently since David Jencks is currently working on getting the Corba >> support working. We might want to delay the tomcat external release as long >> as we can in case we require some patches. "As long as we can" is probably >> not more than a week. The xmlbeans schema jars are probably pretty stable >> and capable of being released now. >> >> Are the components in any shape that release votes can be started? Here >> are the components we need to release: >> >> - geronimo-connector >> - geronmo-transaction >> - geronimo-jaspi >> >> This will need to be handled fairly soon too. >> >> Rick >> >> > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Are the specs ready to go up for a release vote?
Have the specs jars been tested in both a non osgi environment and an osgi environment ? Also, i'd like to have the scripting api and rest api osgi-fied the same way. We'd need them in servicemix, and given you have rewritten the specs to support osgi, i don't see the need to maintain the servicemix ones anymore. Also, I think there is an unresolved JIRA issue (GERONIMO-3960) about the imported packages (they should not import their own packages). On Mon, Apr 12, 2010 at 19:30, Rick McGuire wrote: > If we wish to release a milestone soon, we need to start getting the > different subcomponents released fairly quickly. Here are the things I > believe we need to have release votes on: > > 1) New spec components. These need to be done first, and should probably > done as a single vote rather than trying to schedule a vote for each of the > jars. > 2) New javamail jar (should probably done concurrently with the javamail > spec). > 3) New xmlbeans schema jar releases (java ee 1.4, java ee 5, and java ee 6 > versions) > 4) New components jars > 5) New yoko jars > 6) New tomcat ext jars > > For 1), I think these are ready to go. I believe the issue of the package > exports has been resolved as far as it can be for the 3.1 M1 release. The > jpa and servlet specs will be exporting dual version levels because the need > to line up with different implementations that are not conforming to the > OSGi specs yet. This seems like a workable solution, at least for the short > term. I believe all of our specs are currently passing the signature tests, > so they look clean there. If I don't hear any objections, I'll start > staging these for release tomorrow morning. > > The one spec there might be a concern about is the ccpp spec jar. This is > used in the pluto support currently, but we don't currently have a TCK to > validate this one. I need some opinions on how to proceed with that jar. > For now, I'll not be submitting this one for a vote with the rest of the > specs. > > What state are the rest of these in? I suspect yoko is not stable enough > currently since David Jencks is currently working on getting the Corba > support working. We might want to delay the tomcat external release as long > as we can in case we require some patches. "As long as we can" is probably > not more than a week. The xmlbeans schema jars are probably pretty stable > and capable of being released now. > > Are the components in any shape that release votes can be started? Here > are the components we need to release: > > - geronimo-connector > - geronmo-transaction > - geronimo-jaspi > > This will need to be handled fairly soon too. > > Rick > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: converting optional imports to dynamic imports
I think we should use both. This way, the package would be wired on the initial resolution if available. And we need to make sure the exact same constraints are used for optional and dynamic imports (including version range, etc...). On Fri, Apr 9, 2010 at 05:42, Jarek Gawor wrote: > Hi all, > > I'm beginning to think that we should convert any optional imports in > our spec jars to dynamic imports. The issue is that the optional > imports are resolved when the bundle is resolved. So if the exporting > bundle is not there at the time the importing bundle is resolved the > optional imports are not wired. And the imports stay unwired even if > the exporting bundle is installed later on. With dynamic imports the > exporting bundle could be installed before or after the importing > bundle is resolved. > > Take the management spec as an example. The management spec has an > optional dependency on ejb spec. So for everything to resolve ok, I > need to install ejb spec, jaxrpc spec, and serlvet spec (ejb needs > jaxprc and jaxrpc needs servlet). With the dynamic imports we could > install the management spec without the ejb spec. And once/if the ejb > spec would be installed, the mejb part of the management spec would > work just fine (without bundle refreshes or restarts). > > Jarek > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: osgi core/compendium from felix or osgi?
FWIW, Felix has switched to using the OSGi ones and does not maintain its own versions of core / compendium anymore. On Wed, Mar 10, 2010 at 03:56, Lin Sun wrote: > 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 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 >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: svn commit: r915135 - /geronimo/server/trunk/framework/configs/karaf-framework/src/main/filtered-resources/etc/startup.properties
I suppose that's because I pushed a new snapshot of OBR.
At the moment, it does not ship the org.osgi.service.obr package anymore.
On Mon, Mar 1, 2010 at 13:30, Rick McGuire wrote:
> David,
>
> I'm getting build errors this morning that I suspect is caused by this
> update:
>
> C:\g-3.0\framework\modules\geronimo-system\src\main\java\org\apache\geronimo\sys
> tem\configuration\DependencyManager.java:[51,27] package
> org.osgi.service.obr do
> es not exist
>
> C:\g-3.0\framework\modules\geronimo-system\src\main\java\org\apache\geronimo\sys
> tem\configuration\DependencyManager.java:[65,18] cannot find symbol
> symbol : class RepositoryAdmin
> location: class org.apache.geronimo.system.configuration.DependencyManager
>
> C:\g-3.0\framework\modules\geronimo-system\src\main\java\org\apache\geronimo\sys
> tem\configuration\DependencyManager.java:[75,65] cannot find symbol
> symbol : class RepositoryAdmin
> location: class org.apache.geronimo.system.configuration.DependencyManager
>
> C:\g-3.0\framework\modules\geronimo-system\src\main\java\org\apache\geronimo\sys
> tem\configuration\DependencyManager.java:[76,46] cannot find symbol
> symbol : class RepositoryAdmin
> location: class org.apache.geronimo.system.configuration.DependencyManager
>
> I tried added a dependency to the org.osgi.service.obr bundle in
> geronimo-system, but that didn't appear to fix the problem. I'm not sure I
> understand what's going wrong with the dependencies here.
>
> Rick
>
> On 2/22/2010 9:10 PM, djen...@apache.org wrote:
>>
>> Author: djencks
>> Date: Tue Feb 23 02:10:02 2010
>> New Revision: 915135
>>
>> URL: http://svn.apache.org/viewvc?rev=915135&view=rev
>> Log:
>> remove duplicates
>>
>> Modified:
>>
>> geronimo/server/trunk/framework/configs/karaf-framework/src/main/filtered-resources/etc/startup.properties
>>
>> Modified:
>> geronimo/server/trunk/framework/configs/karaf-framework/src/main/filtered-resources/etc/startup.properties
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/framework/configs/karaf-framework/src/main/filtered-resources/etc/startup.properties?rev=915135&r1=915134&r2=915135&view=diff
>>
>> ==
>> ---
>> geronimo/server/trunk/framework/configs/karaf-framework/src/main/filtered-resources/etc/startup.properties
>> (original)
>> +++
>> geronimo/server/trunk/framework/configs/karaf-framework/src/main/filtered-resources/etc/startup.properties
>> Tue Feb 23 02:10:02 2010
>> @@ -93,8 +93,6 @@
>>
>> org/apache/geronimo/framework/geronimo-kernel/${pom.version}/geronimo-kernel-${pom.version}.jar=40
>>
>> org/apache/geronimo/framework/geronimo-transformer/${pom.version}/geronimo-transformer-${pom.version}.jar=40
>>
>> org/apache/geronimo/framework/geronimo-system/${pom.version}/geronimo-system-${pom.version}.jar=40
>>
>> -org/apache/felix/org.osgi.service.obr/1.0.2/org.osgi.service.obr-1.0.2.jar=40
>>
>> -org/apache/felix/org.apache.felix.bundlerepository/1.5.0-SNAPSHOT/org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar=40
>>
>>
>> org/apache/servicemix/bundles/org.apache.servicemix.bundles.ant/1.7.0_1/org.apache.servicemix.bundles.ant-1.7.0_1.jar=40
>>
>> org/apache/geronimo/framework/geronimo-plugin/${pom.version}/geronimo-plugin-${pom.version}.jar=40
>>
>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Adding OSGi support to Geronimo spec jars.
d implementers of a given interface. The service mix > lookups were being used to directly resolve implementation classes. To do > this, the service definition file would need to use the same class as both > interface name and implementer class. This has a nice side effect of > allowing particular implementations to be selectively replaced, but this is > a usage that could cause problems if the information was picked up by either > spifly or ServiceLoader. This violated the fundamental assumption that this > information defined interface-to-implementation mappings. > > In addition, the javamail changes were using this information to define > protocol-to-provider mappings. For example, an "smtp" javamail provider > implementation class. In this case, the mapping did not even start with the > name of a Java class. This definitely conflicted with both spifly and > ServiceLoader. > > A lot of these difficulties go away if I decouple the Servicemix semantics > by moving the information to a different location so that we're not seeing > multiple interpretations of what the data in META-INF/services means. The > code I'm working on will be looking in OSGI-INF/providers, and the mapping > information is defined in terms of a provider identifier-to-provider class > mapping. This is really is the interpretation used by the Servicemix code, > but removes the conflicting usage. > > Rick > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Adding servicemix improvements to the geronimo spec bundles.
My original intent was to put all the servicemix code directly in the geronimo spec project, but at that time, there has been a push back to avoid mixing the plain apis with some osgi concerns. I don't have much problems in moving this code back to geronimo or aries or anywhere else personally, or improving it (there are lots of things that could be improved). The only thing i'd like to avoid is to have 3 pieces of code doing similar things On Tue, Feb 9, 2010 at 15:36, Rick McGuire wrote: > The bundle version of the some of the geronimo spec jars have some issues > when used in an OSGi environment with locating resources in the META-INF > directories of other bundles. The servicemix project has solved this by > repackaging the geronimo versions with the addition of a bundle Activator > that watches for new bundles to be started and checks these new bundles for > resources of interest, processing them at start time. > > This appears to work well for servicemix, and now that we're converting > using these jars as bundles in Geronimo 3.0, we're going to be running into > the same issues. This Jira issue has been opened to address the problem and > attempt to merge what service mix has done back into the base Geronio > projects: https://issues.apache.org/jira/browse/GERONIMO-5133 > > I've started looking at doing this, beginning with the activation spec, > which should be one of the simpler ones to deal with. I immediately ran > into a couple of issues I'd like some feedback on. > > 1) The servicemix project has core support project with some base classes > that get copied into each bundlized jar file. The copying is not really an > issue, but where is the appropriate place in the svn tree to host this. > It's not really spec jar directly, but does end up contributing to a number > of spec jars. I think it probably belongs in the spec tree, but I'd like > some consensus before I create a new project there. > > 2) Servicemix does a lot of what it does by adding a subclass of one or > more spec classes to the package. In some (most?) cases, this subclass > cannot accomplish what it needs using the classes as implemented in the > Geronimo version because of method/class access qualifiers. For example, in > the activation bundle, Servicemix replaces the MailcapCommandMap class with > one where two private methods have been made protected. Then it adds an > additional OsgiMailcapCommandMap class to implement the additional > processing required when this jar is loaded as a bundle. > > This modification to the MailcapCommandMap class will cause TCK problems > because the additional protected methods will cause sigtest failures. > Package scope for these methods would allow these to pass the sig tests, > but this would require that the activator class and the subclass be package > scope classes in the javax.activation package rather than segregated in a > separate org.apache.geronimo.* package. So, using this, the modification > would be > > - The base MailcapCommandMap class has two methods changed from private > scope to package scope. > - Two additional classes, javax.activation.Activator and > javax.activation.OsgiMailcapCommandMap are added to the bundle. These > classes will be defined with package scope so that they don't trigger > sigtest failures. > > This is probably the simplest working solution I see. A more complicated > solution would be to refactor a lot of the code from the MailcapCommandMap > class into a separate worker class in an implementation-specific package > that can be shared between the two versions, but I'm not sure there's much > to be gained from making that big of a change. > > Rick > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Blueprint MBean progress
amespace. Currently we used >> "org.apache.geronimo.blueprint.jmx" as the package name, but I don't know if >> there is any concern on it. And we also borrow the Item class and >> JmxConstants class from the rfc 139 api. That may not be applicable because >> they won't be exported by the 139 api bundle. So we have to create them by >> ourselves. Temporarily, you have to check out >> https://svn.apache.org/repos/asf/geronimo/sandbox/rex/M2_REPO to help pass >> the compilation. >> >> Ok, that is a brief introduction on what a BlueprintMBean is. Particularly, >> thanks Siqi for his help, and any suggestion is appreciated! >> >> -Rex >> >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Blueprint MBean progress
of the above methods, we define 5 >> > CompositeTypes accordingly, i.e. BEAN_METADATA_TYPE, >> > SERVICE_MATADATA_TYPE, >> > REFERENCE_METADATA_TYPE, REFERENCE_LIST_METADATA_TYPE, >> > BLUEPRINT_EVENT_TYPE. >> > What's more, to simplify the data structure, we pull out the >> > ARGUMENT_TYPE >> > and PROPERTY_TYPE from the BEAN_METADATA_TYPE, and define two >> > independent >> > methods for them. The other composite types, such as >> > COMPONENT_METADATA_TYPE >> > and SERVICE_REFERENCE_METADATA_TYPE are just intermediate material to >> > create >> > Bean, service, reference, and reference-list types. >> > >> > The problem is the values. From the bluepirnt spec, the values can >> > appear in >> > 4 places, that is, BeanArgument, BeanProperty, CollectionMetadata, >> > MapEntry. >> > That means there should be an item named "VALUE" in the 4 >> > compositeTypes. >> > But the value type is uncertain. A value can be one of 7 value >> > types(, , , , Collectoins, , ) + 4 >> > manager types(, , , ). So we >> > have >> > to create a placeholder type to represent such value item. Hence, if a >> > user >> > get a compositeData and one of its item has a placeholder type, he need >> > to >> > iterate all the 11 types to confirm what is the exact one. That is why >> > the >> > GENERIC_METADATA_TYPE exists. I am not very comfortable on this, but >> > seems >> > that is the only acceptable solution. (btw, we haven't finished the >> > coding >> > on the 7 value compositeTypes.) >> > >> > Another problem is the namespace. Currently we used >> > "org.apache.geronimo.blueprint.jmx" as the package name, but I don't >> > know if >> > there is any concern on it. And we also borrow the Item class and >> > JmxConstants class from the rfc 139 api. That may not be applicable >> > because >> > they won't be exported by the 139 api bundle. So we have to create them >> > by >> > ourselves. Temporarily, you have to check out >> > https://svn.apache.org/repos/asf/geronimo/sandbox/rex/M2_REPO to help >> > pass >> > the compilation. >> > >> > Ok, that is a brief introduction on what a BlueprintMBean is. >> > Particularly, >> > thanks Siqi for his help, and any suggestion is appreciated! >> > >> > -Rex >> > >> > >> > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Mbeans for Blueprint
I think those are two separate concerns. What we were discussion is to expose one mbean for the blueprint extender that would allow monitoring the state of the extender and various blueprint bundles. I think what you are proposing is to allow a user to expose beans over JMX. I do agree that this is worthwhile, but that's a totally different discussion imho. On Fri, Oct 30, 2009 at 15:50, Jarek Gawor wrote: > I agree that we should leverage open mbeans for this as much as we > can. Also, I was wondering if we should consider creating namespace > handler that could directly expose individual beans within the > blueprint container as mbeans. But maybe exposing a bean as a service > (and therefore as a mbean) is good enough. > > Jarek > > On Fri, Oct 30, 2009 at 1:54 AM, Rex Wang wrote: >> This topic might be a little bit independent from what we are doing in >> current osgi integration work. However, I would like to raise such >> discussion because I believe blueprint will act as an important role in our >> future framework. So, if we wanna leverage blueprint as a common way to >> construct geronimo plugins and hope use JMX for remote management, we >> definitely need a set of mbeans to track the blueprint bundles. Currently, I >> am working on this work item. >> >> OSGi Alliance is planing to release an enterprise spec which contains rfc >> 139(mbeans for core framework and 3 compendium services), but there is no >> mbeans for blueprint. So I think our jobs go ahead of the standard. We did a >> quick look on karaf and spring dm, and did not found them using mbeans to >> track and manage the state of blueprint. I hope the works we are doing are >> helpful as a complement of rfc 139. >> >> OK, although RFC139 says it is not to provide a generic mechanism that be >> used to expose management of arbitrary OSGi services through JMX, we still >> deside to keep our design consistent with it. That is to leverage the >> openmbean's open type in the data structure of mbeans' return value, such as >> compositeType, tabularType.. And there is not too much APIs exposed by >> blueprint, so I think only one Mbean is enough right now. >> >> A problem is that how we track the status. In the rfc124 spec, blueprint >> bundle's status can be identified by listening the events that pre-defined. >> The blueprint extender sends those events to the Event Admin service, but in >> RFC 139 there is no mbeans designed to manage the event admin. So looks like >> we need a mbean provides the APIs to track bluepirnt application and its >> implementation must also implement the BlueprintListener interface. That is >> what we are thinking currently. >> >> Is anybody insteresting on this topic or do you know anythings behind the >> scenes from Karaf/Springsource that say why they seems not plan to design >> such mbeans? >> Any comments is appreciated. >> >> Regards >> -Rex >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Mbeans for Blueprint
I would think each blueprint bundle managed by this extender would be an entry in the tabular data and contain several informations, including the state and last event(s), so that the error would be available (or maybe it should be available directly). On Fri, Oct 30, 2009 at 10:41, Rick McGuire wrote: > Rex Wang wrote: >> >> >> 2009/10/30 Guillaume Nodet mailto:gno...@gmail.com>> >> >> There are discussions about implementing rfc 139 inside the Aries >> podling, so maybe it would make sense to discuss that in this context >> too. >> >> >From a Karaf pov, I think it would really make sense to add such an >> mbean. Do you see a single mbean for the extender that would allow >> accessing the BlueprintContext through a tabular data or do you see >> one mbean per BLueprintContext ? I would lean toward the first >> solution so keep the coarse grained behavior of rfc 139. >> >> Yes, I am suggesting the first approach. > > I think it would also be very valuable to be able to retrieve any blueprint > deployment failures so that > errors can be diagnosed. > Rick >> >> -Rex >> >> On Fri, Oct 30, 2009 at 06:54, Rex Wang > <mailto:rwo...@gmail.com>> wrote: >> > This topic might be a little bit independent from what we are >> doing in >> > current osgi integration work. However, I would like to raise such >> > discussion because I believe blueprint will act as an important >> role in our >> > future framework. So, if we wanna leverage blueprint as a common >> way to >> > construct geronimo plugins and hope use JMX for remote >> management, we >> > definitely need a set of mbeans to track the blueprint bundles. >> Currently, I >> > am working on this work item. >> > >> > OSGi Alliance is planing to release an enterprise spec which >> contains rfc >> > 139(mbeans for core framework and 3 compendium services), but >> there is no >> > mbeans for blueprint. So I think our jobs go ahead of the >> standard. We did a >> > quick look on karaf and spring dm, and did not found them using >> mbeans to >> > track and manage the state of blueprint. I hope the works we are >> doing are >> > helpful as a complement of rfc 139. >> > >> > OK, although RFC139 says it is not to provide a generic >> mechanism that be >> > used to expose management of arbitrary OSGi services through >> JMX, we still >> > deside to keep our design consistent with it. That is to >> leverage the >> > openmbean's open type in the data structure of mbeans' return >> value, such as >> > compositeType, tabularType.. And there is not too much APIs >> exposed by >> > blueprint, so I think only one Mbean is enough right now. >> > >> > A problem is that how we track the status. In the rfc124 spec, >> blueprint >> > bundle's status can be identified by listening the events that >> pre-defined. >> > The blueprint extender sends those events to the Event Admin >> service, but in >> > RFC 139 there is no mbeans designed to manage the event admin. >> So looks like >> > we need a mbean provides the APIs to track bluepirnt application >> and its >> > implementation must also implement the BlueprintListener >> interface. That is >> > what we are thinking currently. >> > >> > Is anybody insteresting on this topic or do you know anythings >> behind the >> > scenes from Karaf/Springsource that say why they seems not plan >> to design >> > such mbeans? >> > Any comments is appreciated. >> > >> > Regards >> > -Rex >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> >> > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Mbeans for Blueprint
There are discussions about implementing rfc 139 inside the Aries podling, so maybe it would make sense to discuss that in this context too. >From a Karaf pov, I think it would really make sense to add such an mbean. Do you see a single mbean for the extender that would allow accessing the BlueprintContext through a tabular data or do you see one mbean per BLueprintContext ? I would lean toward the first solution so keep the coarse grained behavior of rfc 139. On Fri, Oct 30, 2009 at 06:54, Rex Wang wrote: > This topic might be a little bit independent from what we are doing in > current osgi integration work. However, I would like to raise such > discussion because I believe blueprint will act as an important role in our > future framework. So, if we wanna leverage blueprint as a common way to > construct geronimo plugins and hope use JMX for remote management, we > definitely need a set of mbeans to track the blueprint bundles. Currently, I > am working on this work item. > > OSGi Alliance is planing to release an enterprise spec which contains rfc > 139(mbeans for core framework and 3 compendium services), but there is no > mbeans for blueprint. So I think our jobs go ahead of the standard. We did a > quick look on karaf and spring dm, and did not found them using mbeans to > track and manage the state of blueprint. I hope the works we are doing are > helpful as a complement of rfc 139. > > OK, although RFC139 says it is not to provide a generic mechanism that be > used to expose management of arbitrary OSGi services through JMX, we still > deside to keep our design consistent with it. That is to leverage the > openmbean's open type in the data structure of mbeans' return value, such as > compositeType, tabularType.. And there is not too much APIs exposed by > blueprint, so I think only one Mbean is enough right now. > > A problem is that how we track the status. In the rfc124 spec, blueprint > bundle's status can be identified by listening the events that pre-defined. > The blueprint extender sends those events to the Event Admin service, but in > RFC 139 there is no mbeans designed to manage the event admin. So looks like > we need a mbean provides the APIs to track bluepirnt application and its > implementation must also implement the BlueprintListener interface. That is > what we are thinking currently. > > Is anybody insteresting on this topic or do you know anythings behind the > scenes from Karaf/Springsource that say why they seems not plan to design > such mbeans? > Any comments is appreciated. > > Regards > -Rex > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Geronimo 3.0 build problem caused by a Karaf change?
Those artifacts are available in the following private maven repo: http://svn.apache.org/repos/asf/servicemix/m2-repo/org/eclipse/osgi/3.5.1.v20090827/ which is referenced in the karaf parent pom, so it should be available from maven, but given you use the car maven plugin, that may be the cause for not finding this artifact. Can you try adding this repository in one of your parent pom maybe ? On Thu, Oct 29, 2009 at 13:11, Rick McGuire wrote: > Guillaume, > > It looks like the Geronimo build has been messed up by a recent Karaf > change. Do you have any suggestions on what needs updating this time? > > Rick > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) org.eclipse:osgi:jar:3.5.1.v20090827 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=org.eclipse -DartifactId=osgi > -Dversion > =3.5.1.v20090827 -Dpackaging=jar -Dfile=/path/to/file > > Alternatively, if you host your own repository you can deploy the file > there: > > mvn deploy:deploy-file -DgroupId=org.eclipse -DartifactId=osgi > -Dversion=3 > .5.1.v20090827 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] > -DrepositoryId=[ > id] > > Path to dependency: > 1) > org.apache.geronimo.plugins:geronimo-connector-server:server-assembly > :3.0-SNAPSHOT > 2) > org.apache.geronimo.framework.plugingroups:framework:car:3.0-SNAPSHOT > > 3) org.apache.geronimo.framework:karaf-framework:car:3.0-SNAPSHOT > 4) org.eclipse:osgi:jar:3.5.1.v20090827 > > -- > 1 required artifact is missing. > > for artifact: > org.apache.geronimo.plugins:geronimo-connector-server:server-assembly:3.0-SNAP > SHOT > > from the specified remote repositories: > apache.snapshots (http://repository.apache.org/snapshots), > codehaus.snapshots (http://snapshots.repository.codehaus.org), > repo.mergere.com (http://repo.mergere.com/maven2) > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
