Re: [VOTE] Apache XBean 4.22 release

[David Blevins]

+1


-David


> On Oct 10, 2022, at 2:23 AM, fpapon  wrote:
> 
> Hi everyone,
> 
> I submit Apache XBean 4.22 release to your vote.
> 
> This release includes:
> - ASM 9.4 update
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12352368
>   
> 
> 
> Staging Maven repository:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1157
> 
> 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
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Moving Mail, Activation, Transaction and Connector to Apache TomEE (was Re: [DISCUSS] Move microprofile impl to Apache TomEE)

[David Blevins]

> On Jun 14, 2022, at 10:09 PM, David Jencks  wrote:
> 
> I think each impl. needs to be in its own git repo, I’m not sure which 
> already are.

Agree.  Currently connector and txmanager are in the same git repo.

> I believe the tx manager is used in an OSGI spec impl in (I think) Aries. On 
> the other hand they might have copied the implementation.  It might be 
> confusing if the governing project and/or package names change. I don’t know 
> if there are other uses, or how to find out.
> 
> It might possibly be simpler, after we get each subproject into appropriate 
> git repos, to make people who want to work on these implementations geronimo 
> committers.

I don't know if it helps the conversation, but we need a different version 
that's incompatible to what Aries and ActiveMQ uses.We would be developing 
and implementing jakarta.* implementations they couldn't use.  For them to 
switch from javax to jakarta, they'd need to change all their dependencies 
anyway.

Really the question being asked is does anyone mind if we develop separate 
Jakarta versions of the APIs on the TomEE side?  It would be a little easier 
for us.


-David

>> On Jun 14, 2022, at 9:36 AM, Romain Manni-Bucau  
>> wrote:
>> 
>> No blocker from me (minor note being some are already on git so don't start 
>> back from svn ;))
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> 
>> 
>> Le mar. 14 juin 2022 à 18:29, David Blevins  a 
>> écrit :
>> Jumping off of this thread, is there any openness to discussing moving this 
>> code over to TomEE?
>> 
>>  - http://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/
>>  - 
>> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-activation_2.0_spec/
>>  - 
>> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jakartamail_2.1_spec/
>>  - 
>> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-mail_2.1_spec/
>> 
>> These are on the critical path for TomEE, being updated in Jakarta EE 10.  
>> We're not working on Jakarta EE 10 yet, but we'll hopefully be doing that by 
>> early next year.
>> 
>> It's a bit painful to send people over from the TomEE project to here and 
>> submit patches against SVN repos.  It would be great if we could have them 
>> in git and under the TomEE PMC if possible.
>> 
>> Thoughts?
>> 
>> 
>> -David
>> 
>> > On Jun 6, 2022, at 1:59 AM, fpapon  wrote:
>> > 
>> > Hi all,
>> > 
>> > I would like to start a thread to discuss about the future of the Apache 
>> > Geronimo Microprofile implementation:
>> > 
>> > https://geronimo.apache.org/microprofile/
>> > 
>> > As we can see, we don't have a lot of traction about the maintenance of 
>> > the implementation to be up-to-date with the Microprofile specification.
>> > 
>> > The J2EE Geronimo server is no longer exist and at Apache, the active EE 
>> > server seems to be Apache TomEE.
>> > 
>> > May be it could make more sense to move the Microprofile implementation to 
>> > the Apache TomEE umbrella.
>> > 
>> > WDYT?
>> > 
>> > regards,
>> > 
>> > -- 
>> > --
>> > François
>> > 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Mail 2.0.0-M1

[David Blevins]

I got the wrong version number in the subject, but these would be the links:

 - 
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-mail_2.1_spec-1.0.0-M1
 - 
https://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-mail_2.1_spec/1.0.0-M1/

-David


> On May 23, 2022, at 11:26 PM, Romain Manni-Bucau  
> wrote:
> 
> Side note: referencing tag+hash + dist (dev) area (only thing we vote 
> against) would be neat for future votes since we dont vote on a staging repo.
> 
> Anyway thanks for doing it, really great to see you back ;)
> 
> PS: dont forget jira and site updates, we missed it by the past and hurts way 
> later when we need to catch up.
> 
> Le lun. 23 mai 2022 à 18:15, David Blevins  a écrit :
> Vote passes with 6 +1s (4 binding)
> 
> As noted in the other vote I didn't propose a final as we haven't yet run the 
> full set of TCK tests for this library, specifically the signature tests.  In 
> particular, the signature tests verify all the classes and method signatures 
> match the expected set and there are no additions/changes, etc.  These are 
> separate from the com.sun.ts.tests.javamail tests.
> 
> In the past we would always ensure these tests before releasing.
> 
> 
> -David
> 
> 
> > On May 14, 2022, at 2:27 PM, David Blevins  wrote:
> > 
> > Hey All,
> > 
> > If I was thinking ahead I'd have put these both in the same staging repo 
> > and vote :)
> > 
> > Staging Maven repository:
> > 
> > - https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
> > 
> > The only change is conversion from javax to the jakarta namespace via 
> > contributor Richard Zowalla and a change from "javamail" to simply "mail"
> > 
> > 
> > Please vote to approve this release:
> > [ ] +1 Approve the release
> > [ ]  0 Abstain (please provide specific comments)
> > [ ] -1 Don't approve the release (please provide specific comments)
> > 
> > This vote will be open for at least 72 hours.
> > 
> > -David
> > 
> 



smime.p7s
Description: S/MIME cryptographic signature

Moving Mail, Activation, Transaction and Connector to Apache TomEE (was Re: [DISCUSS] Move microprofile impl to Apache TomEE)

[David Blevins]

Jumping off of this thread, is there any openness to discussing moving this 
code over to TomEE?

 - http://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/
 - 
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-activation_2.0_spec/
 - 
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jakartamail_2.1_spec/
 - http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-mail_2.1_spec/

These are on the critical path for TomEE, being updated in Jakarta EE 10.  
We're not working on Jakarta EE 10 yet, but we'll hopefully be doing that by 
early next year.

It's a bit painful to send people over from the TomEE project to here and 
submit patches against SVN repos.  It would be great if we could have them in 
git and under the TomEE PMC if possible.

Thoughts?


-David

> On Jun 6, 2022, at 1:59 AM, fpapon  wrote:
> 
> Hi all,
> 
> I would like to start a thread to discuss about the future of the Apache 
> Geronimo Microprofile implementation:
> 
> https://geronimo.apache.org/microprofile/
> 
> As we can see, we don't have a lot of traction about the maintenance of the 
> implementation to be up-to-date with the Microprofile specification.
> 
> The J2EE Geronimo server is no longer exist and at Apache, the active EE 
> server seems to be Apache TomEE.
> 
> May be it could make more sense to move the Microprofile implementation to 
> the Apache TomEE umbrella.
> 
> WDYT?
> 
> regards,
> 
> -- 
> --
> François
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] Move microprofile impl to Apache TomEE

[David Blevins]

> On Jun 14, 2022, at 2:44 AM, Thomas Andraschko  
> wrote:
> 
> yep, we probably dont have enough commiters to maintain it
> but instead of freezing, shouldnt we maybe think about how to make it more
> attractive and easier to get more contributors?
> we have sooo many contributors in PrimeFaces as the project structure is
> easier, everything in one repo, and so on
> 
> if you check how many repositories we have for MP implementations, API,
> homepage, ...
> 
> i always wondered about the whole EE projects and locations/structures in
> apache in general
> why is geronimo the place for specs in general?
> i always thought that combining some repos/projects in general would make
> contributions much more welcome and easier
> 
> Wouldnt it be much more self-evident if we would have something like
> https://github.com/apache/ee-specifications?
> Wouldnt it be much more easier and more inviting if we would have all
> microprofile impls in one repo? The time we even safe for all that release
> trains


> On Jun 14, 2022, at 2:44 AM, Thomas Andraschko  
> wrote:
> 
> i always wondered about the whole EE projects and locations/structures in
> apache in general
> why is geronimo the place for specs in general?
> i always thought that combining some repos/projects in general would make
> contributions much more welcome and easier
> 
> Wouldnt it be much more self-evident if we would have something like
> https://github.com/apache/ee-specifications?
> Wouldnt it be much more easier and more inviting if we would have all
> microprofile impls in one repo? The time we even safe for all that release
> trains

Large topic, but at one point in time Geronimo was the center of the universe 
for EE at Apache.  For example, the J2EE license agreement between Apache and 
Sun was managed by the then Geronimo PMC chair.  If another project had a TCK 
challenge, they needed to file a ticket in a JIRA project owned by the Geronimo 
PMC.  Geronimo people were heavily involved in bringing a lot of EE code into 
Apache during its strong years; OpenJPA, Yoko, OpenWebBeans, ActiveMQ, OpenEJB, 
CXF, etc.

Things that were generally too small to be their own top level projects stayed 
in Geronimo; transaction & connector implementation, specs, etc.

There was even a point in time were a project was being developed at Codehaus 
(GBean) that was perceived as only applicable to Geronimo and an attempt to 
undermine the project, so with board support those working on it were forced to 
move it into the Geronimo project to prove there was no attempts being made to 
undermine Geronimo.  OpenEJB and ActiveMQ were also moved from Codehaus to 
Apache to provide additional reassurance.  ActiveMQ and OpenEJB also started 
the XBean code in Geronimo to create a place to share random bits each project 
had in common and to further assure the Geronimo project.

There were several of us who felt the specs in particular might be better off 
in a common place, possibly Apache Commons, but that was against the tone at 
the time (see the above).

There was an attempt in the TomEE project to develop MicroProfile 
implementations that was met with some friction because that work wasn't being 
done in Geronimo.  I don't want to dig all that up again as it took several 
months to resolve.

The real trick is on the TomEE side of the fence we're switching to the 
SmallRye implementations.  This isn't because of where the code lives, but lack 
of resources to contribute to the Geronimo implementations and the significant 
amount of work getting them up to speed.

Maybe the best corse of action is to move them into the Apache Attic 
(https://attic.apache.org/)?  If TomEE or any Apache PMC decides they want them 
at some point in the future, that PMC could request the board to transfer the 
repos.

Thinking out loud.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[David Blevins]

> On May 24, 2022, at 6:14 PM, David Blevins  wrote:
> 
> You could have flags that enabled non-compliant behavior, but they would have 
> to be off by default and require user action to turn them on.

To be clear I could have used a better word than "flags."  You can have any 
means you like to enable non-compliant behavior such as annotations, alternate 
jars, etc.  Anything that must be done explicitly by a user to put themselves 
knowingly in a non-compliant state.


-David



smime.p7s
Description: S/MIME cryptographic signature

Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

[David Blevins]

Just wanted to echo what Jean-Louis said and add some details.

During the 20 years of these specs living in the JCP, the license requirements 
stated that you must agree to ship your implementation with all defaults set to 
the compliant state.  You could have flags that enabled non-compliant behavior, 
but they would have to be off by default and require user action to turn them 
on.

If we encounter a situation where we don't pass a test, here are the valid 
outcomes:

 1.  We decide to change our default behavior so we can pass the test.
 We may chose to create a way to enable the previous behavior, but
 we do not work that way by default.

 2.  We decide we think our behavior is spec-compliant and the TCK is
 testing something not defined by or against the spec.  We file a
 TCK challenge.

 A. Our challenge is approved.  We can ignore that failure and
still claim compliance.
 
 B. Our challenge is rejected.

i.  We execute option #1 and ship a compliant implementation.

ii. We decide we don't care about compliance.  Our users may
disagree and may need to patch or fork.


-David



> On May 24, 2022, at 5:12 PM, Jean-Louis MONTEIRO  wrote:
> 
> I always find it better when we can keep backward compatibility for users.
> But this is a major version and I'm not a big fan of cheap system properties.
> 
> If we think it's not good, we should create a challenge to get it fixed in 
> the spec + TCK.
> Otherwise, I would keep it the way it is. If it breaks users and we want to 
> help them out, it's still time to add the system property or a better 
> configuration option and do a maintenance release.
> 
> I'd go lazy instead of eager considering it's a major version.
> Meanwhile, I'd create an issue on the TCK + Spec
> 
> 
> Le mar. 24 mai 2022 à 13:21, Zowalla, Richard 
>  a écrit :
> Romain mentioned the idea (via Slack) of introducing a (cheap) system
> property, which a user can specifiy to get back the old behaviour. 
> 
> If we want to follow the compatibility appraoch, we should add that
> flag as the spec / RI is really unclear.
> 
> 
> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
> > I conclude the same thing thanks your pointers so back to the
> > question: do we want to maintain the compat for our user base, do we
> > want to align on the random spec behavior or do we don't care?
> > Indeed I'm always in first team, in particular there since it will be
> > deprecated so the least we touch the best it is but guess it is a 50-
> > 50 case in terms of actual points :s.
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > 
> > 
> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > The test in question is 
> > > https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
> > > 
> > > which expects the plain parameter value instead of
> > > "parameter=value" as
> > > a return value.
> > > 
> > > The JavaDoc is also not quite clear about it:
> > > 
> > > https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
> > > 
> > > with "This method is called for each parameter name/value pair and
> > > should return the normalized representation of the
> > > parameterValue.".
> > > 
> > > The spec document itself 
> > > https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
> > >  doesn't mention anything about it.
> > > 
> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
> > > there)
> > > to keep compatibility after removing the references to it.
> > > 
> > > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
> > > Bucau:
> > > > Hmm, before that the question is "are the TCK spec compliant", a
> > > lot
> > > > have a reference in the spec we maybe missed, do you have some
> > > > pointers on them? If we were wrong let's fix it, if the TCK are
> > > wrong
> > > > then maybe ignore the TCK?
> > > > 
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > > 
> > > > 
> > > > Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > There is a TCK test regarding normalizeMimeTypeParameter which
> > > > > broke with the current impl of normalizeMimeTypeParameter 
> > > > > 
> > > > > Therefore, I adjusted it but agree that it is mit really
> > > specified.
> > > > > Question would be, if it is "ok" to fail specific tests of the
> > > TCK.
> > > > > 
> > > > > Gruß
> > > > > Richard
> > > > > Von: Romain Manni-Bucau 
> > > > > Gesendet: Dienstag, 24. Mai 2022 11:53:37
> > > > > An: dev@geronimo.apache.org
> > > > > Betreff: Re: [VOTE] Geronimo activation_2.0_spec 

Re: [VOTE] Release Mail 2.0.0-M1

[David Blevins]

Vote passes with 6 +1s (4 binding)

As noted in the other vote I didn't propose a final as we haven't yet run the 
full set of TCK tests for this library, specifically the signature tests.  In 
particular, the signature tests verify all the classes and method signatures 
match the expected set and there are no additions/changes, etc.  These are 
separate from the com.sun.ts.tests.javamail tests.

In the past we would always ensure these tests before releasing.


-David


> On May 14, 2022, at 2:27 PM, David Blevins  wrote:
> 
> Hey All,
> 
> If I was thinking ahead I'd have put these both in the same staging repo and 
> vote :)
> 
> Staging Maven repository:
> 
> - https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
> 
> The only change is conversion from javax to the jakarta namespace via 
> contributor Richard Zowalla and a change from "javamail" to simply "mail"
> 
> 
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ]  0 Abstain (please provide specific comments)
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> -David
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Mail 2.0.0-M1

[David Blevins]

+1 (binding)


-David


> On May 14, 2022, at 2:27 PM, David Blevins  wrote:
> 
> Hey All,
> 
> If I was thinking ahead I'd have put these both in the same staging repo and 
> vote :)
> 
> Staging Maven repository:
> 
> - https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
> 
> The only change is conversion from javax to the jakarta namespace via 
> contributor Richard Zowalla and a change from "javamail" to simply "mail"
> 
> 
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ]  0 Abstain (please provide specific comments)
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> -David
> 



smime.p7s
Description: S/MIME cryptographic signature

[RESULT] Release Activation 2.0.0-M1

[David Blevins]

Vote passes with 6 +1s (4 binding)

As noted I didn't go for a final as we still haven't run the full set of TCK 
tests which include the signature tests.  If someone would like to do that or 
propose a final without doing that, they're welcome to do so.


-David


> On May 14, 2022, at 2:00 PM, David Blevins  wrote:
> 
> Hey All,
> 
> We're thinking to do a release on the TomEE side and this is one of the 
> snapshot dependencies we have.  I've prepped a 2.0.0-M1 with the idea that 
> being a milestone it should be fairly non-controversial to propose without a 
> heads up and I haven't checked the TCK status.  I know we're not yet actively 
> running the signature tests on the TomEE side.
> 
> I propose we release 2.0.0-M1 so we have some non-snapshots to work with and 
> come back to 2.0.0 as things look 100% on all fronts
> 
> Staging Maven repository:
> 
> - https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
> 
> The only change is conversion from javax to the jakarta namespace via 
> contributor Richard Zowalla.
> 
> 
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ]  0 Abstain (please provide specific comments)
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> -David
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Activation 2.0.0-M1

[David Blevins]

My +1


-David

> On May 14, 2022, at 2:00 PM, David Blevins  wrote:
> 
> Hey All,
> 
> We're thinking to do a release on the TomEE side and this is one of the 
> snapshot dependencies we have.  I've prepped a 2.0.0-M1 with the idea that 
> being a milestone it should be fairly non-controversial to propose without a 
> heads up and I haven't checked the TCK status.  I know we're not yet actively 
> running the signature tests on the TomEE side.
> 
> I propose we release 2.0.0-M1 so we have some non-snapshots to work with and 
> come back to 2.0.0 as things look 100% on all fronts
> 
> Staging Maven repository:
> 
> - https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
> 
> The only change is conversion from javax to the jakarta namespace via 
> contributor Richard Zowalla.
> 
> 
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ]  0 Abstain (please provide specific comments)
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> -David
> 



smime.p7s
Description: S/MIME cryptographic signature

[VOTE] Release Mail 2.0.0-M1

[David Blevins]

Hey All,

If I was thinking ahead I'd have put these both in the same staging repo and 
vote :)

Staging Maven repository:

- https://repository.apache.org/content/repositories/orgapachegeronimo-1153/

The only change is conversion from javax to the jakarta namespace via 
contributor Richard Zowalla and a change from "javamail" to simply "mail"


Please vote to approve this release:
[ ] +1 Approve the release
[ ]  0 Abstain (please provide specific comments)
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

-David



smime.p7s
Description: S/MIME cryptographic signature

[VOTE] Release Activation 2.0.0-M1

[David Blevins]

Hey All,

We're thinking to do a release on the TomEE side and this is one of the 
snapshot dependencies we have.  I've prepped a 2.0.0-M1 with the idea that 
being a milestone it should be fairly non-controversial to propose without a 
heads up and I haven't checked the TCK status.  I know we're not yet actively 
running the signature tests on the TomEE side.

I propose we release 2.0.0-M1 so we have some non-snapshots to work with and 
come back to 2.0.0 as things look 100% on all fronts

Staging Maven repository:

 - https://repository.apache.org/content/repositories/orgapachegeronimo-1153/

The only change is conversion from javax to the jakarta namespace via 
contributor Richard Zowalla.


Please vote to approve this release:
[ ] +1 Approve the release
[ ]  0 Abstain (please provide specific comments)
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

-David



smime.p7s
Description: S/MIME cryptographic signature

Re: TomEE MicroProfile and Jakarta

[David Blevins]

This is very close.  The dangers of A are not quite captured.  Completely agree 
with the dangers of B.

> On Apr 1, 2022, at 1:13 AM, Zowalla, Richard 
>  wrote:
> 
> So we basically have to options (if I understand the discussion
> correctly):
> 
> (A) Put some effort / resources into upgrade our MP impls to the latest
> versions to fully support Jakarta namespace. From my understanding
> maintaining these impls is a bit PITA as MP tends to break its API
> every few months, right? It will take some time, effort and resources
> to catch up.

The danger here is that we - due to lack of time / resources - will continue to 
not be seen as a viable MicroProfile implementation.

MicroProfile is approximately 70 months old.  We were able to keep up for only 
1.5 months out of that 70.  It was with TomEE 7.1, released with MicroProfile 
2.0 support in September of 2018, outdated by MicroProfile 2.1 in October 2018. 
 We were 27 months late to getting our first and only MicroProfile version 
implemented, which is now 41 months out of date.

> 
> (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> side, which breaks the "we use apache impls"-credo but enables a faster
> move forward. I see the danger here that we - due to lack of time /
> resources - will not find the way back to our own Apache
> implementations and will stick with smallrye for a long (?) time
> perhaps.

Correct.  And as mentioned, not finding our way back to our own Apache 
implementations has already been the status quo.

> People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> ready for it, yet. With the latest M7 version, users cannot start new
> projects as testing possibilities are super limited.
> 
> Btw.: I am unsure, if we are still using Hibernate Validation in the
> current TomEE 9-M8 Snapshot. But if we do, we already broke the
> "everything from apache"-credo for the sake of getting the
> certifaction. 

Our certified distribution (Plume) used EclipseLink instead of OpenJPA, Mojarra 
instead of MyFaces and Hibernate Bean Validation instead of BVal.


-David

Re: TomEE MicroProfile and Jakarta

[David Blevins]

It would be great to see us have compliant MicroProfile implementations 
somewhere in Apache; Geronimo, TomEE, CXF.  It's still my personal preference 
--  It makes very little sense to go through the effort to create a spec and 
tck to enable multiple implementations that can compete/innovate and then wind 
up with just one implementation in the industry.

That said, from a TomEE perspective we're struggling to keep up with all specs, 
Jakarta EE and MicroProfile.  Part of that is we do try to uniquely implement 
specs, while everyone else just uses the exact same implementation.  We're not 
really playing the same game.  We would need more resources than the 
competition to compete in the way we have been attempting.  However, because 
we're behind, we end up with fewer resources and larger gaps between 
implementations and over time our goals becomes harder, not easier.

I wonder if we should switch to the SmallRye implementations where needed.  Not 
because we've given up hope of having Apache implementations, but because if we 
assume our desire to do the implementation work here is a constant and we know 
the time to get there will some number of months and that will likely be after 
complete our Jakarta EE spec work, which is also some number of months... we're 
basically talking sometime 2023.  The question then becomes, how do we want to 
spend our time till then?  Do we want to spend it in a compliant state or a 
non-compliant state?

If we spend the next year and change in a compliant state, using the SmallRye 
impls where needed until we've created compliant Apache versions, then we are 
competitive and will gain resources.  The date on which we would have resources 
to create those Apache implementations would likely be sooner.  If we spend the 
next year and change still not in a compliant state (as we've been since 2020), 
then we'l continue to take a resource hit and the date on which we would have 
resources to create those Apache implementations would likely be later.  There 
are also other risks with this approach.

So though it may seem backwards my gut says, unless we get a dramatic influx of 
resources from nowhere, we should use SmallRye where we need until we have the 
time to dedicate to the Apache implementations.


-David


> On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro  
> wrote:
> 
> Hi,
> 
> Small update regarding jakarta namespace switch and MicroProfile. Adding
> Geronimo dev@list because we are using most of the Geronimo implementations
> 
> In order to migrate, we have created a shaded version of all MicroProfile
> APIs to relocate all javax to jakarta. It worked but it's causing some
> issues with TCK. They are not relocated so of course, all TCK are failing.
> 
> I wanted to see how far we are regarding our implementations, so I went
> ahead and updated all TCK to the latest version (and compatible with the
> Jakarta namespace).
> 
> The other option would be to grab all the TCK and create their equivalent
> in jakarta namespace using the same approach as for the APIs.
> 
> What are your thoughts?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com



smime.p7s
Description: S/MIME cryptographic signature

Re: DISCUSS geronimo-security_1.0_spec content unclear

[David Blevins]

> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau  wrote:
> 
> No I guess it was right, "that are" ;) = fork @G only when we need to
> change some impl/default provider.

Right.  A few things in my mind at least:

 - Industry health: we (Apache) are the only other implementations of 
Activation, JavaMail, JACC and similar "impl" specs.  If we give up on the 
impls we have, the industry collapses down to one impl and then what is the 
point of a spec?

 - Competitiveness: we have seen performance issues reported against our impls. 
 I distinctly remember one for JACC several years ago.  Where there are issues, 
there are also potential advantages.  If we can handle it, let's keep our impls 
and be competitive.

Where there is no actual impl I don't see any gain for the effort even if small.

 - Unavoidable EPL dependence: We're not likely to write a new Java compiler 
any time soon, so we're stuck with the EPL forever.

 - Likelyhood of increased EPL dependence: Given it is the default choice in 
Jakarta, more things will be created under it we may need.

 - Decreasing helping hands: Projects at Apache are switching over to the EPL 
libraries, so we will have fewer people willing to type in APIs for 
already-thin legal reasons.


-David

Re: DISCUSS geronimo-security_1.0_spec content unclear

[David Blevins]

> On Sep 4, 2019, at 6:04 AM, Mark Struberg  wrote:
> 
> No, this is an intended situation.
> When one fully passes the TCK then you get the EFSL. This 'removes' the 
> copyleft nature of the EPL.
> The details are quite nested in the legal papers, but that's it basically.
> 
> If we just upgrade our existing API to be binary compat then we have no IP 
> issues.

I'm not sure I understand what's being said with the above.

If it is helpful I can add to the conversation:

 - The EFSL only applies to specification PDF, HTML and Javadoc.  It does not 
apply to the API jars.
 - The EFSL is not an OSI-approved license and not Approved by the Apache Board 
as safe to ship.



-David

Re: DISCUSS geronimo-security_1.0_spec content unclear

[David Blevins]

> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau  wrote:
> 
> If we still can't reuse jakata artifacts (their license is ok and there is no 
> impl reference inside so we should just use them, right?) it sounds natural

This is my current thinking as well; maintain apis that are impls, use the EPL 
version otherwise.

We do have a handful of EPL dependencies, such as ECJ which Tomcat itself uses. 
 Also as more projects like CXF switch over using the Jakarta versions, our 
excludes just get harder to manage.


-David

> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro  
> a écrit :
> Hi all,
> 
> I was digging into some other specifications and see what would pass Jakarta 
> TCK and realized that geronimo-security_1.0_spec content actually mixes 2 
> specifications.
> 
> https://github.com/eclipse-ee4j/security-api
> 
> and 
> 
> https://github.com/eclipse-ee4j/jaspic
> 
> I thought the initial intent was to create a specific artifact per 
> specification.
> Mixing them is a bit annoying from a certification perspective.
> It's also not clean because in Tomcat for instance, there is already jaspic 
> API so it becomes a duplicate.
> 
> Would it be possible to split them up in 2 artifacts?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: Java EE 8 versions of APIs

[David Blevins]

See this note on our activation thread.  Long story short, our version 1.1 is 
legitimate and the exact version expected for Java EE 8 on Java 8.

 - 
https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@

On JavaMail, my recommendation would be to update asap, but not hold up the 
TomEE 8.0.0 final release.

IMHO, we should try to be vote-ready on Friday.  If we can get it done in that 
time, cool.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro  
> wrote:
> 
> Trying to pull this message up in the list.
> 
> If we want to release Apache TomEE 8.0.0 before CodeOne, we need JavaMail,
> Activation and some others.
> For the others, I think I managed to get them up for vote and ready.
> 
> For Activation and JavaMail it's also an implementation so there is more
> work involved and I am not sure we can get it done by CodeOne.
> Of course it's not a good reason, but I still want to revive this topic so
> we can decide all together how we want to proceed.
> 
> Do we update/create our specs in Geronimo?
> Do we use the eclipse jars?
> 
> thoughts
> 
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, Aug 15, 2019 at 5:53 AM David Blevins 
> wrote:
> 
>>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker 
>> wrote:
>>> 
>>> Okay; for EDL I see it's compatible with Apache licensing, but
>>> strangely, JAXB license does not look like an EDL:
>>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
>>> 
>>> Am I mistaking or this is actually "cheesy" ?
>> 
>> I pulled down the official text here and did a quick reformat to match it
>> to the LICENSE.md
>> 
>> - https://www.eclipse.org/org/documents/edl-v10.php
>> 
>> Sans the copyright statement, both came out identical in a diff, so we
>> appear good.
>> 
>> We will want to make sure our NOTICE file does contain the copyright
>> statement, so that is a definitely good catch.
>> 
>> 
>> -David
>> 
>>> Le mer. 14 août 2019 à 10:37, David Blevins  a
>> écrit :
>>>> 
>>>>> On Aug 14, 2019, at 1:23 AM, Alex The Rocker 
>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> How about JAXB which is not EPL but EDL 1.0 ?
>>>>> (see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)
>>>> 
>>>> EDL is an approved license.  Here's the complete naughty and nice list
>> as it where :)
>>>> 
>>>> - https://apache.org/legal/resolved.html
>>>> 
>>>> The interesting thing about jaxb-api is there is only one
>> implementation in the world and it is also EDL and no longer included in
>> the JVM.  If we typed in the API, 98% of the other JAXB code we ship would
>> still be EDL.
>>>> 
>>>> 
>>>> -David
>>>> 
>>>>> Le mer. 14 août 2019 à 10:16, David Blevins 
>> a écrit :
>>>>>> 
>>>>>> This is really the better thread to talk about how to handle the gaps
>> in our Java EE 8 APIs and support.
>>>>>> 
>>>>>> As noted, there is not license victory to be won.  We have had EPL
>> and CDDL dependencies since v1.0 in 2011.
>>>>>> 
>>>>>> From a Geronimo perspective, we typed in the APIs and created all
>> those spec jars because there were no open source options that weren't the
>> JBoss GPL versions.  GlassFish didn't exist yet.  When GlassFish came
>> about, we kept up the practice largely out of habit.  We did have an
>> unavoidable CDDL via the xml schemas and JAXB RI, so our licensing victory
>> wasn't quite there.
>>>>>> 
>>>>>> This is really a resources and timeline issue.
>>>>>> 
>>>>>> Some of these specs are actually implementations, specifically:
>>>>>> 
>>>>>> - JavaMail 1.6
>>>>>> - JACC 1.6
>>>>>> - Activation 1.2
>>>>>> 
>>>>>> If we decide we want the Geronimo versions to be upgraded
>> (implemented) and this is important for TomEE 8, we should expect that to
>> ship sometime 2020.
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> David Blevins
>>>>>> http://twitter.com/dblevins
>>>>>> http://www.tomitribe.com
>>>

Re: Activation 1.2 API/IMPL

[David Blevins]

> On Aug 26, 2019, at 6:47 AM, Jean-Louis Monteiro  
> wrote:
> 
> Hi,
> 
> We currently don't have any Activation 1.2 spec jar (api/impl).
> We need it for Jakarta EE 8 certification so I'll start creating a Geronimo
> spec jar for it.

Ok, it's been a yo-yo day on the Jakarta EE 8 side of the fence as we're 
nailing down the final spec and dealing with this PR that is attempting to 
decipher to the world all potentially confusing gaps:

 - https://github.com/eclipse-ee4j/jakartaee-platform/pull/109

The short version of this is that several specifications that were in Java EE 6 
were removed from Java EE when those things were added to the JVM.  
Specifically:

 - Activation
 - JAXB
 - JAX-WS
 - Web Service Metadata (javax.jws)

These were all donated to Eclipse anyway and then famously deleted in Java 11.

The long story short, there is no official version from a Java EE 8 
specification.

For Activation, here's what we're dealing with:

 - Java 8: Activation 1.1
 - Java 9: Activation 1.2
 - Java 11: no activation

If we shipped an Activation 1.1 jar we would not be breaking Jakarta EE 8 
compliance.

As we don't need more scope, I recommend we do not delay TomEE 8 to ship an 
Activation 1.2 jar.


-David

Re: [VOTE] Apache XBean 4.11 release

[David Blevins]

+1


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 3, 2018, at 12:11 AM, Romain Manni-Bucau  wrote:
> 
> Hello everyone,
> Here is the vote to let us get asm7 shade and a fix in the multiversion jar 
> scanning.
> 
> The dist (dev) area is available at 
> https://dist.apache.org/repos/dist/dev/geronimo/xbean/ 
> <https://dist.apache.org/repos/dist/dev/geronimo/xbean/> (rev 29854)
> The staging repo is: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1072 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1072>
> Tag is http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.11/ 
> <http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.11/> (rev 
> 1842681)
> My keys is still available in http://svn.apache.org/repos/asf/geronimo/KEYS 
> <http://svn.apache.org/repos/asf/geronimo/KEYS>
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
> 
> 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>

Re: asm7 preparation

[David Blevins]

> On Oct 2, 2018, at 8:48 AM, Mark Struberg  wrote:
> 
> Otoh I'm totally fine either ways.

For clarity, though I made the suggestion, I'm fine either way as well.

There might be a few 4.10.x in our future, but it wouldn't be terrible.

I definitely see how a 5x change has the opportunity to make everyone suddenly 
ambitious which usually pushes things out.

I'm good with whatever.


-David



signature.asc
Description: Message signed with OpenPGP

Re: xbean-reflect changes and potential xbean 5?

[David Blevins]

I think what threw me off was seeing XBEAN-309 updated from 4.10 to 4.11.  I 
suspect you moved it only because I hadn't bother to close it, which I should.

I've updated it to 4.10 and marked it closed.

-David

> On Oct 2, 2018, at 12:27 AM, Romain Manni-Bucau  wrote:
> 
> No worries, let's tackle this asm7 thing and we can even add other features ;)
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 2 oct. 2018 à 00:01, David Blevins  a écrit :
> Apparently I have to worry about becoming senile.  I did an svn log and swore 
> I didn't see the commit in there.  It's definitely there.  I think my mind 
> has been warped by working with Git too long.
> 
> Sorry for the noise and thank for the release, sir!
> 
> 
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
> > On Oct 1, 2018, at 1:10 PM, Romain Manni-Bucau  
> > wrote:
> >
> > Seems the code is still here - see 
> > https://github.com/apache/geronimo-xbean/blob/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditorRegistry.java
> >
> > Le lun. 1 oct. 2018 22:04, Romain Manni-Bucau  a 
> > écrit :
> > Hmm, thought i just did what was mentionned in this thread which was not 
> > about dropping any code but ensuring static usage was kept only for 
> > compatibility and moving to a not leaking impl.
> >
> > Do you have a failling test of the missing feature? - feel free to push it 
> > with @Ignore ;). I can check tomorrow I think.
> >
> > We will release soon the 4.11 with asm7 support - we just need to finish to 
> > decide if there is a blocker to do asm7 package or not (another thread on 
> > it).
> >
> > Le lun. 1 oct. 2018 20:52, David Blevins  a écrit :
> > > On Aug 8, 2018, at 6:53 PM, David Blevins  wrote:
> > >
> > > I'd love to do a 4.x release of this code.
> >
> > Hey Romain, is there any reason you pulled this code out of the XBean 4.10 
> > release?  Ideally we discuss these things as a community before tacking 
> > action.
> >
> > Would you mind if I did a 4.11 with it included?
> >
> >
> >
> > -David
> >
> >
> 



signature.asc
Description: Message signed with OpenPGP

Re: asm7 preparation

[David Blevins]

> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau  wrote:
> 
> :) as usual with asm, looks ok but breaks several apps ;). But main point is: 
> do we want to export as asm6 the real asm7 and fake the runtime it will work? 
> If we want a smooth upgrade we can update asm6 module to have some of changes 
> but keep asm7 module to ensure we cover it IMHO.

We should definitely not introduce ASM 7 code into our asm6 module.

Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean 
major version to 5 when we switch to ASM 7?

That would give us the option to keep pushing out XBean 4.x releases with 
further ASM 6 updates for those who can't/won't upgrade yet or also have stable 
branches to maintain.

If if we don't change the major version and any critical bugs or security 
vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a 
few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a 
de facto branch, just after the fact and in a very awkward way.


-David

Re: asm7 preparation

[David Blevins]

> On Sep 30, 2018, at 10:44 AM, Romain Manni-Bucau  
> wrote:
> 
> 3. keep it like that
> 4. use an "asm.*" package crossing fingers
> 
> I'd love 4 but I fear it can create issue quickly when I see what java is 
> becoming so, personally, i think 3 is safe but since we are at "that" moment 
> I'd like to get your feedback.

Like you I like 4, but 3 is probably the smartest option. I didn't care for 
option 3 when Mark suggested it years ago, but in hindsight it has worked out 
very well.

Truthfully, if the ASM versioned their own packages like that, we wouldn't need 
to shade it all and neither would anyone.


-David

Re: xbean-reflect changes and potential xbean 5?

[David Blevins]

Apparently I have to worry about becoming senile.  I did an svn log and swore I 
didn't see the commit in there.  It's definitely there.  I think my mind has 
been warped by working with Git too long.

Sorry for the noise and thank for the release, sir!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 1, 2018, at 1:10 PM, Romain Manni-Bucau  wrote:
> 
> Seems the code is still here - see 
> https://github.com/apache/geronimo-xbean/blob/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditorRegistry.java
> 
> Le lun. 1 oct. 2018 22:04, Romain Manni-Bucau  a écrit 
> :
> Hmm, thought i just did what was mentionned in this thread which was not 
> about dropping any code but ensuring static usage was kept only for 
> compatibility and moving to a not leaking impl.
> 
> Do you have a failling test of the missing feature? - feel free to push it 
> with @Ignore ;). I can check tomorrow I think.
> 
> We will release soon the 4.11 with asm7 support - we just need to finish to 
> decide if there is a blocker to do asm7 package or not (another thread on it).
> 
> Le lun. 1 oct. 2018 20:52, David Blevins  a écrit :
> > On Aug 8, 2018, at 6:53 PM, David Blevins  wrote:
> > 
> > I'd love to do a 4.x release of this code.
> 
> Hey Romain, is there any reason you pulled this code out of the XBean 4.10 
> release?  Ideally we discuss these things as a community before tacking 
> action.
> 
> Would you mind if I did a 4.11 with it included?
> 
> 
> 
> -David
> 
> 

Re: xbean-reflect changes and potential xbean 5?

[David Blevins]

> On Aug 8, 2018, at 6:53 PM, David Blevins  wrote:
> 
> I'd love to do a 4.x release of this code.

Hey Romain, is there any reason you pulled this code out of the XBean 4.10 
release?  Ideally we discuss these things as a community before tacking action.

Would you mind if I did a 4.11 with it included?



-David

Re: [VOTE] Release XBean 4.10

[David Blevins]

Never mind.  I missed the result vote which was a separate thread. I'll put a 
4.11 up.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 1, 2018, at 11:37 AM, David Blevins  wrote:
> 
> Can we do a reroll with XBEAN-309 included?  Sans that does anyone mind if I 
> immediately cut the XBean 4.11 now?
> 
> The work has been done for 2 months and I was hoping to get this into a TomEE 
> release soon.  Hopefully TomEE 8 will be cut in the next days.
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins <http://twitter.com/dblevins>
> http://www.tomitribe.com
> 
>> On Sep 26, 2018, at 1:11 AM, Romain Manni-Bucau > <mailto:rmannibu...@gmail.com>> wrote:
>> 
>> Hi guys,
>> 
>> XBean got asm upgraded to 6.2.1 which contains some java 11 fixes 
>> (https://issues.apache.org/jira/browse/XBEAN-311 
>> <https://issues.apache.org/jira/browse/XBEAN-311>). Here is the vote to 
>> promote it.
>> 
>> The dist (dev) area is available at 
>> https://dist.apache.org/repos/dist/dev/geronimo/xbean/ 
>> <https://dist.apache.org/repos/dist/dev/geronimo/xbean/> (rev 29700)
>> The staging repo is: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1070 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1070>
>> Tag is http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.10/ 
>> <http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.10/> (rev 
>> 1842004)
>> My keys is the same as last time (available in 
>> http://svn.apache.org/repos/asf/geronimo/KEYS 
>> <http://svn.apache.org/repos/asf/geronimo/KEYS>)
>> 
>> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
>> 
>> 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>

Re: [VOTE] Release XBean 4.10

[David Blevins]

Can we do a reroll with XBEAN-309 included?  Sans that does anyone mind if I 
immediately cut the XBean 4.11 now?

The work has been done for 2 months and I was hoping to get this into a TomEE 
release soon.  Hopefully TomEE 8 will be cut in the next days.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 26, 2018, at 1:11 AM, Romain Manni-Bucau  wrote:
> 
> Hi guys,
> 
> XBean got asm upgraded to 6.2.1 which contains some java 11 fixes 
> (https://issues.apache.org/jira/browse/XBEAN-311 
> <https://issues.apache.org/jira/browse/XBEAN-311>). Here is the vote to 
> promote it.
> 
> The dist (dev) area is available at 
> https://dist.apache.org/repos/dist/dev/geronimo/xbean/ 
> <https://dist.apache.org/repos/dist/dev/geronimo/xbean/> (rev 29700)
> The staging repo is: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1070 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1070>
> Tag is http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.10/ 
> <http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.10/> (rev 
> 1842004)
> My keys is the same as last time (available in 
> http://svn.apache.org/repos/asf/geronimo/KEYS 
> <http://svn.apache.org/repos/asf/geronimo/KEYS>)
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
> 
> 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>

Re: [VOTE] Geronimo Validation 2.0 (spec) v1.0

[David Blevins]

+1

Thank you for doing this, Romain!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 30, 2018, at 8:38 AM, Romain Manni-Bucau  wrote:
> 
> Hi guys,
> 
> To enable BVal and TomEE releases, I'd like to release our validation spec 
> bundle.
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1071 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1071>
> The dist (dev) area is: 
> https://dist.apache.org/repos/dist/dev/geronimo/specs/validation/ 
> <https://dist.apache.org/repos/dist/dev/geronimo/specs/validation/> (rev 
> 29801)
> The tag is: 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_2.0_spec-1.0/
>  
> <http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_2.0_spec-1.0/>
>  (rev 1842396)
> My key is the same as usual.
> 
> Vote will be open for 3 days or until we cancel it or we get 3 +1 binding 
> votes.
> 
> 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>

xbean-reflect changes and potential xbean 5?

[David Blevins]

All,

I updated the converter code in xbean-reflect to add support for JAX-RS style 
string constructors and static factory methods.  We weren't so clever to think 
of this in 2006, but it definitely fits.

Moreover, I don't think we need half of the built-in Converter/PropertyEditor 
implementations now.  Most of them can be deleted with likely a positive speed 
impact as part of the process of converting is looping over all the built-in 
Converter/PropertyEditor instances.  There's a second startup improvement as 
well as they are created eagerly via static initializer.

I'd love to do a 4.x release of this code.  It could be nice to save the 
deleting of the property editors for a potential XBean 5.x.  I'm ok with one or 
the other or both.  I see Łukasz's work which might make for a good 5.x 
release, so maybe we just do that.

Thoughts or preferences?


-David

Re: [VOTE] Move ahead with creating a reusable JWT module

[David Blevins]

Ah.  My intention was a +1 would mean "We should create new JWT module in 
Geronimo now, regardless of what TomEE is discussing."

Not "can we ever" in a general sense, but should we do it right now.

If someone would like to wait a bit longer, they should not vote +1.  It could 
still happen later of course.


-David

> On Mar 18, 2018, at 7:32 PM, John D. Ament <johndam...@apache.org> wrote:
> 
> Just to make sure I understand.  a +1 on this to me means there may be a 
> module created in geronimo.  Maybe not.  But either way it shouldn't stop 
> what TomEE is doing.
> 
> On Sun, Mar 18, 2018 at 8:59 PM David Blevins <david.blev...@gmail.com> wrote:
> My vote would be -0 and I hesitate even for a negative anything.
> 
> I think the "Geronimo will do it anyway, collaborate or not" perspective 
> feels a bit like an ultimatum.  That said, if people truly do want to move on 
> regardless of what happens in TomEE, that's exactly what should happen.
> 
> I feel strongly that a project should not be obstructed by other projects who 
> feel ownership over an domain, be forced to collaborate, or otherwise be 
> stopped in their tracks.
> 
> Here's how I'd like my vote read:
> 
>  - Waiting to see what TomEE decides or creates would be ideal in my mind, 
> but not necessary if there is support for moving forward
> 
>  - I wouldn't help, but I wouldn't stand in the way
> 
>  - I continue to have reservations naming reusable components after a dead 
> app server.  I managed to have all my best efforts remain perfectly invisible 
> under the name "OpenEJB" and "EJB."  If people want to put effort into 
> reforming the 15 year-old Geronimo brand, they are welcome to do so, but I 
> can't sign up for that again.  I can't pretend this isn't a significant 
> obstacle.
> 
>  - I continue to feel we'd be stronger together (TomEE and Geronimo).  With 
> these false lines making everyone have to get commit twice and hiding our 
> best work under a dead website and brand, we aren't getting the strength and 
> speed we need.
> 
> 
> As long as I feel understood, not pushed into doing something I don't want to 
> do, I'm more than happy.
> 
> 
> -David
> 
> > On Mar 18, 2018, at 5:05 PM, David Blevins <david.blev...@gmail.com> wrote:
> >
> > Two votes are up in the TomEE community on what to do with PR #123 ( 
> > https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE 
> > should merge it.  The second vote is if TomEE should attempt to extract it.
> >
> > It was said 3-4 times in the discussion between both communities "geronimo 
> > will have a jwt-auth impl."  This is absolutely ok, there is no rule that 
> > two projects cannot do the same or similar thing.  Apache Tamaya exists and 
> > there is a Geronimo Config, both aim at MicroProfile Config compliance.  
> > This is OK by ASF standards and one community is not judged good or bad for 
> > choosing to also implement something.
> >
> > That said, decisions like this should be made by the project clearly.  Some 
> > people may want to move ahead now.  Some people may want to wait and see 
> > how things go with TomEE.
> >
> > Vote: Move ahead with creating a reusable JWT module
> >
> > +1 Let's get on this, now.  There may be two impls, but that's ok.
> > -+0
> > -1 Let's wait / maybe later / other
> >
> >
> > -David
> >
> 

Re: [VOTE] Move ahead with creating a reusable JWT module

[David Blevins]

My vote would be -0 and I hesitate even for a negative anything.

I think the "Geronimo will do it anyway, collaborate or not" perspective feels 
a bit like an ultimatum.  That said, if people truly do want to move on 
regardless of what happens in TomEE, that's exactly what should happen.

I feel strongly that a project should not be obstructed by other projects who 
feel ownership over an domain, be forced to collaborate, or otherwise be 
stopped in their tracks.

Here's how I'd like my vote read:

 - Waiting to see what TomEE decides or creates would be ideal in my mind, but 
not necessary if there is support for moving forward

 - I wouldn't help, but I wouldn't stand in the way

 - I continue to have reservations naming reusable components after a dead app 
server.  I managed to have all my best efforts remain perfectly invisible under 
the name "OpenEJB" and "EJB."  If people want to put effort into reforming the 
15 year-old Geronimo brand, they are welcome to do so, but I can't sign up for 
that again.  I can't pretend this isn't a significant obstacle.

 - I continue to feel we'd be stronger together (TomEE and Geronimo).  With 
these false lines making everyone have to get commit twice and hiding our best 
work under a dead website and brand, we aren't getting the strength and speed 
we need.


As long as I feel understood, not pushed into doing something I don't want to 
do, I'm more than happy.


-David

> On Mar 18, 2018, at 5:05 PM, David Blevins <david.blev...@gmail.com> wrote:
> 
> Two votes are up in the TomEE community on what to do with PR #123 ( 
> https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE 
> should merge it.  The second vote is if TomEE should attempt to extract it.
> 
> It was said 3-4 times in the discussion between both communities "geronimo 
> will have a jwt-auth impl."  This is absolutely ok, there is no rule that two 
> projects cannot do the same or similar thing.  Apache Tamaya exists and there 
> is a Geronimo Config, both aim at MicroProfile Config compliance.  This is OK 
> by ASF standards and one community is not judged good or bad for choosing to 
> also implement something.
> 
> That said, decisions like this should be made by the project clearly.  Some 
> people may want to move ahead now.  Some people may want to wait and see how 
> things go with TomEE.
> 
> Vote: Move ahead with creating a reusable JWT module
> 
> +1 Let's get on this, now.  There may be two impls, but that's ok.
> -+0 
> -1 Let's wait / maybe later / other
> 
> 
> -David
> 

[VOTE] Move ahead with creating a reusable JWT module

[David Blevins]

Two votes are up in the TomEE community on what to do with PR #123 ( 
https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE should 
merge it.  The second vote is if TomEE should attempt to extract it.

It was said 3-4 times in the discussion between both communities "geronimo will 
have a jwt-auth impl."  This is absolutely ok, there is no rule that two 
projects cannot do the same or similar thing.  Apache Tamaya exists and there 
is a Geronimo Config, both aim at MicroProfile Config compliance.  This is OK 
by ASF standards and one community is not judged good or bad for choosing to 
also implement something.

That said, decisions like this should be made by the project clearly.  Some 
people may want to move ahead now.  Some people may want to wait and see how 
things go with TomEE.

Vote: Move ahead with creating a reusable JWT module

 +1 Let's get on this, now.  There may be two impls, but that's ok.
 -+0 
 -1 Let's wait / maybe later / other


-David

Re: MP-JWT progress

[David Blevins]

> On Mar 18, 2018, at 2:38 PM, Romain Manni-Bucau  wrote:
> 
> Are you against/-1ing g-jwt-auth?

I wouldn't do that, but it's also clear to me the discussion in this thread can 
be significantly clearer.  Objections were made that weren't resolved.  The 
discussion started as what do "we" do with we meaning TomEE and Geronimo.  At 
some point in the middle it was stated Geronimo has already made a decision.  I 
also have the feeling people may have opinions that are in-between a full TomEE 
vs Geronimo decision, such as wanting to put work into inching closer to get a 
better view before deciding.

I think all these things are fine, but we need some healthy votes so people can 
move forward with clear support.


-David

Re: MP-JWT progress

[David Blevins]

> On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau  
> wrote:
> 
> 1. code will be at geronimo - whatever happens at tomee

As far as I understand the topic is still open and no git repos have been 
created anywhere yet, is that right?

Is there anyone on the Geronimo side who would be open to collaborating on a 
reusable JWT library under the TomEE project for a change?  Something not 
branded tomee or geronimo.


-David

Re: MP-JWT progress

[David Blevins]

In case that wasn't clear, gentle objection to moving this now.

If we can get this merged and at least a snapshot out, that'd be preferred.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Mar 18, 2018, at 12:26 PM, David Blevins <david.blev...@gmail.com> wrote:
> 
> I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge this 
> at least?
> 
> 
> -David
> 
>> On Mar 9, 2018, at 3:20 AM, John D. Ament <johndam...@apache.org> wrote:
>> 
>> I don't think its a good idea to move TomEE code into Geronimo.
>> 
>> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>> 
>>> If there is no other comment, any objection to move it to
>>> geronimo-jwt-auth? (let say if not we do it on monday european time)
>>> 
>>> 
>>> 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>
>>> 
>>> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>>> 
>>>> 
>>>> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>
>>>> :
>>>> 
>>>>> Hi community,
>>>>> 
>>>>> 
>>>>> So we now have something close in terms of MP-JWT implementation.
>>>>> 
>>>>> With the playground branch I've been working on (Thanks Romain for the
>>>>> help), we now pass 100% of the TCK (including a missing part in MP-JWT
>>>>> TCK
>>>>> I have eagerly added - see ticket on MP-JWT).
>>>>> 
>>>>> Now the question is how do we proceed?
>>>>> Knowing that most of the code is not TomEE specific.
>>>>> 
>>>> 
>>>> I'd move it to G to a new git repo keeping only the tck exec - a bit like
>>>> Roberto started with config. I'll be happy to help fixing the small
>>>> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
>>>> 
>>>> 
>>>>> 
>>>>> Only few things are in the TomcatSecurityService but that can remain in
>>>>> TomEE because it's not really MP-JWT specific either.
>>>>> 
>>>> 
>>>> +1, was overdue anyway for our servlet-ejb integration
>>>> 
>>>> 
>>>>> 
>>>>> Here is the PR for discussion
>>>>> https://github.com/apache/tomee/pull/123
>>>>> 
>>>>> Cheers
>>>>> Jean-Louis
>>>>> 
>>>>> 
>>>>> --
>>>>> Jean-Louis Monteiro
>>>>> http://twitter.com/jlouismonteiro
>>>>> http://www.tomitribe.com
>>>>> 
>>>> 
>>>> 
>>> 
> 

Re: MP-JWT progress

[David Blevins]

I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge this 
at least?


-David

> On Mar 9, 2018, at 3:20 AM, John D. Ament  wrote:
> 
> I don't think its a good idea to move TomEE code into Geronimo.
> 
> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau 
> wrote:
> 
>> If there is no other comment, any objection to move it to
>> geronimo-jwt-auth? (let say if not we do it on monday european time)
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>> 
>> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
>> 
>>> 
>>> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro 
>>> :
>>> 
 Hi community,
 
 
 So we now have something close in terms of MP-JWT implementation.
 
 With the playground branch I've been working on (Thanks Romain for the
 help), we now pass 100% of the TCK (including a missing part in MP-JWT
 TCK
 I have eagerly added - see ticket on MP-JWT).
 
 Now the question is how do we proceed?
 Knowing that most of the code is not TomEE specific.
 
>>> 
>>> I'd move it to G to a new git repo keeping only the tck exec - a bit like
>>> Roberto started with config. I'll be happy to help fixing the small
>>> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
>>> 
>>> 
 
 Only few things are in the TomcatSecurityService but that can remain in
 TomEE because it's not really MP-JWT specific either.
 
>>> 
>>> +1, was overdue anyway for our servlet-ejb integration
>>> 
>>> 
 
 Here is the PR for discussion
 https://github.com/apache/tomee/pull/123
 
 Cheers
 Jean-Louis
 
 
 --
 Jean-Louis Monteiro
 http://twitter.com/jlouismonteiro
 http://www.tomitribe.com
 
>>> 
>>> 
>> 

Re: [DRAFT] Announcement for Geronimo Config release

[David Blevins]

How about "MicroProfile component specification" ?

"first implementation of a MicroProfile component specification here at Apache" 

-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 16, 2017, at 11:06 PM, Romain Manni-Bucau <rmannibu...@gmail.com> 
> wrote:
> 
> "MP specific specification"? MP 1.0 not being anything special (just 
> referencing EE without bringing more consistency or features) it can work and 
> be less ambiguous than "subcomponent" which means not much to me, wdyt?
> 
> Le 17 sept. 2017 05:05, "David Blevins" <david.blev...@gmail.com 
> <mailto:david.blev...@gmail.com>> a écrit :
>> On Sep 15, 2017, at 5:43 PM, John D. Ament <johndam...@apache.org 
>> <mailto:johndam...@apache.org>> wrote:
>> 
>> 
>> 
>> On Fri, Sep 15, 2017 at 2:36 PM David Blevins <david.blev...@gmail.com 
>> <mailto:david.blev...@gmail.com>> wrote:
>>> On Sep 14, 2017, at 3:54 AM, John D. Ament <johndam...@apache.org 
>>> <mailto:johndam...@apache.org>> wrote:
>>> 
>>> as well as being the first release of a MicroProfile specification 
>>> implementation here at Apache
>> 
>> Note TomEE is the first MP implementation at Apache.  We intentionally 
>> defined MP 1.0 as a subset of the WebProfile so all servers were by default 
>> MP compatible.  TomEE, WildFly, Payara and Liberty were all used in the MP 
>> 1.0 Conference demo and initial presentations.
>> 
>> 
>> Sure, are you asking me to rephrase it? I'm referring to the individual 
>> components, rather than the overall MicroProfile umbrella.
> 
> Yeah, maybe use "first implementation of a MicroProfile sub-component here at 
> Apache" or something similar.
> 
> MP 1.0, 1.1 are all MicroProfile specifications as well, so someone with that 
> perspective will read "MicroProfile specification implementation" differently 
> than intended.
> 
> 
> -David
> 
> 
> 

Re: [DRAFT] Announcement for Geronimo Config release

[David Blevins]

> On Sep 15, 2017, at 5:43 PM, John D. Ament <johndam...@apache.org> wrote:
> 
> 
> 
> On Fri, Sep 15, 2017 at 2:36 PM David Blevins <david.blev...@gmail.com 
> <mailto:david.blev...@gmail.com>> wrote:
>> On Sep 14, 2017, at 3:54 AM, John D. Ament <johndam...@apache.org 
>> <mailto:johndam...@apache.org>> wrote:
>> 
>> as well as being the first release of a MicroProfile specification 
>> implementation here at Apache
> 
> Note TomEE is the first MP implementation at Apache.  We intentionally 
> defined MP 1.0 as a subset of the WebProfile so all servers were by default 
> MP compatible.  TomEE, WildFly, Payara and Liberty were all used in the MP 
> 1.0 Conference demo and initial presentations.
> 
> 
> Sure, are you asking me to rephrase it? I'm referring to the individual 
> components, rather than the overall MicroProfile umbrella.

Yeah, maybe use "first implementation of a MicroProfile sub-component here at 
Apache" or something similar.

MP 1.0, 1.1 are all MicroProfile specifications as well, so someone with that 
perspective will read "MicroProfile specification implementation" differently 
than intended.


-David

Re: [DRAFT] Announcement for Geronimo Config release

[David Blevins]

> On Sep 14, 2017, at 3:54 AM, John D. Ament  wrote:
> 
> as well as being the first release of a MicroProfile specification 
> implementation here at Apache

Note TomEE is the first MP implementation at Apache.  We intentionally defined 
MP 1.0 as a subset of the WebProfile so all servers were by default MP 
compatible.  TomEE, WildFly, Payara and Liberty were all used in the MP 1.0 
Conference demo and initial presentations.


-David

Re: [VOTE] [RESULT] retire/EOL the Geronimo Server part?

[David Blevins]

> On Sep 8, 2017, at 2:42 PM, John D. Ament  wrote:
> 
> I think i get your point of view.  Ill note that i didnt participate in this 
> vote but my POV is that we were only voting on item 1, retire the server.
> 
> The fact that new components are coming in is a different item.  If the goal 
> is to shut down G and moving elsewhere and everyone is in agreement thats 
> fine.  I suspect not everyone is in agreement.
> 
> If for instance there's a strong opinion to incubate potential sub projects 
> that can happen as well.  But i dont think we are saying at this time that G 
> is now EE commons.

Thanks for this.  It does help clarify.


-David

Re: [VOTE] [RESULT] retire/EOL the Geronimo Server part?

[David Blevins]

> On Sep 8, 2017, at 2:23 PM, Mark Struberg  wrote:
> 
> This 'implied' 3rd block was actually never implied nor up for discussion.
> Not quite sure what I did word wrong to give you that impression.
> But rest ensurred that it was never intended that way!


>> Paraphrasing, I’ve seen “we agreed to do it in Geronimo, why are you 
>> attempting to move forward elsewhere”
> 
> We do have existing code in geronimo. Used all over the place in other 
> projects. There is now no confusion anymore as the G server is dead. So what 
> would moving those existing projects to TomEE add for all those projects?

Note, I’m not requesting the remaining Geronimo bits to move to TomEE.  It has 
been mentioned several times, particularly by Jeff and I would support it, but 
for the sake of avoiding confusion I’m not referring to this.  On this 
particular subject, I have a gut feeling David Jencks would really love to see 
Geronimo legacy live on in some form, so if there isn’t unanimous support for 
moving things, I don’t want to push on that rock.

Where I do get confused is statements like this on the thread of adding new 
non-ASF code into TomEE:

> On Aug 11, 2017, at 11:43 PM, Romain Manni-Bucau  
> wrote:
> 
> Why not geronimo subprojects since it is the official umbrella project now
> - vs tomee is not until we rediscuss it transprojects.
> 
> Really sounds weird to me to try to push it in tomee when we agreed to do
> it in G weeks ago, what am I missing?

When statements like this are said, even proceeding any formal vote on the G 
side, it blurs things for me.  I can’t see the “we” being cited and it likely 
colors people’s comments and votes.  This very well can be just my confusion.

If the “we” is just Romain.  That’s fine.  If there is a “we” and this 
perspective that Geronimo is the "official umbrella project now” to the 
exclusion of all other Apache projects, then I’d really like to talk about it.


-David

Re: [VOTE] [RESULT] retire/EOL the Geronimo Server part?

[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 <johndam...@apache.org> wrote:
> 
> On Fri, Sep 8, 2017 at 2:45 AM David Blevins <david.blev...@gmail.com> wrote:
> > On Aug 30, 2017, at 12:14 PM, Mark Struberg <strub...@yahoo.de> 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

Re: Renaming Geronimo Config?

[David Blevins]

> 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.

In all my years at Apache I’ve never closed a vote that sharply especially when 
I know there are concerns.

It is clear I am the odd man out, however, and do not want to stand in the way 
the way of anyone’s fun.  

What I ask is the same in return.  I ask you politely to not block attempts on 
the TomEE side to create sub-projects.  I think everyone should be allowed to 
have the fun they want to have.  Anatole has’t come and tried to shutdown 
Geronimo config.  I haven’t attempted to go to OWB and shut down Meecrowave.  
If there are people excited and willing to work on something on the TomEE side, 
please don’t try to shut it down and redirect it to Geronimo.

I’ll contribute to what I can over on this side of the fence and think the 
change is positive.  I don’t however agree that other projects shouldn’t also 
have similar fun.


-David

Re: Other MP Specs @ Geronimo?

[David Blevins]

> On Sep 7, 2017, at 5:35 PM, John D. Ament  wrote:
> 
> The reason I'm hesitant to look at XBean, it seems to be focused on a single 
> target (which is good for a sub-project).  It would start to confuse things 
> to make more stuff XBean.

Can you elaborate on what you mean by single target?  I’m happy to give the 
history behind XBean, but the long and short of it is it was largely made by 
OpenEJB, ActiveMQ and ServiceMix as a place to share code we thought each other 
might want to reuse.  A lot of it wasn’t used by Geronimo till later.  Nearly 
all of it is unrelated and goes across the board.  It’s the closest Apache has 
gotten to an EE commons.

 - xbean-spring = Configuration library for Spring apps that want to use custom 
xml

 Used by: ActiveMQ, ServiceMix

 - xbean-finder = Annotation scanning library

 Used by: OpenEJB, Geronimo, ServiceMix, ActiveMQ, Aries,
  Netflix Governator, Netflix Zuul, OPS4j, CrateDB

 - xbean-blueprint = OSGi blueprint related stuff

 Used by: Geronimio, ServiceMix, ActiveMQ, Aries, Fabric8,
  Osgiliath

 - xbean-naming = JNDI implementation

 Used by: Geronimo, OpenEJB, ServiceMix, Ode, Nuxeo.org,
  Osgiliath

 - xbean-reflect = Lightweight pojo creator/injector

 Used by: OpenEJB, Geronimo, ServiceMix, Plexus, BatchEE,
  Meecrowave, Fabric8, Sonatype Nexus, JOnAS, OPS4j,
  Osgiliath, DataTorrent, more


> Plus its a kind of odd name, I'm guessing the X is for XML.

“Odd name” is a fine enough reason for me.  I certainly prefer that over 
arguing what XBean is or isn’t, cause then I feel like I need to give a history 
lesson.  XBean *is* “app server commons”.  It has no other purpose than that.

There are better names.  Let’s definitely use them if we can find them.  My 
preference would be for us to keep using xbean-* when we can’t think of a 
better name.


-David

Re: Other MP Specs @ Geronimo?

[David Blevins]

> On Sep 4, 2017, at 4:56 PM, John D. Ament  wrote:
> 
> So I want to pick back up at least with fault tolerance.  Would anyone be 
> opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so 
> that it would either be "org.apache.safeguard" or 
> "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, 
> config the latter).

I have a strong preference for “org.apache.safeguard" over 
“org.apache.geronimo.safeguard”.  We have 14 years of Google search results to 
work against and a few million developers brains that say Geronimo is an app 
server.  Every time we put “Geronimo” on something, it’s a strike against 
Hammok, Meecrowave and TomEE and any MP implementation that may want to use it 
but not confuse the world that “Geronimo is back".

If we do want a parent package, I repeat we can use org.apache.xbean if we 
like.  It was meant for common reusable stuff.  We do not need to shackle 
ourselves with any self-imposed restrictions like “xbean needs to be all 
released at once”.  That was only done out of laziness.


-David

Renaming Geronimo Config?

[David Blevins]

Can we rename Geronimo Config?  I think the name is strongly stuck with the app 
server.  From experience in EJB land, try to repurpose names is usually an 
uphill battle.

If we wanted to go with the grain, we could call it XBean Config.  Open to 
other names as well.

If we did call it XBean Config, I’m not sure there’s a need to have the same 
version as the other xbean components.  We could, but I think 1.0 would still 
be fine.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Re: [VOTE] XBean 4.4 release

[David Blevins]

+1


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 9, 2015, at 9:50 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> Hi!
> 
> Please VOTE for the release of Apache XBean-4.4.
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1022/ 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1022/>
> 
> The source distribution can be found here: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1022/org/apache/xbean/xbean/4.4/xbean-4.4-source-release.zip
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1022/org/apache/xbean/xbean/4.4/xbean-4.4-source-release.zip>
> sha1 is 82b2d32e9ccf117b91d2f8bb1907779d743c95fb
> 
> 
> We fixed 3 issues, most notably is fixing the wrong ASM version in 
> EmptyVisitor (#286): 
> https://issues.apache.org/jira/browse/XBEAN/fixforversion/12332977/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
>  
> <https://issues.apache.org/jira/browse/XBEAN/fixforversion/12332977/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel>
> 
> 
> [+1] ship it
> [+0] meh, don’t care
> [-1] nope, stop because ${reason}
> 
> The VOTE is open for 72h.
> 
> Here is my +1.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
> <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> 
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber 
> <http://www.tomitribe.com/>

Re: [VOTE] release jpa 2.1 spec jar in 1.0-alpha-1

[David Blevins]

+1


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Jun 15, 2015, at 10:03 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Hi
 
 I'd like to call a vote to release our jpa 2.1 api jar.
 
 Here are:
 - the staging  repo: 
 https://repository.apache.org/content/repositories/orgapachegeronimo-1021/
 - the tag: 
 http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_2.1_spec-1.0-alpha-1/
 
 Please vote:
 +1: all is fine
 +-0: don't care
 -1: don't release it cause ${good.reason}
 
 Vote will be open for 3 days (72h) or until 3 +1 bindings votes are reached.
 
 PS: AFAIK we didnt pass yet signature test that is why i used alpha versioning
 
 Romain Manni-Bucau
 @rmannibucau |  Blog | Github | LinkedIn | Tomitriber

Re: [VOTE] a few geronimo-spec alpha-1 artifacts (take2)

[David Blevins]

+1


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Sep 17, 2014, at 12:37 PM, Mark Struberg strub...@yahoo.de wrote:

 Hi!
 
 Here comes the release train again after fixing the build and a few missing 
 licenses...
 
 * geronimo-annotation_1.2_spec
 * geronimo-jcdi_1.1_spec
 * geronimo-interceptor_1.2_spec
 * geronimo-concurrent_1.0_spec
 * geronimo-jcache_1.0_spec/
 * geronimo-validation_1.1_spec/
 * geronimo-json-1.0_spec
 
 Here is the staging repo
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-1006/
 
 I bet you will find the source.jars yourself ;)
 
 
 
 
 My key can be found at
 https://svn.apache.org/repos/asf/geronimo/KEYS
 
 
 please VOTE
 [+1] all fine, ship it
 [+0] meh, don't care
 [-1] stop, because ${reason}
 
 
 
 here is my +1
 
 
 txs and LieGrue,
 strub
 

Re: [VOTE] XBean 4.0

[David Blevins]

On Aug 20, 2014, at 10:23 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 The main changes are:
[...]
 skip java.* classes since we'll not get their bytecode for sure
 (protected method if needed)

I'm not a fan of hard coding filtering inside the AnnotationFinder itself, so 
+1 under the condition that we remain open to revising this in a future release.


-David

Re: [RESULT] [VOTE] XBean 4.0

[David Blevins]

On Aug 25, 2014, at 9:43 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:
 PS: ones having identified some issues would be welcomed to at least
 open a jira explaining it and potentially proposing a fix if you
 already have an idea to not forget them for 4.1

Nicely phrased.  And +1 on the welcome nudges.


-David

Re: [RESULT] [VOTE] XBean 4.0

[David Blevins]

And Thank You for the vote!!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Aug 25, 2014, at 9:43 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Counting votes it seems it passed:
 
 +1s:  Alan D Cabrera, David Blevins, Romain Manni-Bucau
 +0: Jean-Baptiste Onofré, Mark Struberg
 -1: no
 
 thank you all for your votes.
 
 PS: ones having identified some issues would be welcomed to at least
 open a jira explaining it and potentially proposing a fix if you
 already have an idea to not forget them for 4.1
 
 I'll publish binaries tonight.
 
 
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau
 
 
 2014-08-25 17:08 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
 @David: it was filtering java.lang.Object since it was created, java.*
 filter just extend this logic since it will never works (excepted if
 you bring java.* in your app which is unlikely. That said method is
 protected to be able to override it.
 
 
 In all case (I think I mentionned it several times) 4.x x  0 will
 make it more usable (OSGi, this if you think it is bad etc...). Main
 purpose was to get a first release fixing linking time and respecting
 the constructor contract
 
 
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau
 
 
 2014-08-25 16:12 GMT+02:00 David Blevins david.blev...@gmail.com:
 On Aug 20, 2014, at 10:23 AM, Romain Manni-Bucau rmannibu...@gmail.com 
 wrote:
 
 The main changes are:
 [...]
 skip java.* classes since we'll not get their bytecode for sure
 (protected method if needed)
 
 I'm not a fan of hard coding filtering inside the AnnotationFinder itself, 
 so +1 under the condition that we remain open to revising this in a future 
 release.
 
 
 -David
 

Re: Google Analytics

[David Blevins]

Was specifically referring to the geronimo.apache.org website.  Seems these 
stats are no longer accessible.



-David

On May 26, 2014, at 3:06 PM, Jean-Louis MONTEIRO jeano...@gmail.com wrote:

 Yep I see the OpenEJB website and a google message to update to Universal 
 Analytics
 
 
 JLouis
 
 
 2014-05-26 23:21 GMT+02:00 David Blevins david.blev...@gmail.com:
 Anyone still able to access this?  For some reason this no longer shows up in 
 my Google Analytics account.
 
 
 On Wed, May 14, 2008 at 11:32 PM, David Blevins david.blev...@visi.com 
 wrote:
 Setup google analytics on all our spaces and added everyone who's a committer 
 who I could easily find a gmail address for.
 
 bruce.sny...@gmail.com
 c1vams...@gmail.com
 dava...@gmail.com
 dblev...@visi.com
 eljo...@gmail.com
 gno...@gmail.com
 goyathlay.geron...@gmail.com
 hcun...@gmail.com
 jason.dil...@gmail.com
 jaydmch...@gmail.com
 jga...@gmail.com
 jrsis...@gmail.com
 kevan.mil...@gmail.com
 paulmcma...@gmail.com
 rick...@gmail.com
 sppat...@gmail.com
 tim.mcco...@gmail.com
 
 
 You don't need a gmail address, just a google account.  So if you're not in 
 the above list, just get someone in the above list to add your google account.
 
 Just visit http://www.google.com/analytics/ to log in and view the data.  
 It'll be a day or two before we see much of anything.
 
 -David
 
 
 
 
 
 -- 
 Jean-Louis

Re: Google Analytics

[David Blevins]

Anyone still able to access this?  For some reason this no longer shows up
in my Google Analytics account.


On Wed, May 14, 2008 at 11:32 PM, David Blevins david.blev...@visi.comwrote:

 Setup google analytics on all our spaces and added everyone who's a
 committer who I could easily find a gmail address for.

 bruce.sny...@gmail.com
 c1vams...@gmail.com
 dava...@gmail.com
 dblev...@visi.com
 eljo...@gmail.com
 gno...@gmail.com
 goyathlay.geron...@gmail.com
 hcun...@gmail.com
 jason.dil...@gmail.com
 jaydmch...@gmail.com
 jga...@gmail.com
 jrsis...@gmail.com
 kevan.mil...@gmail.com
 paulmcma...@gmail.com
 rick...@gmail.com
 sppat...@gmail.com
 tim.mcco...@gmail.com


 You don't need a gmail address, just a google account.  So if you're not
 in the above list, just get someone in the above list to add your google
 account.

 Just visit http://www.google.com/analytics/ to log in and view the data.
  It'll be a day or two before we see much of anything.

 -David

Re: [VOTE] XBean 3.18

[David Blevins]

+1


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On May 20, 2014, at 1:56 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 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

[David Blevins]

+1

On Mar 31, 2014, at 12:54 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 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

Re: [VOTE] release geronimo-jbatch_1.0-1.0

[David Blevins]

+1

-David

On Nov 25, 2013, at 7:53 AM, Mark Struberg strub...@yahoo.de wrote:

 Good evening!
 
 I'd like to call a VOTE on releasing the geronimo jbatch 1.0 API. 
 
 The API is already used in Apache BatchEE and passes the JSR-352 JBatch TCK.
 
 The staging repo is 
 https://repository.apache.org/content/repositories/orgapachegeronimo-005/
 
 The source release is here
 https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/specs/geronimo-jbatch_1.0_spec/1.0/geronimo-jbatch_1.0_spec-1.0-source-release.zip
 
 The tag can be found here
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jbatch_1.0_spec-1.0/
 
 [+1] ship it
 [+0] meh, don't care
 [-1] nope, because ${reason}
 
 Here is my +1
 
 LieGrue,
 strub
 
 

[RESULTS] XBean 3.15 release

[David Blevins]

Ok.  Here's my +1.

Vote passes with 8 +1s and no other votes:

David Blevins
Alan Cabrera
Romain Manni-Bucau
Dain Sundstrom
Hiram Chirino
Jean-Louis Monteiro
Jarek Gawor
Mark Struberg


-David


On Nov 6, 2013, at 8:55 PM, David Blevins david.blev...@gmail.com wrote:

 Ok, release rolled!
 
 Binaries:
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-086/
 
 Tag:
 
 http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.15/
 
 
 72 hours for voting! :)
 
 
 -David
 

[VOTE] XBean 3.15 release

[David Blevins]

Ok, release rolled!

Binaries:

https://repository.apache.org/content/repositories/orgapachegeronimo-086/

Tag:

http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.15/


72 hours for voting! :)


-David

XBean 3.15 release?

[David Blevins]

Anyone object if I roll an XBean 3.1.5 release?


-David

Re: [VOTE] (take 2) Release genesis-2.1 and xbean-3.13

[David Blevins]

+1 for genesis

+1 for xbean.  The presence of a snapshot repository declaration is fine, IMO.  
I built both genesis and xbean tags against a clean maven repo and no snapshots 
were downloaded.


-David

On Mar 11, 2013, at 1:34 PM, Jarek Gawor jga...@gmail.com wrote:

 +1 for genesis.
 
 -1 for xbean. Unless I'm looking at a cached version, there are still
 snaphot repositories defined in the root pom (marked with !-- Can be
 removed once Genesis SNAPSHOT dependency is removed --).
 
 Jarek
 
 
 On Fri, Mar 8, 2013 at 3:12 PM, Mark Struberg strub...@yahoo.de 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 repository with the URL pointing to the
 staging repo as posted above.
 
 
 txs and LieGrue,
 strub

Re: geronimo.genesis

[David Blevins]

On Jan 31, 2013, at 7:57 AM, Mark Struberg strub...@yahoo.de wrote:

 Hi folks!
 
 I'm currently trying to fix a xbean compilation error on java7 platforms.
 
 Thus I stumbled over a very deep parent chain in our poms. There are 4 
 layers of geronimo.genesis parent poms. And the top of them still point 
 to an apache-parent in the ancient version 6...
 
 Is this something to clean up?
 And if so: who is cleaning this up? :)

If you're looking for volunteers I suspect you won't find any :)  If you are 
the volunteer, than I say go for it!

Certainly for something as tiny as xbean we don't need the complicated and 
outdated parent poms.


-David

[jira] [Created] (XBEAN-233) Support for RetentionPolicy.CLASS broken for ElementType FIELD, METHOD and CONSTRUCTOR

[David Blevins (JIRA)]

David Blevins created XBEAN-233:
---

 Summary: Support for RetentionPolicy.CLASS broken for ElementType 
FIELD, METHOD and CONSTRUCTOR
 Key: XBEAN-233
 URL: https://issues.apache.org/jira/browse/XBEAN-233
 Project: XBean
  Issue Type: Bug
  Components: finder
Affects Versions: 3.12
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.13


For findAnnotatedFields, if said class had any fields annotated with @Foo, then 
all fields were returned.

Same bug for a findAnnotatedMethods, findAnnotatedConstructors

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release XBean 3.12

[David Blevins]

+1

-David

Re: [VOTE] Release Geronimo 3.0.0 (3rd Try)

[David Blevins]

+1


-David

On Jul 3, 2012, at 4:19 PM, Forrest Xia wrote:

 Hi Devs,
 
 With correction of repositoryList URL, here we have the 3rd release candidate 
 for vote. Please help vote at your earliest convenient time.
 
 The server code up for vote is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/geronimo/3.0.0/geronimo-3.0.0-source-release.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/geronimo/3.0.0/geronimo-3.0.0-source-release.zip
 
 The binary code up for vote is:
 Java EE 6 Full Profile Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0.0/geronimo-tomcat7-javaee6-3.0.0-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0.0/geronimo-tomcat7-javaee6-3.0.0-bin.zip
 
 Java EE 6 Web Profile Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0.0/geronimo-tomcat7-javaee6-web-3.0.0-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0.0/geronimo-tomcat7-javaee6-web-3.0.0-bin.zip
 
 Little-G Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/assemblies/geronimo-tomcat7-minimal/3.0.0/geronimo-tomcat7-minimal-3.0.0-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-015/org/apache/geronimo/assemblies/geronimo-tomcat7-minimal/3.0.0/geronimo-tomcat7-minimal-3.0.0-bin.zip
 
 Staging repo is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-015
 
 The tag has created at:
 http://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-3.0.0
 
 Java EE 6 TCKs all passed!
 
 Vote will be at least open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 -- 
 Thanks!
 
 Regards, Forrest
 

Re: [VOTE] XBean 3.10 (take 1)

[David Blevins]

Ok, closing vote with 5 +1s and no other votes.

+1s:
Forrest Xia
David Blevins
Kevan Miller
Alan Cabrera
Shawn Jiang


-David


On Apr 10, 2012, at 11:13 PM, David Blevins wrote:

 Binaries are up for consideration.
 
 Here's the staging repo:
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-032/org/apache/xbean/
 
 I assume this is what was being asked for to run on the 3.0-beta branch.
 
 The tag:
 
 http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.10
 
 
 Vote is up for 72 hours or as needed.
 
 
 -David
 

Re: [VOTE] XBean 3.10 (take 1)

[David Blevins]

Excellent.  My +1

-David

On Apr 10, 2012, at 11:13 PM, David Blevins wrote:

 Binaries are up for consideration.
 
 Here's the staging repo:
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-032/org/apache/xbean/
 
 I assume this is what was being asked for to run on the 3.0-beta branch.
 
 The tag:
 
 http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.10
 
 
 Vote is up for 72 hours or as needed.
 
 
 -David
 

[VOTE] XBean 3.10 (take 1)

[David Blevins]

Binaries are up for consideration.

Here's the staging repo:

 
https://repository.apache.org/content/repositories/orgapachegeronimo-032/org/apache/xbean/

I assume this is what was being asked for to run on the 3.0-beta branch.

The tag:

 http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.10


Vote is up for 72 hours or as needed.


-David

Re: XBean release

[David Blevins]

It sounds like there's willingness, but I'm not sure who is doing what and when.

If I put the vote up tonight, would the standard 72 hour vote period be enough 
for you or Shawn to get the TCK run complete?

If not that's totally fine and we'll probably just use a patched version of 
xbean-finder instead as we're trying to get an OpenEJB/TomEE final release out 
this week.


-David

On Apr 10, 2012, at 1:53 AM, Forrest Xia wrote:

 Yep, a full profile tck run is preferable when we finalize the xbean new 
 release. I could help trigger a tck execution when the change into 3.0-beta 
 branch.
 
 On Sun, Apr 8, 2012 at 11:39 PM, Shawn Jiang genspr...@gmail.com wrote:
 I would like to see a full run of geronimo tck result before the release.
 
 
 On Fri, Apr 6, 2012 at 7:20 PM, Kevan Miller kevan.mil...@gmail.com wrote:
 
 On Apr 5, 2012, at 6:53 PM, David Blevins wrote:
 
  Hoping to get time to do an xbean release today or tomorrow.
 
  Let me know if there's any reason to wait.
 
 Sounds good to me.
 
 I recall Jarek had some Jira's / commits (e.g. 
 https://issues.apache.org/jira/browse/XBEAN-204), but the Jira isn't closed. 
 If that work is in a good state, I'd say a release is in order...
 
 --kevan
 
 
 
 
 -- 
 Shawn
 
 
 
 -- 
 Thanks!
 
 Regards, Forrest
 

Re: XBean release

[David Blevins]

Alright, might be easier to just put the release up for vote and give people 
the time to do what they need.

Rolling


-David


On Apr 10, 2012, at 9:45 PM, David Blevins wrote:

 It sounds like there's willingness, but I'm not sure who is doing what and 
 when.
 
 If I put the vote up tonight, would the standard 72 hour vote period be 
 enough for you or Shawn to get the TCK run complete?
 
 If not that's totally fine and we'll probably just use a patched version of 
 xbean-finder instead as we're trying to get an OpenEJB/TomEE final release 
 out this week.
 
 
 -David
 
 On Apr 10, 2012, at 1:53 AM, Forrest Xia wrote:
 
 Yep, a full profile tck run is preferable when we finalize the xbean new 
 release. I could help trigger a tck execution when the change into 3.0-beta 
 branch.
 
 On Sun, Apr 8, 2012 at 11:39 PM, Shawn Jiang genspr...@gmail.com wrote:
 I would like to see a full run of geronimo tck result before the release.
 
 
 On Fri, Apr 6, 2012 at 7:20 PM, Kevan Miller kevan.mil...@gmail.com wrote:
 
 On Apr 5, 2012, at 6:53 PM, David Blevins wrote:
 
 Hoping to get time to do an xbean release today or tomorrow.
 
 Let me know if there's any reason to wait.
 
 Sounds good to me.
 
 I recall Jarek had some Jira's / commits (e.g. 
 https://issues.apache.org/jira/browse/XBEAN-204), but the Jira isn't closed. 
 If that work is in a good state, I'd say a release is in order...
 
 --kevan
 
 
 
 
 -- 
 Shawn
 
 
 
 -- 
 Thanks!
 
 Regards, Forrest
 
 

XBean release

[David Blevins]

Hoping to get time to do an xbean release today or tomorrow.

Let me know if there's any reason to wait.

-David

Re: [VOTE] Release XBean 3.9

[David Blevins]

If at all possible it would be great to get a re-roll with these two:


r1215562 | dblevins | 2011-12-17 11:49:40 -0800 (Sat, 17 Dec 2011) | 2 lines

XBEAN-198: Support for proposed @javax.annotation.Metatype and 
@javax.annotation.Metaroot annotations


r1215561 | dblevins | 2011-12-17 11:39:05 -0800 (Sat, 17 Dec 2011) | 1 line

produce a source jar

No worries if not.  My +1 either way.



-David

On Dec 16, 2011, at 6:31 AM, Hiram Chirino wrote:

 Please vote for the geronimo xbean 3.9 release,.
 
 The components up for vote are:
 https://repository.apache.org/content/repositories/orgapachegeronimo-349/org/apache/xbean/xbean/3.9/xbean-3.9-source-release.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-349/org/apache/xbean/xbean/3.9/xbean-3.9-source-release.zip
 
 Staging repo is here:
 https://repository.apache.org/content/repositories/orgapachegeronimo-349/
 
 tag is here:
 https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.9/
 
 Vote open 72 hours
 
 [ ] +1 release this
 [ ] 0 don't care
 [ ] -1 don't release this (please explain)
 
 Here's my +1
 
 Regards,
 Hiram
 
 FuseSource
 Web: http://fusesource.com/

[jira] [Created] (XBEAN-196) Meta Annotation Support for Method and Constructor Parameters

[David Blevins (Created) (JIRA)]

Meta Annotation Support for Method and Constructor Parameters
-

 Key: XBEAN-196
 URL: https://issues.apache.org/jira/browse/XBEAN-196
 Project: XBean
  Issue Type: New Feature
  Components: finder
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.9




--
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] [Created] (XBEAN-197) Alternate annotations can serve as @Metatype

[David Blevins (Created) (JIRA)]

Alternate annotations can serve as @Metatype


 Key: XBEAN-197
 URL: https://issues.apache.org/jira/browse/XBEAN-197
 Project: XBean
  Issue Type: New Feature
  Components: finder
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.9




--
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: Trunk beta release

[David Blevins]

It would be great if we could release 3.1.1-SNAPSHOT.  Transaction failure 
getCause() is a long awaited feature.


On Aug 29, 2011, at 12:35 AM, Shawn Jiang wrote:

 Forward this to geronimo community too.
 
 Do we want to pick up the fixes in Geronimo Connector 3.1.1-SNAPSHOT  for
 coming geronimo 3.0 beta release ?
 
 On Sun, Aug 28, 2011 at 6:36 PM, Jonathan Gallimore 
 jonathan.gallim...@gmail.com wrote:
 
 Swapped over to Geronimo connector 3.1 - most stuff looks ok, but the
 TransactionRollbackCauseTest unit test fails with this earlier version. We
 had previously upgraded to 2.2.2-SNAPSHOT to support the rollback cause:
 http://svn.apache.org/viewvc?view=revisionrevision=1097964 - I then
 upgraded to 3.1.1-SNAPSHOT after that.
 
 What's the view here - should we go for 3.1 and change/comment out the test
 until a newer connector is published, or is it preferably to try and get a
 newer version of the connector published.
 
 Jon
 
 On Sat, Aug 27, 2011 at 8:45 AM, Jonathan Gallimore 
 jonathan.gallim...@gmail.com wrote:
 
 I'll give trunk a try with connector 3.1.1 today and report back. I did a
 fair bit of work on the connector support in openejb, and just went for
 the
 latest snapshot of geronimo connector at the time. I think 3.1.1 will
 probably be fine.
 
 If everyone is happy then I'll kick of the release process for a beta
 once
 xbean is published. Please shout if there's any problem with that.
 
 Jon
 On Aug 27, 2011 2:13 AM, Shawn Jiang genspr...@gmail.com wrote:
 Thank you for volunteering ! Geronimo will publish xbean soon. But is
 connector 3.1.1-SNAPSHOT a must-have ?
 
 can we use connector 3.1.1 for the openejb beta for now ?
 
 -- Forwarded message --
 From: Shawn Jiang genspr...@gmail.com
 Date: Sat, Aug 27, 2011 at 9:11 AM
 Subject: Re: Trunk beta release
 To: d...@openejb.apache.org, dev@geronimo.apache.org
 
 
 Thank you for volunteering ! Geronimo will publish xbean soon. But is
 connector 3.1.1-SNAPSHOT
 
 
 On Sat, Aug 27, 2011 at 3:06 AM, Jonathan Gallimore 
 jonathan.gallim...@gmail.com wrote:
 
 I think it would be great to get some kind of alpha/beta/milestone
 release
 out.
 
 We deliberately keep the examples on a different version number to
 openejb,
 as there shouldn't be any dependency there, but we create an examples
 zip
 at
 release time as well as everything else I believe.
 
 I'm not too sure about javaee-api - obviously it follows the javaee
 version.
 My guess is we could choose to push that at the same time as the
 everything
 else as well.
 
 I think we'd need xbean and geronimo connector publishing first.
 
 I'm happy to volunteer to do the release work, if that's any help.
 
 Jon
 On Aug 26, 2011 7:15 AM, Shawn Jiang genspr...@gmail.com wrote:
 Anyway, let's start to do this and figure how rough the trunk is
 step
 by
 step. the first step would be to clean the snapshot depencencies up:
 
 xbeanVersion3.8-SNAPSHOT/xbeanVersion
 
 
 
 
 org.apache.openwebbeans.version1.1.1-SNAPSHOT/org.apache.openwebbeans.version
 
 geronimo.connector.version3.1.1-SNAPSHOT/geronimo.connector.version
 
 
 There are also some internal compoents that are using different
 version
 then
 4.0.0-SNAPSHOT.
 
 javaee-api.version6.0-SNAPSHOT/javaee-api.version
 
 some samples in trunk are using 1.1-SNAPSHOT, But I can find part of
 them
 are still 1.0-SNAPSHOT.
 
 I'm not sure what's the pratice to release javaee-api and samples
 when
 they
 don't share the same version with trunk.
 
 
 
 
 
 
 
 
 On Fri, Aug 26, 2011 at 1:58 PM, David Blevins 
 david.blev...@gmail.com
 wrote:
 
 I suspect that even if we get started now, it will still be a few
 weeks
 before we see anything. It's been over a year on trunk with no
 release.
 It's going to be rough.
 
 Best case scenario, we get two releases out before October. Worst
 case
 scenario, we wait too long to start and don't get any.
 
 -David
 
 On Aug 25, 2011, at 10:49 PM, Shawn Jiang wrote:
 
 Don't know if geronimo can wait until javaone. We could release a
 openejb
 m1/beta1, and then release a m2/beta2 for javaone.
 
 On Fri, Aug 26, 2011 at 12:21 PM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:
 
 maybe we should wait just before javaone?
 
 - Romain
 
 2011/8/26 Shawn Jiang genspr...@gmail.com
 
 Geronimo is going to make a beta release. Let's discuss a
 openejb
 trunk
 release again.
 
 On Tue, Jul 12, 2011 at 9:00 AM, David Blevins 
 david.blev...@gmail.com
 wrote:
 
 Would be excellent if we could get a beta ready before this
 presentation
 on
 the 25th:
 
 http://www.oscon.com/oscon2011/public/schedule/detail/20105
 
 Might be kind of tight, but ideally there would be at least
 something
 there
 for people to download and play with.
 
 -David
 
 
 
 
 
 
 
 --
 Shawn
 
 
 
 
 
 --
 Shawn
 
 
 
 
 --
 Shawn
 
 
 
 
 --
 Shawn
 
 
 
 --
 Shawn
 
 
 
 
 
 -- 
 Shawn

[jira] [Updated] (GERONIMO-6122) Support Stateless and Singleton EJB as JAX-RS root resource classes, providers and Application subclasses

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins updated GERONIMO-6122:


Summary: Support Stateless and Singleton EJB as JAX-RS root resource 
classes, providers and Application subclasses  (was: Support Stateless and 
Statefull EJB as JAX-RS root resource classes, providers and Application 
subclasses)

 Support Stateless and Singleton EJB as JAX-RS root resource classes, 
 providers and Application subclasses
 -

 Key: GERONIMO-6122
 URL: https://issues.apache.org/jira/browse/GERONIMO-6122
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: javaee6
Affects Versions: 3.0
Reporter: viola.lu
Assignee: Ivan
Priority: Minor
 Fix For: 3.0.1


 From JAX-RS spec 1.1
 In a product that also supports EJB, an implementation MUST support use of 
 stateless and singleton
 session beans as root resource classes, providers and Application subclasses. 
 JAX-RS annotations
 MAY be applied to a bean's local interface or directly to a no-interface 
 bean. If an Exception-
 Mapper for a EJBException or subclass is not included with an application 
 then exceptions thrown
 by an EJB resource class or provider method MUST be treated as EJB 
 application exceptions: the
 embedded cause of the EJBException MUST be unwrapped and processed as 
 described in section
 3.3.4.
 Now geronimo recognize javax.ws.rs.URIinfo as EJB resource in a stateless 
 EJB, so failed to get Uriinfo
 Run Restfulorder samples can give more details.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: BVal and searchWiredBudles=false

[David Blevins]

That was perfect, btw.  Thanks so much!

I really love that whole bundles setup.  Being able to patch a file or two is 
so incredibly useful.


-David

On Aug 24, 2011, at 10:25 PM, Rex Wang wrote:

 commit At revision: 1161387
 Please check if that is what you want.
 
 -Rex
 
 2011/8/25 David Blevins david.blev...@gmail.com
 Checked in a potential fix for the bean validation tests that fail with the 
 following issue:
 
java.lang.NullPointerException
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:626)
at 
 org.apache.bval.jsr303.xml.ValidationParser.getSchema(ValidationParser.java:144)
 
 Fixed version does no classpath scanning for the schema:
 
   
 https://svn.apache.org/repos/asf/geronimo/bundles/trunk/bval-jsr303/src/main/java/org/apache/bval/jsr303/xml/ValidationParser.java
 
 I don't think I setup the bundle correctly as it pulls in all the transitive 
 dependencies, which is definitely not right.  If someone can take a peek, 
 that would be great.
 
 -David
 
 
 
 
 -- 
 Lei Wang (Rex)
 rwonly AT apache.org

BVal and searchWiredBudles=false

[David Blevins]

Checked in a potential fix for the bean validation tests that fail with the 
following issue:

java.lang.NullPointerException
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:626)
at 
org.apache.bval.jsr303.xml.ValidationParser.getSchema(ValidationParser.java:144)

Fixed version does no classpath scanning for the schema:

   
https://svn.apache.org/repos/asf/geronimo/bundles/trunk/bval-jsr303/src/main/java/org/apache/bval/jsr303/xml/ValidationParser.java

I don't think I setup the bundle correctly as it pulls in all the transitive 
dependencies, which is definitely not right.  If someone can take a peek, that 
would be great.

-David

Re: svn commit: r1096951 [6/6] - in /geronimo/server/trunk: ./ framework/ framework/assemblies/ framework/assemblies/geronimo-framework/ framework/buildsupport/car-maven-plugin/src/main/filtered-resou

[David Blevins]

Followed up with Infra and we're using the better part of 67GB of /tmp in 
buildbot (around 50GB).

Will add the fix back in tomorrow.

-David

On Aug 19, 2011, at 5:27 PM, David Jencks wrote:

 I'm not sure how this got removed, but this is in what turned into the 
 3.0-osgi branch, not current trunk.  I guess I should investigate since I've 
 been working with that code some more
 
 david jencks
 
 On Aug 19, 2011, at 4:50 PM, David Blevins wrote:
 
 David,
 
 Any info on why this was removed?  Guessing it was just a side effect of a 
 merge.
 
 (related jira https://issues.apache.org/jira/browse/GERONIMO-5888)
 
 
 -David
 
 On Apr 26, 2011, at 4:19 PM, djen...@apache.org wrote:
 
 Modified: 
 geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java?rev=1096951r1=1096950r2=1096951view=diff
 ==
 --- 
 geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java
  (original)
 +++ 
 geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java
  Tue Apr 26 23:18:49 2011
 @@ -30,7 +30,6 @@ import java.io.OutputStream;
 import java.io.OutputStreamWriter;
 import java.net.MalformedURLException;
 import java.net.URL;
 -import java.util.ArrayList;
 import java.util.Collection;
 import java.util.Collections;
 import java.util.Enumeration;
 @@ -38,7 +37,6 @@ import java.util.HashMap;
 import java.util.LinkedHashMap;
 import java.util.LinkedHashSet;
 import java.util.LinkedList;
 -import java.util.List;
 import java.util.Map;
 import java.util.Set;
 import java.util.jar.JarFile;
 @@ -83,7 +81,6 @@ public class FileUtils {
   File tempDir = File.createTempFile(geronimo-fileutils, .tmpdir);
   tempDir.delete();
   tempDir.mkdirs();
 -deleteOnExit(tempDir);
   return tempDir;
   }
 
 @@ -412,37 +409,4 @@ public class FileUtils {
 
   private FileUtils() {
   }
 -
 -// Shutdown hook for recurssive delete on tmp directories
 -static final ListString delete = new ArrayListString();
 -
 -static {
 -Runtime.getRuntime().addShutdownHook(new Thread(){
 -@Override
 -public void run() {
 -delete();
 -}
 -});
 -}
 -
 -private static void deleteOnExit(File file) {
 -delete.add(file.getAbsolutePath());
 -}
 -
 -private static void delete() {
 -for (String path : delete) {
 -delete(new File(path));
 -}
 -}
 -
 -private static void delete(File file) {
 -if (file.isDirectory()) {
 -for (File f : file.listFiles()) {
 -delete(f);
 -}
 -}
 -
 -file.delete();
 -}
 -
 }
 
 
 

[jira] [Created] (GERONIMO-6117) OpenWebBeansPlugin load optimization

[David Blevins (JIRA)]

OpenWebBeansPlugin load optimization


 Key: GERONIMO-6117
 URL: https://issues.apache.org/jira/browse/GERONIMO-6117
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: OpenEJB, OpenWebBeans
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.0-M2




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java

[David Blevins]

On Aug 22, 2011, at 9:25 AM, Kevan Miller wrote:

 
 On Aug 22, 2011, at 12:45 AM, dblev...@apache.org wrote:
 
 Author: dblevins
 Date: Mon Aug 22 04:45:07 2011
 New Revision: 1160106
 
 URL: http://svn.apache.org/viewvc?rev=1160106view=rev
 Log:
 GERONIMO-6117: OpenWebBeansPlugin load optimization
 
 Modified:
   
 geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
 
 
 Cool. With this change and setting 
 BundleResourceHelper.searchWiredBundles=false (e.g. 
 GERONIMO_OPTS=-Dorg.apache.xbean.osgi.bundle.util.BundleResourceHelper.searchWiredBundles=false
  ./geronimo run), my server starts without a problem and startup is pretty 
 good. Tthe timed portion (so doesn't count the initial karaf loading) is 9-10 
 seconds:
 
 ...
 Module 63/63 org.apache.geronimo.configs/wink-deployer/3.0-SNAPSHOT/car   
started in   .015s
 Startup completed in 9.105s seconds
  Listening on Ports:
 ...
 
 Which is great, given that we're not doing any lazy startup. However, I'm 
 seeing some bean-validation tck failures with searchWiredBundles=false (jcdi 
 tck looks fine and I didn't try any other tck tests). Anybody able to take a 
 look at this?

Looked into it a bit.

Most the BVal tests seem to be failing due to classLoader.getResource() calls 
in Apache BVal looking for schemas.  Probably there's some way we could work 
around that as we already have logic for this in BValModuleBuilderExtension.

There is one failure however that will not pass with 
BundleResourceHelper.searchWiredBundles=false ... at least not the way it's 
implemented.  ValidationProviderResolverTest is implementing its own provider 
search and verifying it works.  Better said they're executing:

classloader.getResources(META-INF/services/ + 
ValidationProvider.class.getName());

And verifying that there is at least one provider found.  Our version of that 
API has been extended to support more OSGi friendly search mechanisms -- the 
code Rick wrote.

The options as I see them:

  1. challenge the test
  2. Don't use BundleResourceHelper.searchWiredBundles=false and live with the 
performance we have
  3. Make the BundleResourceHelper.searchWiredBundles functionality more 
configurable so validation API can be exempt from limited search
  4. Physically add a META-INF/services/javax.validation.spi.ValidationProvider 
file to apps
  5. Somehow intercept calls to getResources(foo) and do like we did with the 
ServiceLoader searching of OWB and supply known implementations up front.  Not 
sure if that is even possible in this situation.

Open to ideas.

-David

Re: svn commit: r1096951 [6/6] - in /geronimo/server/trunk: ./ framework/ framework/assemblies/ framework/assemblies/geronimo-framework/ framework/buildsupport/car-maven-plugin/src/main/filtered-resou

[David Blevins]

David,

Any info on why this was removed?  Guessing it was just a side effect of a 
merge.

(related jira https://issues.apache.org/jira/browse/GERONIMO-5888)


-David

On Apr 26, 2011, at 4:19 PM, djen...@apache.org wrote:

 Modified: 
 geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java?rev=1096951r1=1096950r2=1096951view=diff
 ==
 --- 
 geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java
  (original)
 +++ 
 geronimo/server/trunk/framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/util/FileUtils.java
  Tue Apr 26 23:18:49 2011
 @@ -30,7 +30,6 @@ import java.io.OutputStream;
 import java.io.OutputStreamWriter;
 import java.net.MalformedURLException;
 import java.net.URL;
 -import java.util.ArrayList;
 import java.util.Collection;
 import java.util.Collections;
 import java.util.Enumeration;
 @@ -38,7 +37,6 @@ import java.util.HashMap;
 import java.util.LinkedHashMap;
 import java.util.LinkedHashSet;
 import java.util.LinkedList;
 -import java.util.List;
 import java.util.Map;
 import java.util.Set;
 import java.util.jar.JarFile;
 @@ -83,7 +81,6 @@ public class FileUtils {
 File tempDir = File.createTempFile(geronimo-fileutils, .tmpdir);
 tempDir.delete();
 tempDir.mkdirs();
 -deleteOnExit(tempDir);
 return tempDir;
 }
 
 @@ -412,37 +409,4 @@ public class FileUtils {
 
 private FileUtils() {
 }
 -
 -// Shutdown hook for recurssive delete on tmp directories
 -static final ListString delete = new ArrayListString();
 -
 -static {
 -Runtime.getRuntime().addShutdownHook(new Thread(){
 -@Override
 -public void run() {
 -delete();
 -}
 -});
 -}
 -
 -private static void deleteOnExit(File file) {
 -delete.add(file.getAbsolutePath());
 -}
 -
 -private static void delete() {
 -for (String path : delete) {
 -delete(new File(path));
 -}
 -}
 -
 -private static void delete(File file) {
 -if (file.isDirectory()) {
 -for (File f : file.listFiles()) {
 -delete(f);
 -}
 -}
 -
 -file.delete();
 -}
 -
 }
 

[jira] [Created] (XBEAN-179) File path / URL decoding issue for paths with +

[David Blevins (JIRA)]

File path / URL decoding issue for paths with +
---

 Key: XBEAN-179
 URL: https://issues.apache.org/jira/browse/XBEAN-179
 Project: XBean
  Issue Type: Bug
Affects Versions: 3.7, 3.4.2, 3.4.1, 3.4
Reporter: David Blevins
Assignee: David Blevins


Specifically affects OSX which likes to create tmp directories with + sign in 
them

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-6090) Don't scan for EE Injections in a CDI application in metadata complete web module

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069315#comment-13069315
 ] 

David Blevins commented on GERONIMO-6090:
-

CDI TCK got a little grouchy :)  Poking at it in a debugger.  Did the EE TCK 
results look ok?


  
testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest)
  
testInjectionOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest)
  
testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
  
testInjectionOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
  
testInjectionOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
  
testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
  
testPassivatingResource(org.jboss.jsr299.tck.tests.implementation.simple.resource.resource.InjectionOfResourceTest)
  
testInjectionOfResource(org.jboss.jsr299.tck.tests.implementation.simple.resource.resource.InjectionOfResourceTest)
  
testProduceResourceProxy(org.jboss.jsr299.tck.tests.implementation.simple.resource.resource.InjectionOfResourceTest)
  
testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest)


 Don't scan for EE Injections in a CDI application in metadata complete web 
 module
 -

 Key: GERONIMO-6090
 URL: https://issues.apache.org/jira/browse/GERONIMO-6090
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.0-M2

 Attachments: 
 0005-GERONIMO-6090-Limit-web-beans-annotation-scan-scope.patch




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-6090) Don't scan for EE Injections in a CDI application in metadata complete web module

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069332#comment-13069332
 ] 

David Blevins commented on GERONIMO-6090:
-

Checked in a fix, seems to do the trick with the tests that I ran.  Running a 
full run now.  Fingers crossed! :)

 Don't scan for EE Injections in a CDI application in metadata complete web 
 module
 -

 Key: GERONIMO-6090
 URL: https://issues.apache.org/jira/browse/GERONIMO-6090
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.0-M2

 Attachments: 
 0005-GERONIMO-6090-Limit-web-beans-annotation-scan-scope.patch




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (GERONIMO-6090) Don't scan for EE Injections in a CDI application in metadata complete web module

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved GERONIMO-6090.
-

Resolution: Fixed

 Don't scan for EE Injections in a CDI application in metadata complete web 
 module
 -

 Key: GERONIMO-6090
 URL: https://issues.apache.org/jira/browse/GERONIMO-6090
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.0-M2

 Attachments: 
 0005-GERONIMO-6090-Limit-web-beans-annotation-scan-scope.patch




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (GERONIMO-6089) Support for CDI beans in ear lib directory

[David Blevins (JIRA)]

Support for CDI beans in ear lib directory
--

 Key: GERONIMO-6089
 URL: https://issues.apache.org/jira/browse/GERONIMO-6089
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.0-M2




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (GERONIMO-6090) Don't scan for EE Injections in a CDI application in metadata complete web module

[David Blevins (JIRA)]

Don't scan for EE Injections in a CDI application in metadata complete web 
module
-

 Key: GERONIMO-6090
 URL: https://issues.apache.org/jira/browse/GERONIMO-6090
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 3.0-M2




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Geronimo Transaction Manager version 2.2.2

[David Blevins]

+1

On Jul 18, 2011, at 6:09 AM, Jacek Laskowski wrote:

 Hi,
 
 Note: This is my first release ever so provide guidance where needed.
 
 The release of Geronimo Transaction Manager version 2.2.2 is to ship
 OpenEJB 3.2.0 as it currently depends on 2.2-SNAPSHOT.
 
 The fixes in this release are:
 GERONIMO-5754 Timing window when removing expired connections
 GERONIMO-5742 NPE in MultiPoolConnectionInterceptor.returnConnection
 with non-zero minPoolSize
 GERONIMO-4576 Make persistence exceptions more visible to client
 GERONIMO-6029 Upgrade slf4j api version to one that correctly does not
 require the impl
 
 The artifacts up for vote are:
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/components/geronimo-connector/2.2.2/geronimo-connector-2.2.2.jar
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/components/geronimo-transaction/2.2.2/geronimo-transaction-2.2.2.jar
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/components/geronimo-txmanager-parent/2.2.2/geronimo-txmanager-parent-2.2.2-source-release.zip
 
 The staging repository is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/
 
 The source tag is:
 https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.2.2/
 
 Vote will be open for 72 hours (starting 3 PM CET = GMT+1).
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 Jacek
 
 -- 
 Jacek Laskowski
 Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
 Warszawa JUG conference = Confitura (formerly Javarsovia) :: 
 http://confitura.pl

Re: [VOTE] Release new bundle components.

[David Blevins]

+1


On Jul 18, 2011, at 6:54 AM, Shawn Jiang wrote:

 This is a single vote for releasing 6 new Geronimo bundles that are OSGi 
 versions of other jar files.  The wrappered jars are
 
woodstox-core-asl 4.1.1_1
jaxb-impl 2.2.3-1_1   
scout 1.2.3_1
saaj-impl 1.3.8_1
axis 1.4_2
axiom-all 1.2.12_1
 
 
The components up for vote are:



 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/woodstox-core-asl/4.1.1_1/woodstox-core-asl-4.1.1_1-source-release.zip

 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/woodstox-core-asl/4.1.1_1/woodstox-core-asl-4.1.1_1-source-release.tar.gz


 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/jaxb-impl/2.2.3-1_1/jaxb-impl-2.2.3-1_1-source-release.zip

 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/jaxb-impl/2.2.3-1_1/jaxb-impl-2.2.3-1_1-source-release.tar.gz


 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/scout/1.2.3_1/scout-1.2.3_1-source-release.zip

 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/scout/1.2.3_1/scout-1.2.3_1-source-release.tar.gz


 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/saaj-impl/1.3.8_1/saaj-impl-1.3.8_1-source-release.zip

 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/saaj-impl/1.3.8_1/saaj-impl-1.3.8_1-source-release.tar.gz


 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/axis/1.4_2/axis-1.4_2-source-release.zip

 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/axis/1.4_2/axis-1.4_2-source-release.tar.gz


 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/axiom-all/1.2.12_1/axiom-all-1.2.12_1-source-release.zip

 https://repository.apache.org/content/repositories/orgapachegeronimo-002/org/apache/geronimo/bundles/axiom-all/1.2.12_1/axiom-all-1.2.12_1-source-release.tar.gz

 
 
The staging repository is:
 
https://repository.apache.org/content/repositories/orgapachegeronimo-002/
 
 
The source repos are:
 

 https://svn.apache.org/repos/asf/geronimo/bundles/tags/woodstox-core-asl-4.1.1_1
https://svn.apache.org/repos/asf/geronimo/bundles/tags/jaxb-impl-2.2.3-1_1
https://svn.apache.org/repos/asf/geronimo/bundles/tags/scout-1.2.3_1
https://svn.apache.org/repos/asf/geronimo/bundles/tags/saaj-impl-1.3.8_1
https://svn.apache.org/repos/asf/geronimo/bundles/tags/axis-1.4_2
https://svn.apache.org/repos/asf/geronimo/bundles/tags/axiom-all-1.2.12_1
 
 Vote will be open for 72 hours.
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 -- 
 Shawn

Re: less-osgi-friendly code drop

[David Blevins]

On Jul 13, 2011, at 10:10 PM, David Jencks wrote:

 
 On Jul 13, 2011, at 9:46 PM, David Blevins wrote:
 
 
 On Jul 11, 2011, at 12:54 AM, David Jencks wrote:
 
 testSpecializedBeanNotInstantiated(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest)
 testSpecializingBeanHasBindingsOfSpecializedAndSpecializingBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
 testSpecializingBeanHasNameOfSpecializedBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
 testSpecializingClassDirectlyExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsNothing.DirectlyExtendsNothingTest)
 testSpecializingClassDirectlyExtendsSimpleBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest)
 testSpecializingClassImplementsInterfaceAndExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.implementInterfaceAndExtendsNothing.ImplementsInterfaceAndExtendsNothingTest)
 testSpecializingAndSpecializedBeanHasName(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.sameName.SameNameTest)
 
 Have all but 3 of these passing in the embedded container in my local copy.  
 The 3 that fail are broken ones.  Simply need to add validation for those. 
  My impl code is a bit hacked -- currently only works for @Stateful and not 
 exactly implemented in the right spot -- but otherwise looks like a good 
 approach.  Will clean it up and check it in tomorrow.
 
 
 
 Excellent!  On the geronimo side I've changed things around so that we have 
 one openejb appInfo tree for the entire application and use it to set up the 
 owb context.  This _ought_ to fix the problem in g. that I was seeing that 
 the owb context didn't include any of the specialized classes (since it was 
 looking at only one of the modules in the ear).  However I'm still cleaning 
 up loose ends so apps will deploy ok :-)

Checked in my specialization code to OWB and OpenEJB.  It fixes things in the 
embedded container (sans the three 'broken' tests). Still seeing them fail in G 
though.

Hacking up the validation logic for the 'broken' tests now.


-David

[jira] [Commented] (GERONIMO-6038) testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonCo

[David Blevins (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065672#comment-13065672
 ] 

David Blevins commented on GERONIMO-6038:
-

public class Cruiser implements Ship
{

   @EJB
   MissileLocal missile;   never injected

   public void defend()
   {
  missile.fire();
   }
}


 testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest)
 --

 Key: GERONIMO-6038
 URL: https://issues.apache.org/jira/browse/GERONIMO-6038
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
Reporter: David Blevins
Assignee: David Blevins



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: buildbot failure in ASF Buildbot on geronimo-server-trunk

[David Blevins]

Likely the snapshots are out of date.  Poking buildbot to publish new ones 
now

-David

On Jul 13, 2011, at 1:11 AM, Rex Wang wrote:

 Not me.. anyone see this?
 
 java.lang.NoClassDefFoundError: org/apache/openejb/jee/Application
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:383)
 
 
   at 
 org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:326)
 
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:233)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
 
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
 
 
   at 
 org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
 
   at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:879)
 
 
   at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
 
   at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:524)
   at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:340)
 
 
   at 
 org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:235)
 
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 
 
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 
 
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
 
 
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
 
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 
 
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 
   at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 
 
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 
 
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.openejb.jee.Application
 
 
   at 
 org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:772)
 
   at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
   at 
 org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
 
 
   at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
 
   at 
 org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:634)
   at 
 org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99)
 
 
   at 
 org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1345)
 
   at 
 org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:711)
   at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
 
 
   at 
 org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
 
   at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
   ... 33 more
 
 
 2011/7/13 build...@apache.org
 The Buildbot has detected a new failure on builder geronimo-server-trunk 
 while building ASF Buildbot.
 Full details are available at:
  http://ci.apache.org/builders/geronimo-server-trunk/builds/186
 
 Buildbot URL: http://ci.apache.org/
 
 Buildslave for this Build: hemera_ubuntu
 
 Build Reason: scheduler
 Build Source Stamp: [branch geronimo/server/trunk] 1145895
 Blamelist: rwonly
 
 BUILD FAILED: failed compile
 
 sincerely,
  -The Buildbot
 
 
 
 
 -- 
 Lei Wang (Rex)
 rwonly AT apache.org

Re: less-osgi-friendly code drop

[David Blevins]

On Jul 11, 2011, at 12:54 AM, David Jencks wrote:

  
 testSpecializedBeanNotInstantiated(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest)
  
 testSpecializingBeanHasBindingsOfSpecializedAndSpecializingBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
  
 testSpecializingBeanHasNameOfSpecializedBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
  
 testSpecializingClassDirectlyExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsNothing.DirectlyExtendsNothingTest)
  
 testSpecializingClassDirectlyExtendsSimpleBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest)
  
 testSpecializingClassImplementsInterfaceAndExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.implementInterfaceAndExtendsNothing.ImplementsInterfaceAndExtendsNothingTest)
  
 testSpecializingAndSpecializedBeanHasName(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.sameName.SameNameTest)

Have all but 3 of these passing in the embedded container in my local copy.  
The 3 that fail are broken ones.  Simply need to add validation for those.  
My impl code is a bit hacked -- currently only works for @Stateful and not 
exactly implemented in the right spot -- but otherwise looks like a good 
approach.  Will clean it up and check it in tomorrow.


-David

[jira] [Resolved] (GERONIMO-6032) testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved GERONIMO-6032.
-

Resolution: Fixed

 testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)
 --

 Key: GERONIMO-6032
 URL: https://issues.apache.org/jira/browse/GERONIMO-6032
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
Reporter: David Blevins
Assignee: David Blevins



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (GERONIMO-6033) testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)

[David Blevins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Blevins resolved GERONIMO-6033.
-

Resolution: Won't Fix

This will go away with the merge of David Jencks' OSGi friendly code that 
always uses OpenEJB with OpenWebBeans and CDI.

 testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)
 -

 Key: GERONIMO-6033
 URL: https://issues.apache.org/jira/browse/GERONIMO-6033
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
Reporter: David Blevins



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (GERONIMO-6062) XBean 3.8-SNAPSHOT

[David Blevins (JIRA)]

XBean 3.8-SNAPSHOT
--

 Key: GERONIMO-6062
 URL: https://issues.apache.org/jira/browse/GERONIMO-6062
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public (Regular issues)
Reporter: David Blevins




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (GERONIMO-6061) Geronimo 3.0 trunk SNAPSHOT dependencies

[David Blevins (JIRA)]

Geronimo 3.0 trunk SNAPSHOT dependencies


 Key: GERONIMO-6061
 URL: https://issues.apache.org/jira/browse/GERONIMO-6061
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
Reporter: David Blevins
 Fix For: 3.0-M2




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira