Re: Yoko used in IBM WAS Liberty server

[Alan D. Cabrera]

So sorry about the egregious delay in my reply.  :(

> On Jul 30, 2015, at 10:53 AM, David Jencks  wrote:
> 
> I am pleased to finally be able to announce that the Yoko orb is now used in 
> IBM’s WAS Liberty application server, the first EE 7 certified application 
> server available for use in production.
> 
> As part of this effort several of us at IBM have made some bug fixes, 
> enhancements, and new features including
> 
> - naming service that can be run on the “main” orb
> - support for newer java constructs such as enums and corba constructs such 
> as the new custom marshaling format
> - improved concurrency support
> - better osgi-ification
> - update to java 7

Wow, congrats!

> We finally have both time and approval to contribute these fixes back to 
> apache.

Awesome!

> I’m going to start by opening jira issues for the code changes.  In addition 
> I’d like to suggest that we move yoko to git.  

That sounds great.  I love git, but now you’re going to make me slog through 
those god forsaken git threads; sigh, the things I do for the ASF.  Let’s plan 
on moving it to git.  By the way, how will this affect our CI and TCK machinery?


Regards,
Alan

Board report time 2015-11

[Alan D. Cabrera]

Here's the report that I sent to the board:

https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2015-18+-+November
 


If I missed something please let me know directly.  I’m sorry about being so 
tardy with the report.


Regards,
Alan

Re: [VOTE] geronimo-javamail_1.4 1.9.0-alpha-2

[Alan D. Cabrera]

+1

Tag builds fine, signatures and hashes match.


Regards,
Alan

> On Sep 23, 2015, at 10:51 PM, Romain Manni-Bucau  
> wrote:
> 
> Hi guys,
> 
> I'd like to release geronimo javamail 1.4, main reason is it is not usable 
> with some SMTP server using 1.8.x and 1.9.0-apha-1 had some bundling issues 
> with james classes.
> 
> The SMTP issue is https://issues.apache.org/jira/browse/GERONIMO-6547 
> 
> 
> here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1023/ 
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> here is my +1
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Github  
> | LinkedIn  | Tomitriber 
> 

Board report time 2015-07

[Alan D. Cabrera]

Here's the report that I sent to the board:

https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2015-07+-+July
 


If I missed something please let me know directly.  I’m sorry about being so 
tardy with the report.


Regards,
Alan 

Re: Board report time 2015-04

[Alan D. Cabrera]

I agree, we should start moving our focus.

When you speak of #2, what bits do you speak of?  The glue that assembles the 
various JSR implementations of the JEE spec?

I wonder if we should start a total re-write.  We’ve learned a thing or two 
since this project started and the current Zeitgeist for server software has 
moved on.

I think it’s an exciting time to take a fresh look at Geronimo and to 
“re-imagine” it.  If you all agree, what to keep and what to re-write? 


Regards,
Alan

> On Apr 6, 2015, at 7:50 AM, Mark Struberg  wrote:
> 
> Txs Alan!
> 
> 
> I think we should probably move our focus finally? The Geronimo project 
> basically consists of 2 different things.
> 1.) the Geronimo EE server
> 2.) all the rest ;)
> 
> 2 is doing really fine. 1 is worrying. Or are there any significant people 
> interested in continueing with 1?
> 
> Should we reflect this in the report?
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 04.04.2015 um 20:36 schrieb Alan D. Cabrera :
>> 
>> Here's my initial draft:
>> 
>> https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2015-04+-+April
>> 
>> If I missed something please let me know or go ahead and update the page 
>> directly.
>> 
>> 
>> Regards,
>> Alan
>> 
> 

Re: [VOTE] JMS 2 API alpha-2

[Alan D. Cabrera]

Thanks, just making sure my report is correct. :)


Regards,
Alan

> On Apr 6, 2015, at 12:34 PM, Romain Manni-Bucau  wrote:
> 
> Yes they have been
> 
> 
> 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/>
> 2015-04-06 21:21 GMT+02:00 Alan D. Cabrera  <mailto:l...@toolazydogs.com>>:
> We need to follow up w/ a [RESULT].  Did the artifacts get pushed out?
> 
> 
> Regards,
> Alan
> 
> 
>> On Apr 6, 2015, at 8:12 AM, Romain Manni-Bucau > <mailto:rmannibu...@gmail.com>> wrote:
>> 
>> Think i did then
>> 
>> Le 6 avr. 2015 16:49, "Mark Struberg" > <mailto:strub...@yahoo.de>> a écrit :
>> Remain sent the tally but forgot to change the subject to [RESULT].
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>> > Am 05.04.2015 um 16:46 schrieb Alan D. Cabrera > > <mailto:l...@toolazydogs.com>>:
>> >
>> > I was scanning the mailing lists and I don’t think that saw the result.  I 
>> > double checked and found it.  :)
>> >
>> >
>> > Regards,
>> > Alan
>> >
>> >> On Apr 5, 2015, at 12:59 AM, Romain Manni-Bucau > >> <mailto:rmannibu...@gmail.com>> wrote:
>> >>
>> >> Done AFAIK
>> >>
>> >> Le 4 avr. 2015 21:41, "Alan D. Cabrera" > >> <mailto:l...@toolazydogs.com>> a écrit :
>> >> Time to wrap up this vote?  :)
>> >>
>> >>
>> >> Regards,
>> >> Alan
>> >>
>> >> > On Feb 13, 2015, at 10:25 AM, Alan D. Cabrera > >> > <mailto:l...@toolazydogs.com>> wrote:
>> >> >
>> >> > I imagine since this is an alpha release we won’t be creating a tag.  
>> >> > Can you at least tell us the svn revision?
>> >> >
>> >> > +1 - binding
>> >> >
>> >> >
>> >> >> On Feb 12, 2015, at 12:43 PM, Romain Manni-Bucau 
>> >> >> mailto:rmannibu...@gmail.com>> wrote:
>> >> >>
>> >> >> Hello guys,
>> >> >>
>> >> >> As stated in the other thread here the vote for the
>> >> >> geronimo-jms_2.0_spec module with the fixes from Martyn included.
>> >> >>
>> >> >> Here is the staging repo:
>> >> >> https://repository.apache.org/content/repositories/orgapachegeronimo-1013/
>> >> >>  
>> >> >> <https://repository.apache.org/content/repositories/orgapachegeronimo-1013/>
>> >> >>
>> >> >>
>> >> >> My key can be found as last time at
>> >> >> https://svn.apache.org/repos/asf/geronimo/KEYS 
>> >> >> <https://svn.apache.org/repos/asf/geronimo/KEYS>
>> >> >>
>> >> >> please VOTE
>> >> >> [+1] all fine, ship it
>> >> >> [+0] don't care
>> >> >> [-1] stop, because ${reason}
>> >> >>
>> >> >> here is my +1
>> >> >>
>> >> >>
>> >> >> Romain Manni-Bucau
>> >> >> @rmannibucau
>> >> >> http://www.tomitribe.com <http://www.tomitribe.com/>
>> >> >> http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>
>> >> >> https://github.com/rmannibucau <https://github.com/rmannibucau>
>> >> >
>> >>
>> >
>> 
> 
> 

Re: [VOTE] JMS 2 API alpha-2

[Alan D. Cabrera]

We need to follow up w/ a [RESULT].  Did the artifacts get pushed out?


Regards,
Alan


> On Apr 6, 2015, at 8:12 AM, Romain Manni-Bucau  wrote:
> 
> Think i did then
> 
> Le 6 avr. 2015 16:49, "Mark Struberg"  <mailto:strub...@yahoo.de>> a écrit :
> Remain sent the tally but forgot to change the subject to [RESULT].
> 
> 
> LieGrue,
> strub
> 
> 
> > Am 05.04.2015 um 16:46 schrieb Alan D. Cabrera  > <mailto:l...@toolazydogs.com>>:
> >
> > I was scanning the mailing lists and I don’t think that saw the result.  I 
> > double checked and found it.  :)
> >
> >
> > Regards,
> > Alan
> >
> >> On Apr 5, 2015, at 12:59 AM, Romain Manni-Bucau  >> <mailto:rmannibu...@gmail.com>> wrote:
> >>
> >> Done AFAIK
> >>
> >> Le 4 avr. 2015 21:41, "Alan D. Cabrera"  >> <mailto:l...@toolazydogs.com>> a écrit :
> >> Time to wrap up this vote?  :)
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >> > On Feb 13, 2015, at 10:25 AM, Alan D. Cabrera  >> > <mailto:l...@toolazydogs.com>> wrote:
> >> >
> >> > I imagine since this is an alpha release we won’t be creating a tag.  
> >> > Can you at least tell us the svn revision?
> >> >
> >> > +1 - binding
> >> >
> >> >
> >> >> On Feb 12, 2015, at 12:43 PM, Romain Manni-Bucau  >> >> <mailto:rmannibu...@gmail.com>> wrote:
> >> >>
> >> >> Hello guys,
> >> >>
> >> >> As stated in the other thread here the vote for the
> >> >> geronimo-jms_2.0_spec module with the fixes from Martyn included.
> >> >>
> >> >> Here is the staging repo:
> >> >> https://repository.apache.org/content/repositories/orgapachegeronimo-1013/
> >> >>  
> >> >> <https://repository.apache.org/content/repositories/orgapachegeronimo-1013/>
> >> >>
> >> >>
> >> >> My key can be found as last time at
> >> >> https://svn.apache.org/repos/asf/geronimo/KEYS 
> >> >> <https://svn.apache.org/repos/asf/geronimo/KEYS>
> >> >>
> >> >> please VOTE
> >> >> [+1] all fine, ship it
> >> >> [+0] don't care
> >> >> [-1] stop, because ${reason}
> >> >>
> >> >> here is my +1
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau
> >> >> http://www.tomitribe.com <http://www.tomitribe.com/>
> >> >> http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>
> >> >> https://github.com/rmannibucau <https://github.com/rmannibucau>
> >> >
> >>
> >
> 

Re: [VOTE] JMS 2 API alpha-2

[Alan D. Cabrera]

I was scanning the mailing lists and I don’t think that saw the result.  I 
double checked and found it.  :)


Regards,
Alan

> On Apr 5, 2015, at 12:59 AM, Romain Manni-Bucau  wrote:
> 
> Done AFAIK
> 
> Le 4 avr. 2015 21:41, "Alan D. Cabrera"  <mailto:l...@toolazydogs.com>> a écrit :
> Time to wrap up this vote?  :)
> 
> 
> Regards,
> Alan
> 
> > On Feb 13, 2015, at 10:25 AM, Alan D. Cabrera  > <mailto:l...@toolazydogs.com>> wrote:
> >
> > I imagine since this is an alpha release we won’t be creating a tag.  Can 
> > you at least tell us the svn revision?
> >
> > +1 - binding
> >
> >
> >> On Feb 12, 2015, at 12:43 PM, Romain Manni-Bucau  >> <mailto:rmannibu...@gmail.com>> wrote:
> >>
> >> Hello guys,
> >>
> >> As stated in the other thread here the vote for the
> >> geronimo-jms_2.0_spec module with the fixes from Martyn included.
> >>
> >> Here is the staging repo:
> >> https://repository.apache.org/content/repositories/orgapachegeronimo-1013/ 
> >> <https://repository.apache.org/content/repositories/orgapachegeronimo-1013/>
> >>
> >>
> >> My key can be found as last time at
> >> https://svn.apache.org/repos/asf/geronimo/KEYS 
> >> <https://svn.apache.org/repos/asf/geronimo/KEYS>
> >>
> >> please VOTE
> >> [+1] all fine, ship it
> >> [+0] don't care
> >> [-1] stop, because ${reason}
> >>
> >> here is my +1
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com <http://www.tomitribe.com/>
> >> http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>
> >> https://github.com/rmannibucau <https://github.com/rmannibucau>
> >
> 

Re: [VOTE] Release geronimo-interceptor-1.2 spec API

[Alan D . Cabrera]

Time to wrap up this vote?  :)


Regards,
Alan

> On Apr 1, 2015, at 1:52 AM, Mark Struberg  wrote:
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-interceptor-1.2_spec-1.0 jar.
> This is an API which implements the interceptor MR-1.2 specification.
> The changes got tested via the ALv2 licensed CDI TCK.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1017/
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1017/org/apache/geronimo/specs/geronimo-interceptor_1.2_spec/1.0/geronimo-interceptor_1.2_spec-1.0-source-release.zip
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> Here is my +1
> 
> LieGrue,
> strub

Board report time 2015-04

[Alan D. Cabrera]

Here's my initial draft:

https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2015-04+-+April
 


If I missed something please let me know or go ahead and update the page 
directly.


Regards,
Alan

Re: [VOTE] JMS 2 API alpha-2

[Alan D. Cabrera]

Time to wrap up this vote?  :)


Regards,
Alan

> On Feb 13, 2015, at 10:25 AM, Alan D. Cabrera  wrote:
> 
> I imagine since this is an alpha release we won’t be creating a tag.  Can you 
> at least tell us the svn revision?
> 
> +1 - binding
> 
> 
>> On Feb 12, 2015, at 12:43 PM, Romain Manni-Bucau  
>> wrote:
>> 
>> Hello guys,
>> 
>> As stated in the other thread here the vote for the
>> geronimo-jms_2.0_spec module with the fixes from Martyn included.
>> 
>> Here is the staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1013/
>> 
>> 
>> My key can be found as last time at
>> https://svn.apache.org/repos/asf/geronimo/KEYS
>> 
>> please VOTE
>> [+1] all fine, ship it
>> [+0] don't care
>> [-1] stop, because ${reason}
>> 
>> here is my +1
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
> 

Re: [VOTE] Release geronimo-annotation-1.2 spec API

[Alan D . Cabrera]

Time to wrap up this vote?  :)


Regards,
Alan

> On Apr 1, 2015, at 1:52 AM, Mark Struberg  wrote:
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-annotation-1.2_spec-1.0 jar.
> This is an API which implements the common-annotations JSR-250 MR-1.2 
> specification.
> The only change was the introduction of @Priority which got tested via the 
> ALv2 licensed CDI TCK.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1016/
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1016/org/apache/geronimo/specs/geronimo-annotation_1.2_spec/1.0/geronimo-annotation_1.2_spec-1.0-source-release.zip
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> Here is my +1
> 
> LieGrue,
> strub

Re: [VOTE] Release geronimo-annotation-1.2 spec API

[Alan D. Cabrera]

+1


Regards,
Alan

> On Apr 1, 2015, at 1:52 AM, Mark Struberg  wrote:
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-annotation-1.2_spec-1.0 jar.
> This is an API which implements the common-annotations JSR-250 MR-1.2 
> specification.
> The only change was the introduction of @Priority which got tested via the 
> ALv2 licensed CDI TCK.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1016/
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1016/org/apache/geronimo/specs/geronimo-annotation_1.2_spec/1.0/geronimo-annotation_1.2_spec-1.0-source-release.zip
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> Here is my +1
> 
> LieGrue,
> strub

Re: [VOTE] Release geronimo-interceptor-1.2 spec API

[Alan D. Cabrera]

+1


Regards,
Alan

> On Apr 1, 2015, at 1:52 AM, Mark Struberg  wrote:
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-interceptor-1.2_spec-1.0 jar.
> This is an API which implements the interceptor MR-1.2 specification.
> The changes got tested via the ALv2 licensed CDI TCK.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1017/
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1017/org/apache/geronimo/specs/geronimo-interceptor_1.2_spec/1.0/geronimo-interceptor_1.2_spec-1.0-source-release.zip
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> Here is my +1
> 
> LieGrue,
> strub

Geronimo on Docker?

[Alan D. Cabrera]

I think that it would be pretty cool if we had Geronimo on Docker.  How would 
we structure our images?


Regards,
Alan

Re: [VOTE] release Apache Geronimo XBean-4.2

[Alan D. Cabrera]

+1


Regards,
Alan

> On Mar 25, 2015, at 3:22 AM, Romain Manni-Bucau  wrote:
> 
> Hi!
> 
> I'd like to release XBean 4.2 to be able to integrate it ASAP in the coming 
> tomee releases.
> 
> It fixes 2 impacting bugs: recursive algorithm (just fails for big jars) and 
> linkParent loosing parent annotations (regression in 4.0 release I think)
> 
> 
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachegeronimo-1015/ 
> 
> 
> The source jar can be found here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1015/org/apache/xbean/xbean/4.2/
>  
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> 
> here is my +1
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Github  
> | LinkedIn  | Tomitriber 
> 

Re: [VOTE] Release geronimo-jcdi-1.1 spec API

[Alan D. Cabrera]

+1


Regards,
Alan

> On Mar 24, 2015, at 3:56 PM, Mark Struberg  wrote:
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-jcdi_1.1_spec-1.0 jar.
> This is an API which implements the CDI-1.1 and 1.2 API and SPI and passes 
> the CDI TCK.
> It also passes the method signature test of CDI-1.2.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1014/
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1014/org/apache/geronimo/specs/geronimo-jcdi_1.1_spec/1.0/geronimo-jcdi_1.1_spec-1.0-source-release.zip
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> here is my +1
> 
> LieGrue,
> strub

ASF Board Report - Initial Reminder for Apr 2015

[Alan D. Cabrera]

This email was sent by an automated system on behalf of the ASF Board.
It is an initial reminder to give you plenty of time to prepare the report.

The meeting is scheduled for Wed, 15 April 2015, 10:30 am PST and the deadline 
for
submitting your report is 1 full week prior to that (Wed, Apr 8th)!

According to board records, you are listed as the chair of at least one
committee that is due to submit a report this month. [1] [2]

Details on which project reports are due and how to submit a report 
are enclosed below.

Please submit your report with sufficient time to allow the board members
to review and digest. Again, the very latest you should submit your report
is 1 full week (7days) prior to the board meeting (Wed, Apr 8th).

If you feel that an error has been made, please consult [1] and if there
is still an issue then contact the board directly.

As always, PMC chairs are welcome to attend the board meeting.

Thanks,
The ASF Board

[1] - https://svn.apache.org/repos/private/committers/board/committee-info.txt 

[2] - https://svn.apache.org/repos/private/committers/board/calendar.txt 

[3] - https://svn.apache.org/repos/private/committers/board/templates 

[4] - https://reporter.apache.org/ 


Submitting your Report
--

Full details about the process and schedule are in [1].

The report should be committed to the meeting agenda in the board directory
in the foundation repository, trying to keep a similar format to the others.
This can be found at:

 https://svn.apache.org/repos/private/foundation/board 


Your report should also be sent in plain-text format to bo...@apache.org 

with a Subject line that follows the below format:

   Subject: [REPORT] Project Name

Cutting and pasting directly from a Wiki is not acceptable due to formatting
issues. Line lengths should be limited to 77 characters.

Chairs may use the Apache Reporter Service [4] to help them compile and
submit a board report.


Resolutions
---

There are several templates for use for various Board resolutions.
They can be found in [3] and you are encouraged to use them. It is
strongly recommended that if you have a resolution before the board,
you are encouraged to attend that board meeting.


ASF Board Reports
-

Reports are due from you for the following committees:

 - Geronimo

Re: Geronimo and jvisualvm

[Alan D. Cabrera]

> On Mar 16, 2015, at 8:02 AM, Marcin Wietecha  
> wrote:
> 
> Hi,
>  
> I am trying to use jvisualvm (profiling tool included to JDK) to check 
> application performance on Geronimo v3.0.
> I use JDK 1.7.0_71. App is web service oriented. However I can’t connect to 
> server through visualvm correctly. 
> Jfluid-server.jar is added to bootstrap classpath, xms, xmx and maxpermsize 
> increased sufficiently, process of app in visualvm is visible. 
>  
> After connecting to it, depending on what I profile I get following errors:
> -start profiling from webservice (request through soapUI):
> ERROR AxisEngine javax.xml.bind.JAXBException:
> MY_CLASS is not known to this context
> -start profiling from business layer:
> java.lang.NoClassDefFoundError: 
> org/netbeans/lib/profiler/server/ProfilerRuntimeCPUFullInstr
> which belongs to Jfluid-server.jar, so it is not visible to server.
>  
> I know that on JBoss it was enough to add to VM argmuents following entry:
> -Djboss.modules.system.pkgs=org.netbeans.lib.profiler.server
> The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the 
> "com.profiler" classes to be found from any class loader, which is essential 
> to allow the JProfiler agent to run.
>  
> I can’t find anything adequate:
> http://geronimo.apache.org/GMOxDOC30/system-properties.html 
> 
>  
> Question: Is it possible to connect via jvisualvm to app on Geronimo and if 
> yes, what should I change?

I don’t think that there should be any problems.  Are you able to start up the 
application with a “vanilla” JVM?


Regards,
Alan

Re: [ANNOUNCE] Alan Cabrera has been appointed as the new PMC Chair of the Geronimo Project

[Alan D. Cabrera]

> On Feb 19, 2015, at 8:08 AM, Jarek Gawor  wrote:
> 
> All,
> 
> Due to lack of time, in the last few months, I've found it very
> difficult to contribute and stay on top of Geronimo activities. So,
> last month I informed the PMC that I would like to step down as the
> PMC Chair of the Geronimo Project.
> 
> The Geronimo PMC nominated Alan Cabrera to become the new PMC Chair.
> Today, I'm happy to announce that the ASF Board (at this month's
> meeting) officially appointed Alan to be the new PMC Chair of the
> Geronimo Project.
> 
> Congratulations Alan!
> 
> Jarek
> 
> p.s. To all the PMC members, committers, contributors, and users that
> made my life easier as PMC chair - thank you!

Thanks Jarek!  Thank you for all the work you’ve done as our PMC chair!

I’m very excited to be the next PMC chair.  I’ve got some big shoes to fill.

One of the things that I’d like to discuss is the possibility of a complete 
re-write of Geronimo.  A nice fresh start at implementing the JEE specs.  Maybe 
we could even have multiple implementations as people could try out new ideas.


Regards,
Alan

Re: [VOTE] JMS 2 API alpha-2

[Alan D. Cabrera]

I imagine since this is an alpha release we won’t be creating a tag.  Can you 
at least tell us the svn revision?

+1 - binding


> On Feb 12, 2015, at 12:43 PM, Romain Manni-Bucau  
> wrote:
> 
> Hello guys,
> 
> As stated in the other thread here the vote for the
> geronimo-jms_2.0_spec module with the fixes from Martyn included.
> 
> Here is the staging repo:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1013/
> 
> 
> My key can be found as last time at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> here is my +1
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau

Re: How was the table in SSLCipherSuiteDatabase for CORBA support constructed?

[Alan D. Cabrera]

This looks like it was an OpenORB contribution:

http://openorb.cvs.sourceforge.net/viewvc/openorb/SSL/src/main/org/openorb/orb/ssl/SSLCipherSuiteDatabase.java?revision=1.5&view=markup
 



Regards,
Alan

> On Feb 6, 2015, at 2:21 PM, David Jencks  wrote:
> 
> I'm considering updating the table in 
> plugins/corba/geronimo-corba/src/main/java/org/apache/geronimo/corba/security/config/ssl/SSLCipherSuiteDatabase.java
>  to a more up to date list of available cipher suites.  However I don't know 
> how this table was constructed so would have difficultly classifying suites 
> not currently in it.
> 
> The table indicates whether each known suite supports the integrity, 
> confidentiality, and establishTrustinTarget flags for the CORBA CSIv2 spec.  
> (Actually it doesn't list any suites that support integrity.  I would think 
> that is is a possibility, but don't know enough to be sure… presumably signed 
> message hashes without encryption).
> 
> I managed to trace the provenance of this file back to 
> 
> incubator/openejb/trunk/openejb2/modules/openejb-core/src/main/java/org/apache/openejb/corba/security/config/ssl/SSLCipherSuiteDatabase.java
>  
> 
> 
> commit 452600 
> 
> which has my name on it but I don't think I wrote this.  Maybe it was moved 
> in CVS and the migration to subversion didn't track the source of the move?
> 
> Any help welcome :-)
> 
> thanks
> david jencks
> 

Re: [VOTE] release Apache Geronimo XBean-4.1 (take2)

[Alan D. Cabrera]

+1


Regards,
Alan

On Oct 21, 2014, at 2:11 AM, Mark Struberg  wrote:

> Hi!
> 
> 
> I've rolled another build (take2) for Geronimo XBean-4.1.
> 
> This release mainly brings an important performance improvement for 
> xbean-finder.
> 
> 
> 
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachegeronimo-1011/
> 
> The source jar can be found here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1011/org/apache/xbean/xbean/4.1/
> 
> 
> 
> 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] release Geronimo XBean-4.1

[Alan D. Cabrera]

So is this vote officially canceled?


Regards,
Alan

> On Oct 19, 2014, at 3:50 AM, Mark Struberg  wrote:
> 
> Of course, if this has the same limitation then just go on and fix it the 
> same way. 
> 
> Just ping me and I'll re-roll the release (or better do another try).
> 
> LieGrue,
> strub
> 
> 
> 
> 
>> On Sunday, 19 October 2014, 12:00, Romain Manni-Bucau 
>>  wrote:
>>> Hi Mark,
>> 
>> Don't we want the same hack in FileArchive before releasing?
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>> 
>> 
>> 
>> 2014-10-19 9:51 GMT+02:00 Mark Struberg :
>>> Hi!
>>> 
>>> I've rolled a build for Geronimo XBean-4.1.
>>> 
>>> This release mainly brings an important performance improvement for 
>> xbean-finder.
>>> 
>>> 
>>> 
>>> The staging repo is
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1007/
>>> 
>>> The source jar can be found here:
>>> 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1007/org/apache/xbean/xbean/4.1/
>>> 
>>> 
>>> 
>>> 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: Board report time

[Alan D. Cabrera]

LGTM, thanks!


Regards,
Alan

On Oct 11, 2014, at 5:23 AM, Jarek Gawor  wrote:

> Hi all,
> 
> This is a bit late but I created a draft board report for October:
> 
> https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-10+-+October
> 
> If I missed something please let me know or go ahead and update the
> page directly.
> 
> Thanks,
> Jarek

Re: [VOTE] release Geronimo Genesis 2.2

[Alan D. Cabrera]

+1


Regards,
Alan

On Sep 11, 2014, at 12:13 AM, Mark Struberg  wrote:

> Hi!
> 
> genesis is our parents project collector for all geronimo projects.
> The main changes for 2.2 have been the automatic enablement of the apache-rat 
> plugin (Apache Creadur) and version updates of many other maven plugins. I 
> also fixed quite a few missing versions for some maven plugins.
> 
> I updated all geronimo-spec projects to use 2.2-SNAPSHOT as a test and they 
> all build fine.
> 
> The staging repo can be found here:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1005/
> 
> The source release:
> 
> http://repository.apache.org/content/repositories/orgapachegeronimo-1005/org/apache/geronimo/genesis/genesis/2.2/genesis-2.2-source-release.zip
> 
> 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}
> 
> 
> 
> The VOTE is open for 72h.
> 
> here is my +1
> 
> txs and LieGrue,
> strub

Re: [VOTE] a few spec alpha-1 versions

[Alan D. Cabrera]

I've found some problems:

geronimo-annotation_1.2_spec-1.0-alpha-1:

src/main/java/javax/annotation/Priority.java is missing the AL2 header

geronimo-jcdi_1.1_spec-1.0-alpha-1:
src/main/java/javax/enterprise/inject/spi/AfterTypeDiscovery.java is missing 
the AL2 header
src/main/java/javax/enterprise/inject/spi/CDI.java is missing the AL2 header
src/main/java/javax/enterprise/inject/spi/CDIProvider.java is missing the AL2 
header
src/main/java/javax/enterprise/inject/spi/ProcessSyntheticAnnotatedType.java is 
missing the AL2 header
geronimo-concurrent_1.0_spec-1.0-alpha-1:

src/main/java/javax/enterprise/concurrent/Trigger.java is missing the AL2 header


Regards,
Alan


On Aug 30, 2014, at 1:03 PM, Mark Struberg  wrote:

> Hi folks!
> 
> I've just did run the releasing of a few EE7 spec artifacts
> 
> * 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/
> 
> Please review the releases and cast your vote
> The staging repo can be found at
> https://repository.apache.org/content/repositories/orgapachegeronimo-1004/
> 
> My key can be found at
> https://svn.apache.org/repos/asf/openwebbeans/trunk/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] a few spec alpha-1 versions

[Alan D. Cabrera]

Can you add your keys to the Geronimo KEYS?  Thanks!


Regards,
Alan

On Aug 30, 2014, at 1:03 PM, Mark Struberg  wrote:

> Hi folks!
> 
> I've just did run the releasing of a few EE7 spec artifacts
> 
> * 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/
> 
> Please review the releases and cast your vote
> The staging repo can be found at
> https://repository.apache.org/content/repositories/orgapachegeronimo-1004/
> 
> My key can be found at
> https://svn.apache.org/repos/asf/openwebbeans/trunk/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
> 

KEYS file, where's the official location?

[Alan D. Cabrera]

We seem to have two locations for our KEYS file, 
http://svn.apache.org/repos/asf/geronimo/KEYS and 
http://www.apache.org/dist/geronimo/KEYS.

Which one is the official one?


Regards,
Alan

Re: [VOTE] XBean 4.0

[Alan D. Cabrera]

+1


Regards,
Alan

On Aug 22, 2014, at 5:55 AM, Romain Manni-Bucau  wrote:

> a little up since it makes 2 days the vote started already ;)
> 
> 
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 2014-08-20 19:23 GMT+02:00 Romain Manni-Bucau :
>> Hi,
>> 
>> As said in a mail last week I'm starting a vote for xbean 4.0 release.
>> 
>> The main changes are:
>> 1) force AnnotationFinder to respect archive in its scanning (don't
>> leak in external classes)
>> 1bis) skip java.* classes since we'll not get their bytecode for sure
>> (protected method if needed)
>> 2) Remove asynchronous finder which was really specific and can lead
>> to some classloading issue pretty quickly on recent JVMs
>> 
>> Binaries:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1003/
>> 
>> Tag:
>> http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.0/
>> 
>> 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 4.0

[Alan D. Cabrera]

Is your signature in http://www.apache.org/dist/geronimo/KEYS?  


Regards,
Alan

On Aug 22, 2014, at 5:55 AM, Romain Manni-Bucau  wrote:

> a little up since it makes 2 days the vote started already ;)
> 
> 
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 2014-08-20 19:23 GMT+02:00 Romain Manni-Bucau :
>> Hi,
>> 
>> As said in a mail last week I'm starting a vote for xbean 4.0 release.
>> 
>> The main changes are:
>> 1) force AnnotationFinder to respect archive in its scanning (don't
>> leak in external classes)
>> 1bis) skip java.* classes since we'll not get their bytecode for sure
>> (protected method if needed)
>> 2) Remove asynchronous finder which was really specific and can lead
>> to some classloading issue pretty quickly on recent JVMs
>> 
>> Binaries:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1003/
>> 
>> Tag:
>> http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.0/
>> 
>> 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] release geronimo-jbatch_1.0-1.0

[Alan D. Cabrera]

+1 looks good


Regards,
Alan

On Nov 25, 2013, at 7:53 AM, Mark Struberg  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
> 
> 

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

[Alan D. Cabrera]

There's no TCK for this spec?  I imagine if it passes the TCK then we're good.


Regards,
Alan

On Nov 26, 2013, at 6:49 AM, Romain Manni-Bucau  wrote:

> Hi Kevin,
> 
> java 7 requires Java 7 as runtime or build version? Basically I see
> nothing in javaee 7 which could prevent to build against j6 almost the
> whole stack.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 
> 2013/11/26 Kevin Sutter :
>> Hi Romain,
>> That's interesting when the Java EE 7 spec is clear that it requires Java SE
>> 7...  But, maybe since Java Batch can also be used in an SE environment,
>> they can change their requirement for SE.  But, technically, they can't
>> override the requirement for Java SE 7 in the EE environment.
>> 
>> It may not be a big deal for the API, but I wonder if this dual requirement
>> will cause any issues for the implementation and integration with Java EE
>> environments.  I guess we'll find out...
>> 
>> Kevin
>> 
>> 
>> On Tue, Nov 26, 2013 at 4:01 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> Hi Mark,
>>> 
>>> "the only issue I found is you built it against java 7 where the spec says
>>> 
>>> "This specification applies to Java SE and Java EE environments. It
>>> requires Java 6 or higher. "
>>> 
>>> Not sure it is a blocker or not.
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>> 
>>> 
>>> 
>>> 2013/11/25 Mark Struberg :
 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
 
 
>> 
>> 

Re: [VOTE] XBean 3.16 release

[Alan D. Cabrera]

+1


Regards,
Alan

On Nov 13, 2013, at 2:14 PM, Guillaume Nodet  wrote:

> I'm starting a vote for an xbean 3.16 release.
> The 3.15 of last week is unusable in OSGi due to some OSGi metadata problems.
> See https://issues.apache.org/jira/browse/XBEAN-258
> 
> Binaries:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-130/
> 
> Tag:
> 
> http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.16/
> 
> Please review and vote.
> 
> 
> -- 
> ---
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
> 
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
> 

Re: [VOTE] XBean 3.15 release

[Alan D. Cabrera]

+1 Looks good.


Regards,
Alan

On Nov 6, 2013, at 8:55 PM, David Blevins  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
> 

Re: XBean 3.15 release?

[Alan D. Cabrera]

+1


Regards,
Alan

On Nov 3, 2013, at 6:15 PM, David Blevins  wrote:

> Anyone object if I roll an XBean 3.1.5 release?
> 
> 
> -David
> 

Re: Board Report Time

[Alan D. Cabrera]

+1


Regards,
Alan

On Oct 4, 2013, at 11:13 AM, Jarek Gawor  wrote:

> I created a draft board report for October:
> https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2013-10+-+October
> 
> If I missed something please let me know of update the page.
> 
> The report is due on the 9th (Wednesday).
> 
> Jarek

SPAM: Local Computer Support for Business and Home

[Alan D. Cabrera]

Sorry. My bad.  Must resist moderating early in the morning before coffee.  :(


Regards,
Alan

On Sep 20, 2012, at 3:27 AM, Liz wrote:

> Hi, 
> 
> I heard you might need better computer support.
> The company I work for has affordable, local, fast, and friendly
> technicians to service your computers. Please give us a chance to
> impress you.
> 
> Liz C.
> Sales Rep
> Pc Repair Trust
> 305-349-3773
> http://pcrepairtrust.com/signup.html
> 
> 
> 
> --
> If you do not want to receive any more newsletters, 
> http://pcrepairtrust.com/lists/?p=unsubscribe&uid=53b53c80befd305f04e92e4bad26b2d5
> 
> To update your preferences and to unsubscribe visit
> http://pcrepairtrust.com/lists/?p=preferences&uid=53b53c80befd305f04e92e4bad26b2d5
> Forward a Message to Someone
> http://pcrepairtrust.com/lists/?p=forward&uid=53b53c80befd305f04e92e4bad26b2d5&mid=2
> 
> 
> --
> powered by phpList, www.phplist.com --
> 
> 

Re: [VOTE] XBean 3.10 (take 1)

[Alan D. Cabrera]

+1

Regards,
Alan
 
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] release YOKO 1.2 - 2nd attempt.

[Alan D. Cabrera]

+1


Regards,
Alan

On Jul 15, 2011, at 6:16 AM, Forrest Xia wrote:

> [VOTE] release YOKO 1.2 - 2nd attempt.
> 
> This is a bug fixes release for Java EE 6 compliance:
> 
> The fixes in this release are:
> YOKO-431 Classloader issue when initializing a corba skeleton for EJB object
> YOKO-433 YOKO chunking logic does not set the the chunk flag to false when 
> the valuetype tag is false on the chunking bit
> 
> The artifacts up for vote are:
> 1. 
> https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
> 2. 
> https://repository.apache.org/content/repositories/orgapachegeronimo-020/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip
> 
> The staging repository is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-020
> 
> The source tag is:
> https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/
> 
>  Vote will be open for 72 hours.
> 
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
> 
> Forrest

Re: Availability spec compile error

[Alan D. Cabrera]

Ha!  I wonder why I never checked that in.  Sorry!  :)


Regards,
Alan

On Mar 9, 2011, at 5:41 PM, David Blevins wrote:

> Any ideas?
> 
> http://ci.apache.org/builders/specs-trunk/builds/2/steps/compile/logs/stdio
> 
> -David
> 

Re: JSR 319: Availability Management for Java

[Alan D. Cabrera]

On Oct 14, 2010, at 1:08 PM, Kevan Miller wrote:

> 
> On Oct 14, 2010, at 2:07 PM, Alan D. Cabrera wrote:
> 
>> The JSR was approved this summer.  If no one minds I'm going to put this 
>> into specs.
> 
> Can't think of any objections. Can't say that I've looked at the spec... 
> Something you're going to be working on?

It's a nice, clean, abstraction between containers and the availability agents 
that manage the container's and the container's deployment units lifecycle.  
Very nice loose coupling that doesn't try to be a swiss army knife of 
management, which is refreshing.

I think that I can weave it into Geronimo without affecting how Geronimo works 
now but thus provide a way for availability agents to cleanly plugin if needed. 
 I'll do the work in a sandbox to solicit comments before I do any real damage. 
 :)


Regards,
Alan

JSR 319: Availability Management for Java

[Alan D. Cabrera]

The JSR was approved this summer.  If no one minds I'm going to put this into 
specs.


Regards,
Alan

Re: [ANNOUNCE] Welcome Ming Xai "Forrest" as a new Geronimo PMC member

[Alan D. Cabrera]

Congrats!


Regards,
Alan

On Sep 7, 2010, at 12:34 PM, Donald Woods wrote:

> Please join us in congratulating Forrest as a new member of the Geronimo
> PMC.  In addition to all his work on Samples,  Forrest also has
> demonstrated a clear commitment to Geronimo in numerous other areas.
> We're very glad that he has accepted our invitation to join us in
> providing oversight of the Geronimo project.
> 
> Congratulation Forrest !!!
> 
> The Apache Geronimo PMC

Re: [ANNOUNCE] Welcome Rex Wang as a new member of the Geronimo PMC

[Alan D. Cabrera]

Congrats!


Regards,
Alan

On Sep 7, 2010, at 6:00 AM, Rick McGuire wrote:

> Please join us in congratulating  as a new member of the Geronimo PMC.  In 
> addition to serving as a release manager for the Geronimo 2.1.5 server 
> release,  Rex also has demonstrated a clear commitment to Geronimo in 
> numerous other areas.   We're very glad that he has accepted our invitation 
> to join us in providing oversight of the Geronimo project.
> 
> Congratuatlons Rex !!!
> 
> The Apache Geronimo PMC

Re: [ANNOUNCE] Welcome Xuan Dai "Delos" as a new Geronimo PMC member

[Alan D. Cabrera]

Congrats!


Regards,
Alan

On Sep 7, 2010, at 12:32 PM, Donald Woods wrote:

> Please join us in congratulating Delos as a new member of the Geronimo
> PMC.  In addition to all his work on GEP and Samples,  Delos also has
> demonstrated a clear commitment to Geronimo in numerous other areas.
> We're very glad that he has accepted our invitation to join us in
> providing oversight of the Geronimo project.
> 
> Congratulation Delos !!!
> 
> The Apache Geronimo PMC

Re: [Need review] The mock UI for displaying bundle information

[Alan D. Cabrera]

Very nice!

On Dec 15, 2009, at 1:19 AM, Delos wrote:


Hi all,

OSGI Bundle is a new item for Geronimo admin console and RFC 139  
defines many Mbeans used to get bundle information in OSGI  
environment. So it's necessary for admin console to show the  
information of OSGI bundles.


Therefore, Rodger and I mocked up a couple of portlets. Here are  
some screenshots for the mock UI. As you can see, we have two  
portlets here, to show the bundle list and bundle information. It's  
a initial draft based on Dojo widgets without full javascript  
implementation.


Screenshot 1: 
https://svn.apache.org/repos/asf/geronimo/sandbox/delos/dojoBundleList_anntation.JPG
Screenshot 2: 
https://svn.apache.org/repos/asf/geronimo/sandbox/delos/singlebundle.JPG

In the attachment, 1 is the bundle list portlet, while 2 is the  
bundle information portlet. Bundle list portlet gives a list of  
installed bundles;besides, the portlet also allow user to stop/start/ 
uninstall bundles. Bundle information portlet is much simpler, it  
only display the bundle information in OSGI framework. Mbeans  
defined in RFC 139 is a way to obtain the information.


I assume that you'll format the exported and imported packages in the  
same manner as BND in #1?


For better illustration, I added some markers (A,B,C,D,E) in  
snapshot 1.


A - With these widgets, user can install any bundle from file  
system. If "start" is checked, the bundle will be started  
automatically after it's installed.Meanwhile, user can also specify  
the start level of this bundle. I'm not sure if the "Deploy New"  
portlet will be applicable for OSGI bundles, so I just mock the  
installation UI according to Web console of Felix.


B - All the possible actions can be taken to bundles. Every bundle  
can be selected through the checkbox in front of it. Each time an  
action is taken to all the selected bundles. If the action is not  
applicable for some bundles, these bundles will be ignored.


C - Each column in the table can be sorted by clicking the column  
header. The up arrow stands for sort asending while the down arrow  
stands for sort desending.


D - The textbox here is used to filter bundles by symbolic name.  
Only the bundles with symbolic name containing specified text will  
be shown. If no text provided, all the bundles will show


I would have a drop down box to the left so that you could enter in:

- imported packages
- exported packages

in addition to the Symbolic Name.

It would also be great if one could trace the wirings to help discover  
where conflicts lie.  Maybe this would be a different screen but I  
think that tooltips that showed the wirings would be pretty helpful.


E - The drop down list here gives the possible status of an  
installed bundle - "resolved","starting","active","stopping". It's  
used to filter bundles by status. If one status is selected, only  
bundle with status the same as selected value will be shown. If no  
value is selected, all the bundles will be shown.


I imagine the status would update automatically via some kind of comet  
call.


Again, very nice!

Regards,
Alan

Re: [DISCUSS] Donate Blueprint implementation to Aries podling

[Alan D. Cabrera]

On Sep 23, 2009, at 8:20 AM, Guillaume Nodet wrote:


Some time ago, a few Geronimo committers have started an
implementation of the OSGi Blueprint Services spec, which is basically
an OSGi standardized version of Spring-DM (the next version of
Spring-DM being the RI of this spec).
The code was developed at Geronimo mostly because the people that were
interested in doing so were all Geronimo committers, so it was way
easier to set that up inside Geronimo.  However, the piece of code
does not really fit well in Geronimo, as it has nothing to do with
JEE.

A few days ago, a podling named Aries has been proposed to the
incubator.  You'll find the proposal at
http://wiki.apache.org/incubator/AriesProposal.
Aries would be a much more natural home for the blueprint code
currently in Geronimo.

Thoughts / questions / remarks ?


Makes sense to me.


Regards,
Alan

Re: [VOTE] Release Blueprint 1.0.0 (4th try)

[Alan D. Cabrera]

+1

On Sep 11, 2009, at 9:38 AM, Guillaume Nodet wrote:


I've uploaded another 1.0.0 release of the blueprint project.
I think I've addressed all the issues raised in the discussion thread.

The staging repository is available at:
https://repository.apache.org/content/repositories/geronimo-staging-005/

The corresponding tag is available at
 
http://svn.apache.org/repos/asf/geronimo/components/blueprint/tags/blueprint-1.0.0/

Please review and vote:
[  ] +1 Release
[  ] -1 Do not release

The vote will remain open for 72 hours.

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: javadoc @version tags

[Alan D. Cabrera]

On Sep 9, 2009, at 3:31 PM, David Jencks wrote:



On Sep 9, 2009, at 1:14 PM, Alan D. Cabrera wrote:



On Sep 9, 2009, at 11:01 AM, David Jencks wrote:

I was looking at the generated xbean site prior to releasing and  
noticed the version looks pretty messy with lots of random  
variations.  I think we've previously encouraged something like  
this:


 * @version $Rev:$ $Date:$

which expands to something like

 * @version $Rev: 437551 $ $Date: 2006-08-27 23:14:47 -0700 (Sun,  
27 Aug 2006) $


which ends up in javadoc as something like

Version:
$Rev$ $Date$
or

Version:
$Rev: 437551 $ $Date: 2006-08-27 23:14:47 -0700 (Sun, 27 Aug 2006) $

This seems wrong to me.  I think in javadoc the version ought to  
be something like 3.6-SNAPSHOT or 3.6.


So, I'd like to propose that:

1. we investigate and find out if there's a way to set the javadoc  
version to the maven version.  If so, use it.  If not, remove the  
@version.


2. Decide if we want the svn keyword info in the java files at  
all, and if so get it out from the @version javadoc tag.


What do other projects do?  It's always been my understanding that  
the @version relates to the version of the code file and not the  
release.


So far the documentation I've found (http://java.sun.com/j2se/javadoc/writingdoccomments/index.html# 
@version) says:


The Java Software convention for the argument to the @version tag is  
the SCCS string "%I%, %G%", which converts to something like "1.39,  
02/28/97" (mm/dd/yy) when the file is checked out of SCCS.


Also (http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html# 
@version),


@version  version-text
Adds a "Version" subheading with the specified version-text to the  
generated docs when the -version option is used. This tag is  
intended to hold the current version number of the software that  
this code is part of (as opposed to @since, which holds the version  
number where this code was introduced). The version-text has no  
special internal structure. To see where the version tag can be  
used, see Where Tags Can Be Used.
A doc comment may contain multiple @version tags. If it makes sense,  
you can specify one version number per @version tag or multiple  
version numbers per tag. In the former case, the Javadoc tool  
inserts a comma (,) and space between names. In the latter case, the  
entire text is simply copied to the generated document without being  
parsed. Therefore, you can use multiple names per line if you want a  
localized name separator other than comma.



While the meaning of "1.39" is not clear, it might be a cvs version  
number, which is sort of analogous to an svn revision number.  On  
the other hand, the second snippet indicates that it is analogous to  
the @since tag and that the versions specified in both should be  
comparable: this would agree with the idea that the maven version  
number is more appropriate.


It seems that either would be fine.  I think, like you, that the  
latter would be more useful to users reading the documentation.



Regards,
Alan

Re: [VOTE] Release Blueprint 1.0.0 (3thd try)

[Alan D. Cabrera]

On Sep 10, 2009, at 9:44 AM, Guillaume Nodet wrote:

On Thu, Sep 10, 2009 at 17:54, Kevan Miller   
wrote:


On Sep 10, 2009, at 4:29 AM, Guillaume Nodet wrote:


I've uploaded a new 1.0.0 release of the blueprint project.
I think I've addressed all the issues raised in the discussion  
thread.


The staging repository is available at:
 https://repository.apache.org/content/repositories/geronimo-staging-054/

The corresponding tag is available at

 
http://svn.apache.org/repos/asf/geronimo/components/blueprint/tags/blueprint-1.0.0/

Please review and vote:
[  ] +1 Release
[  ] -1 Do not release

The vote will remain open for 72 hours.


The following files do not contain apache source license headers.

 ./blueprint-api/src/main/java/org/osgi/service/blueprint/container/ 
package.html
 ./blueprint-api/src/main/java/org/osgi/service/blueprint/container/ 
packageinfo
 ./blueprint-api/src/main/java/org/osgi/service/blueprint/reflect/ 
package.html
 ./blueprint-api/src/main/java/org/osgi/service/blueprint/reflect/ 
packageinfo


Those come straight from the blueprint OSGi from the osgi alliance  
afaik.

I can add them with the OSGi alliance copyright, but I'm not even sure
what's the comments syntax for the packageinfo file


Should these maybe be released separately, like the spec jars?


Regards,
Alan

Re: javadoc @version tags

[Alan D. Cabrera]

On Sep 9, 2009, at 11:01 AM, David Jencks wrote:

I was looking at the generated xbean site prior to releasing and  
noticed the version looks pretty messy with lots of random  
variations.  I think we've previously encouraged something like this:


 * @version $Rev:$ $Date:$

which expands to something like

 * @version $Rev: 437551 $ $Date: 2006-08-27 23:14:47 -0700 (Sun, 27  
Aug 2006) $


which ends up in javadoc as something like

Version:
$Rev$ $Date$
or

Version:
$Rev: 437551 $ $Date: 2006-08-27 23:14:47 -0700 (Sun, 27 Aug 2006) $

This seems wrong to me.  I think in javadoc the version ought to be  
something like 3.6-SNAPSHOT or 3.6.


So, I'd like to propose that:

1. we investigate and find out if there's a way to set the javadoc  
version to the maven version.  If so, use it.  If not, remove the  
@version.


2. Decide if we want the svn keyword info in the java files at all,  
and if so get it out from the @version javadoc tag.


What do other projects do?  It's always been my understanding that the  
@version relates to the version of the code file and not the release.



Regards,
Alan

Re: [DISCUSS] Only Support Java SE 6 with Geronimo 2.2

[Alan D. Cabrera]

On Nov 6, 2008, at 9:04 PM, Donald Woods wrote:


The time has come to make the hard decision -

Do we only build and certify Geronimo 2.2 on the Sun 1.6.0 JDK and  
drop support for running on Java SE 5?


Pros:
- Reduce testing effort to one version of Java
- Allows us to use the JAXB 2.1, JAX-WS 2.1 and wsgen tools in the  
JDK, instead of shipping those jars in our assemblies (and removes  
some more Sun RI from our assemblies)  :-)

- Keeps us current on the latest Java release
- All major platforms have a Java SE 6 solution:

Cons:
- Users will have to upgrade to Java SE 6 to run Geronimo 2.2
- Will require us to maintain the 2.1 branch during 2009 for any  
users who want to stay on Java SE 5


I'm for moving to a Java SE 6 only runtime for Geronimo 2.2.



I'm not kean on the idea.  Java SE 6 has not been out for that long,  
relatively speaking and a lot of production environments will still be  
on Java SE 5.



Regards,
Alan

Re: JSR 311

[Alan D. Cabrera]

On Oct 26, 2008, at 8:38 AM, Matthias Wessendorf wrote:


Hi,

I was wondering if you guys know about an Apache licensed JSR 311
implementation ?


I would checkout CXF:  cxf.apache.org


Regards,
Alan

Re: JASPI as a component? JACC as a component?

[Alan D. Cabrera]

Sounds good to me.


Regards,
Alan

On Jul 11, 2008, at 11:55 AM, David Jencks wrote:

I've been looking at JASPI lately, first working with jetty to base  
its authentication on jaspi, and now looking at implementing a  
provider for geronimo.  I think it makes sense to have this as a  
component (like the tm/connector framework) rather than inside the  
geronimo-security jar.


I'll move it, if there are problems or anyone objects we can move it  
back.


thanks
david jencks

Re: [ANNOUNCE] Lin Sun is the newest member of the Geronimo PMC

[Alan D. Cabrera]

Congratulations!


Regards,
Alan

On Jun 26, 2008, at 10:34 AM, Jarek Gawor wrote:


All,

Please join us in congratulating Lin Sun as the newest member of the
Geronimo PMC. She has been involved with the Geronimo community for a
long time and made great contributions as a committer and otherwise.
She will be a great addition to the PMC.

Congratulations Lin!

The Apache Geronimo PMC

Re: [ANNOUNCE] Welcome Shiva Kumar H R as the newest member of the Geronimo PMC

[Alan D. Cabrera]

Welcome aboard!


Regards,
Alan

On Jun 23, 2008, at 4:43 AM, Vamsavardhana Reddy wrote:


All,
Please join us in congratulating Shiva Kumar H R as the newest  
member of the Geronimo PMC. It's been great to have Shiva working  
with us as a committer on Geronimo. Even better to have him join us  
in providing oversight of the Geronimo project.


Way to go Shiva!!!

The Apache Geronimo PMC

++Vamsi

Re: [VOTE] Release JAX-WS 2.1 spec jar version 1.0 (take 2)

[Alan D. Cabrera]

+1


Regards,
Alan

On May 23, 2008, at 11:20 AM, Jarek Gawor wrote:


Hi,

JAX-WS 2.1 spec jar is used by Axis2 and CXF projects and it will help
Geronimo in transition to JAX-WS 2.1. This is a very first release of
the JAX-WS 2.1 spec jar.

This version contains fixes for the problems Kevan found (missing
LICENSE, NOTICES files in svn tree and product name).

Staging repo:
http://people.apache.org/~gawor/staging-repo-2/specs/geronimo-jaxws_2.1_spec/

Staging site:
http://people.apache.org/~gawor/staging-site-2/specs/geronimo-jaxws_2.1_spec/

Since Monday is a holiday in the US the vote is open until next
Thursday (May 29th).

[ ] +1
[ ] +0
[ ] -1

Jarek

Re: FYI: Geronimo 2.0 Docs - Japanese Translation completed.

[Alan D. Cabrera]

Outstanding!


Regards,
Alan

On May 28, 2008, at 8:43 AM, 石田　剛 wrote:


Hello, Geronimo-devs.

We, The Japan Apache Geronimo Users Group , are proud to announce  
that we've completed all the Geronimo 2.0 documents translation. Now  
it's on the Geronimo Wiki.


http://cwiki.apache.org/GMOxDOC20ja/documentation.html

Everything was done on a voluntary basis, so it took a little time.
We'd like to say big "thank-you !" to all the original doc authors.  
Surely it was fun and interesting as the original docs were so good.

We're looking forward the 2.1 docs growing up !

contact: [EMAIL PROTECTED]

Regards.


GANBARE! NIPPON! Win your ticket to Olympic Games 2008.

Re: Google Analytics

[Alan D. Cabrera]

Thanks Dave.  Can you add [EMAIL PROTECTED]


Regards,
Alan

On May 14, 2008, at 11:32 PM, David Blevins wrote:

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


[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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: Geronimo specs jars in OSGi

[Alan D. Cabrera]

I must be missing something.  That legacy code would not need to  
change.  The whiteboard pattern only obviates the need to scavenge  
every bundle the META-INF/services entries.  The rest works as you say.


But, as I think about it some more, I'm thinking that this is over  
engineering it.  Let's drop this aspect of the thread.


I still feel strongly that the virgin spec jar should be wrapped in a  
bundle.



Regards,
Alan

On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote:


i don't mean legacy jars but legacy *code*.
If you have a jar which uses
  javax.xml.stream.XMLInputFactory.newInstance()
somewhere deep in the code, I don't really understand how using a  
whiteboard

pattern will solve the problem.  I'm not trying to make people rewrite
everything,
but rather make things easy for them to deploy their application  
and keep the

behavior they are used to see.
it could be you want to deploy the jaxws-ri, jersey or any other  
xml related

technology that could use SAAJ, Stax, Jaxb2 ...


On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:

IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
manifest entries.  You do so using the maven/BND plugin I suspect.

 This strikes me as a common service discovery pattern.  Off the  
top of my
head I would think that a plugin that adds the necessary  
BundleActivator for

legacy modules would be useful.

 Another thought that flashed in my head is that in a buttoned down
environment getting service notifications might be easier than  
getting

access to every Bundle's class loader.


 Regards,
 Alan



 On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:


Cleaner, but the main problem is that it does not work with  
legacy code.
Will you rewrite the jaxb2 implementation to do that instead of  
using the

stax

factory ? ;-)
We've got tons of legacy stuff that use stax, or jaxb2 and i  
don't see

rewriting
the whole lot as realistic.  it would also mean having an OSGi  
specific

thing

everywhere we use a factory from a j2ee spec :-(

On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]>

wrote:





On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:




On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski

<[EMAIL PROTECTED]>



wrote:




On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet  
<[EMAIL PROTECTED]>





wrote:







However, lots of these spec jars define factories (stax, saaj  
for







example)






that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not

fit







well in






OSGi (really, it does not), mainly because usually, the

classloader

containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an

OSGi
BundleActivator that would change the behavior of these  
factories

when
deployed in an OSGi environment (without changing the  
behavior in







other






case).  The idea is that the activator would scan OSGi bundles

when







they are





started to find META-INF/services and populate a map that  
would be







used by






the factory when creating an object before using the standard






mechanism.










Just to ensure I'm following, you are about to create a activator

that

would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided

services?

Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?




This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own  
classloader and

classloaders
are not organized in a simple tree: if bundle A requires bundle  
B and

bundle B requires
bundle C, it does not mean that C will be accessible to A.   
Following

so



far ?


So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.   
The stax

implementation that
I deploy will also have the stax api in its classpath, but it  
won't be

available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all,  
because

the META-INF/services
and the implementation class are not available from the stax api


classloader.


One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and  
make sure

the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to  
make

sure the classloader
includes it.

The problem is that it's a b

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

Sorry.  This is for David's idea:

"I also wonder if there is a way to generalize the osgi method so it  
might work in some non-osgi environments."


Another reason to wrap the spec jar in a bundle is that we won't be  
seen as extending the spec, something that is explicitly prohibited in  
the licensing of the JSRs.



Regards,
Alan

On Apr 17, 2008, at 7:17 AM, Guillaume Nodet wrote:


Do you mean your -1 only apply to extending the behavior of the spec
in the J2EE environment,
and does not apply to extending the behavior in an OSGi environment ?
I'm not sure to completely understand your reasoning.

On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:

Sorry, I meant to say:


On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:




On Apr 16, 2008, at 8:49 AM, David Jencks wrote:


I'd like to see an example in action before I commit myself but  
so far I
don't see any problems with this.  I assume you have already or  
will soon

verify this doesn't cause problems with the tck :-)


I wonder if a package name with "osgi" in it somewhere would be  
more

appropriate?


There are some specs (jacc for instance) that use a system  
property to

figure out what to create.  I've always thought this was a less than
brilliant idea and wonder if we can do something similar for  
those.  I also
wonder if there is a way to generalize the osgi method so it might  
work in

some non-osgi environments.









-1 technical veto

These are spec jars and extending the behavior of these jars on an  
ad hoc
basis is bad and possibly violates the licenses of the JSRs they  
implement.



Regards,
Alan










--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

IIUC, they're not entirely legacy, i.e. you at least put in the OSGi  
manifest entries.  You do so using the maven/BND plugin I suspect.


This strikes me as a common service discovery pattern.  Off the top of  
my head I would think that a plugin that adds the necessary  
BundleActivator for legacy modules would be useful.


Another thought that flashed in my head is that in a buttoned down  
environment getting service notifications might be easier than getting  
access to every Bundle's class loader.



Regards,
Alan

On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:

Cleaner, but the main problem is that it does not work with legacy  
code.
Will you rewrite the jaxb2 implementation to do that instead of  
using the stax

factory ? ;-)
We've got tons of legacy stuff that use stax, or jaxb2 and i don't  
see rewriting
the whole lot as realistic.  it would also mean having an OSGi  
specific thing

everywhere we use a factory from a j2ee spec :-(

On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:



On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:


On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED] 
>

wrote:



On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>

wrote:




However, lots of these spec jars define factories (stax, saaj for

example)

that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not  
fit

well in
OSGi (really, it does not), mainly because usually, the  
classloader

containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi
BundleActivator that would change the behavior of these  
factories when

deployed in an OSGi environment (without changing the behavior in

other
case).  The idea is that the activator would scan OSGi bundles  
when

they are

started to find META-INF/services and populate a map that would be

used by

the factory when creating an object before using the standard

mechanism.




Just to ensure I'm following, you are about to create a activator  
that

would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided  
services?

Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?



This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own classloader  
and

classloaders
are not organized in a simple tree: if bundle A requires bundle B  
and

bundle B requires
bundle C, it does not mean that C will be accessible to A.   
Following so

far ?

So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.  The  
stax

implementation that
I deploy will also have the stax api in its classpath, but it  
won't be

available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api

classloader.

One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make  
sure

the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the  
bundles

and it does prevent
swicthing implementations.

So now, there is no need to reference the implementation from the
bundle.  The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.



I think, just my personal opinion, that scouring bundles' META-INF/ 
services
entries is kinda klunky.  Could we not use a service/whiteboard  
approach

that is common in OSGi? When in Rome, do as the Romans do.

Let's assume that we go with the virgin spec jar wrapped in a bundle
paradigm I spoke of in a previous post.  Here the bundles that use  
the stax
api would register stax api service implementations.  The stax api  
would
catch those service registrations and properly configure the  
factory.   A

bit cleaner imo and you don't have to search every bundle.


Regards,
Alan






--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote:


I've thought about this.  The main problem is that you end up having
two different
jars for the spec, one being a plain jar and another one being an  
OSGi bundle.
Both would not be compatible if the bundle embeds the spec jar,  
because non osgi

environment would not be able to load the jar inside the bundle.
Imho, creating two different jars would confuse the users and be more
error prone.


Non OSGi environments use the vanilla jar as they currently do.  OSGi  
environments load the spec bundle.  Doesn't seem confusing to me.





On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:


On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:




In the past months, I've been working on making the specs jars from

Geronimo working in an OSGi environment.

All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for  
example)

that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not  
fit well in

OSGi (really, it does not), mainly because usually, the classloader
containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi
BundleActivator that would change the behavior of these factories  
when
deployed in an OSGi environment (without changing the behavior in  
other
case).  The idea is that the activator would scan OSGi bundles when  
they are
started to find META-INF/services and populate a map that would be  
used by
the factory when creating an object before using the standard  
mechanism.


The only real difference compared to what we currently have would  
be the
addition of a package named org.apache.geronimo.specs.stax (for  
example)
that would contain the needed classes (i suppose two classes), and  
the
modification of the factories to delegate to one of these class  
before using
the standard behavior (the class would do nothing if not deployed  
in an OSGi

environment).

Has anyone any objection with such an enhancement in the specs jar ?



I would prefer to have a virgin spec jar wrapped inside an OSGi  
bundle.

Here the virgin factories would be overshadowed by the OSGi specific
factories.

I feel strongly about this but am willing to discuss it.


Regards,
Alan






--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:

On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED] 
> wrote:
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>  
wrote:


However, lots of these spec jars define factories (stax, saaj for  
example)

that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not  
fit well in

OSGi (really, it does not), mainly because usually, the classloader
containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi
BundleActivator that would change the behavior of these factories  
when
deployed in an OSGi environment (without changing the behavior in  
other
case).  The idea is that the activator would scan OSGi bundles  
when they are
started to find META-INF/services and populate a map that would be  
used by
the factory when creating an object before using the standard  
mechanism.


Just to ensure I'm following, you are about to create a activator  
that

would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided  
services?

Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?


This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own classloader and
classloaders
are not organized in a simple tree: if bundle A requires bundle B and
bundle B requires
bundle C, it does not mean that C will be accessible to A.   
Following so far ?

So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.  The stax
implementation that
I deploy will also have the stax api in its classpath, but it won't be
available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api  
classloader.

One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make sure
the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the bundles
and it does prevent
swicthing implementations.

So now, there is no need to reference the implementation from the
bundle.  The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.


I think, just my personal opinion, that scouring bundles' META-INF/ 
services entries is kinda klunky.  Could we not use a service/ 
whiteboard approach that is common in OSGi? When in Rome, do as the  
Romans do.


Let's assume that we go with the virgin spec jar wrapped in a bundle  
paradigm I spoke of in a previous post.  Here the bundles that use the  
stax api would register stax api service implementations.  The stax  
api would catch those service registrations and properly configure the  
factory.   A bit cleaner imo and you don't have to search every bundle.



Regards,
Alan

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

Sorry, I meant to say:

On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:



On Apr 16, 2008, at 8:49 AM, David Jencks wrote:

I'd like to see an example in action before I commit myself but so  
far I don't see any problems with this.  I assume you have already  
or will soon verify this doesn't cause problems with the tck :-)


I wonder if a package name with "osgi" in it somewhere would be  
more appropriate?


There are some specs (jacc for instance) that use a system property  
to figure out what to create.  I've always thought this was a less  
than brilliant idea and wonder if we can do something similar for  
those.  I also wonder if there is a way to generalize the osgi  
method so it might work in some non-osgi environments.



-1 technical veto

These are spec jars and extending the behavior of these jars on an  
ad hoc basis is bad and possibly violates the licenses of the JSRs  
they implement.



Regards,
Alan

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

On Apr 16, 2008, at 8:49 AM, David Jencks wrote:

I'd like to see an example in action before I commit myself but so  
far I don't see any problems with this.  I assume you have already  
or will soon verify this doesn't cause problems with the tck :-)


I wonder if a package name with "osgi" in it somewhere would be more  
appropriate?


There are some specs (jacc for instance) that use a system property  
to figure out what to create.  I've always thought this was a less  
than brilliant idea and wonder if we can do something similar for  
those.  I also wonder if there is a way to generalize the osgi  
method so it might work in some non-osgi environments.  I'm looking  
forward to seeing what you have in mind.


thanks
david jencks

On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
In the past months, I've been working on making the specs jars from  
Geronimo working in an OSGi environment.

All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for  
example) that use the META-INF/services/ discovery mechanism to  
find an implementation of the spec and load it.  This mechanism  
does not fit well in OSGi (really, it does not), mainly because  
usually, the classloader containing the spec jar will not contain  
the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi BundleActivator that would change the behavior of these  
factories when deployed in an OSGi environment (without changing  
the behavior in other case).  The idea is that the activator would  
scan OSGi bundles when they are started to find META-INF/services  
and populate a map that would be used by the factory when creating  
an object before using the standard mechanism.


The only real difference compared to what we currently have would  
be the addition of a package named org.apache.geronimo.specs.stax  
(for example) that would contain the needed classes (i suppose two  
classes), and the modification of the factories to delegate to one  
of these class before using the standard behavior (the class would  
do nothing if not deployed in an OSGi environment).

Has anyone any objection with such an enhancement in the specs jar ?


-1 technical veto

These are spec jars and extending the behavior of these jars on an ad  
hoc basis is bad and possibly violates the licenses of the JSRs they  
implement.



Regards,
Alan

Re: Geronimo specs jars in OSGi

[Alan D. Cabrera]

On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:

In the past months, I've been working on making the specs jars from  
Geronimo working in an OSGi environment.

All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for  
example) that use the META-INF/services/ discovery mechanism to find  
an implementation of the spec and load it.  This mechanism does not  
fit well in OSGi (really, it does not), mainly because usually, the  
classloader containing the spec jar will not contain the  
implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi BundleActivator that would change the behavior of these  
factories when deployed in an OSGi environment (without changing the  
behavior in other case).  The idea is that the activator would scan  
OSGi bundles when they are started to find META-INF/services and  
populate a map that would be used by the factory when creating an  
object before using the standard mechanism.


The only real difference compared to what we currently have would be  
the addition of a package named org.apache.geronimo.specs.stax (for  
example) that would contain the needed classes (i suppose two  
classes), and the modification of the factories to delegate to one  
of these class before using the standard behavior (the class would  
do nothing if not deployed in an OSGi environment).

Has anyone any objection with such an enhancement in the specs jar ?


I would prefer to have a virgin spec jar wrapped inside an OSGi  
bundle. Here the virgin factories would be overshadowed by the OSGi  
specific factories.


I feel strongly about this but am willing to discuss it.


Regards,
Alan

Java Service Wrapper

[Alan D. Cabrera]

Something that we might need to look into.


Regards,
Alan

-- Forwarded message --
From: Roy T. Fielding <[EMAIL PROTECTED]>
Date: Wed, Apr 2, 2008 at 3:20 PM
Subject: Java Service Wrapper
To: [EMAIL PROTECTED]


The Java Service Wrapper is being used (and sometimes redistributed) by
many of our Java projects (ActiveMQ, ServiceMix, Geronimo, OFBiz,  
Tomcat).

It was formerly available under an MIT/BSD style license, as can be seen
in the 3.2.3 version at

 http://sourceforge.net/projects/wrapper/

More recent versions of the product are currently under dual GPLv2
and commercial licensing.

 http://wrapper.tanukisoftware.org/doc/english/licenseOverview.html

And yet no mention of its license is found in our documentation.

 http://activemq.apache.org/java-service-wrapper.html
 
http://docs.ofbiz.org/display/OFBIZ/How+to+Run+OFBiz+as+Windows+Service+with+Java+Service+Wrapper
 http://people.apache.org/~fhanik/wrapper.html
 http://wiki.apache.org/db-derby/DerbyWindowsService

and the only pages we have that refer to the old version are in Geronimo

 
http://cwiki.apache.org/GMOxDOC11/configuring-geronimo-as-a-windows-service.html
 
http://cwiki.apache.org/GMOxDOC20/configuring-geronimo-as-a-windows-service.html

If your project is currently distributing or telling users to make use  
of
the Java Service Wrapper, please be sure that we only use the old  
licensed
version, that our documentation points to the old site, and that when  
we do
point folks to wrapper.tanukisoftware.org (which we should do because  
some

users are not allergic to GPLv2) we should also point out that the newer
versions are under different licenses (GPLv2/commercial).

Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] Jason Warner as Geronimo's most recent committer

[Alan D. Cabrera]

Congratulations!


Regards,
Alan

On Apr 2, 2008, at 11:22 AM, Joe Bohn wrote:


All,

It is my privilege to announce that Jason has recently accepted an  
invitation to join the Apache Geronimo project.  Jason has been  
working on Geronimo for a while now in multiple areas including J2G,  
javamail, G-shell commands, samples, and many more things.  He is  
always eager to help users and goes the extra mile to ensure issues  
are addressed. We're grateful to have him on the project.  Please  
give it up for Jason.


Joe

Re: [PROPOSAL] Indent 2 spaces in xml and vm files to match more common usage, especially maven.

[Alan D. Cabrera]

-0

I find 2 space indenting difficult to read.  I'm sure that I'm  
misunderstanding something so take my reply with a grain of salt.


On Mar 13, 2008, at 8:28 AM, David Jencks wrote:



On Mar 13, 2008, at 7:21 AM, Jason Dillon wrote:

-1.  I don't think there is any value in making the indent for xml  
or any other files different than the normal indent for all other  
files.


Let me give a couple of examples where the 4-space indent causes a  
lot of pain and will continue to:


- in genesis geronimo-skin we have a site.vm file that is a slightly  
modified copy of the default .vm file from doxia-sitetools.  Trying  
to update it or compare it with different indents is quite an  
experience.


I'm not terribly familiar w/ site generation.  I was under the  
impression that we leave cookies by the wiki and elves make it.  :)


Could we not just reformat the site.vm file to have 4 space indents?

- maven archetypes pop out xml with 2 space indenting, and maven xml  
has 2 space indenting.  Re-indenting our stuff any time you run an  
archetype or borrow some configuration from maven is a nuisance that  
frequently is ignored and again the spacing difference makes  
comparison quite difficult.


For those of us sensible enough to use IntelliJ, alt-cmd-L makes our  
world tidy.  Maybe we could get the archetype generator to take the  
number of spaces for an indent as a configuration parameter?


Do you have an editor that can't deal with different indents for  
different file types?


thanks
david jencks



--jason


On Mar 13, 2008, at 6:34 AM, David Jencks wrote:

IIUC we have a coding standard of a 4 space indent for all files  
(documented at http://cwiki.apache.org/GMOxDEV/coding-standards.html) 
.  This can make working with maven difficult because its files  
and xml output generatiion use 2 space indent for xml and .vm files.


I think we could make life a lot easier when using maven tooling  
to use a 2 space indent for xml and .vm and possibly other files.   
At least with IDEA its easy to have different indents for java and  
xml files.


Comments?

thanks
david jencks

Re: [VOTE] new release process docs

[Alan D. Cabrera]

+1

Regards,
Alan

On Mar 4, 2008, at 9:40 AM, David Jencks wrote:

The current release process docs http://cwiki.apache.org/confluence/display/GMOxPMGT/Release+Branching+Process 
 indicate they were subject to a vote, so I think a major change  
also needs a vote.


Please vote on changing to the proposed docs

http://cwiki.apache.org/confluence/display/GMOxPMGT/Proposed+%28updated%29+release+process

I've added a note indicating that the idea is for clarifications,  
updates, etc to be fine without a vote.


We'll finish up the vote friday morning March 7.

[ ] +1 these are better
[ ] + 0 I could care less
[ ] -1 not exactly an improvement because

thanks
david jencks

Re: using Resource Bundles for message strings

[Alan D. Cabrera]

Jarek's statements reflect my own sentiments as well.

To address your concern about key collisions, I don't think that it  
will happen if modules get their own resource file.  It was never a  
problem for me.



Regards,
Alan

On Feb 27, 2008, at 7:57 AM, B.J. Reed wrote:

Thanks, each plugin/module will have its own resource file in the  
plugin/module jar now.


The MessageFormat and varargs were very helpful.  The code is much  
simpler now.


For the message keys, I'm just looking for some way to have a unique  
naming scheme and the group id/module/abbreviations should do that  
(for now at least).  With a scheme not based on the module name, I'm  
afraid of the following: since each module has its own resource  
bundle, keys in different modules could have the same name and  
everything would work fine, but if users reference a key and it's  
not unique.what else can we use to help make these keys unique  
across modules?


--B.J. Reed


Jarek Gawor wrote:

Some thoughts:

1) Each module or plugin should have its own resource file.

2) Messages should be formatted using java.text.MessageFormat. The
substitution arguments should be arbitrary objects (not just strings)
and should be passed using varargs.

3) As soon as we encode the module or group id into the key or
whatever, it will become invalid or inaccurate. It's a maintenance
mess in my opinion. I think the key should just be a simple string
without any additional encoded information. We can inject some extra
info as the message is displayed but the key should be very simple.

Jarek

Re: using Resource Bundles for message strings

[Alan D. Cabrera]

On Feb 26, 2008, at 7:30 AM, B.J. Reed wrote:

I have written a patch to get Geronimo messages from a common set of  
resource bundles.  Included in the patch is the  
GeronimoMessageBundle.java, GeronimoMessageBundleTest.java, and the  
start of the  geronimo-messages.properties file.


Neat!

2) Is there a numbering standard for the key?  The standard that I  
have started for the message key is as follows:

l
   - 4 char module name abbreviation
  l - one char level (E - error, W - warning, I - information
   - 4 digit error number
Since I haven't gotten very far...if there is a better suggestion,  
then it will be easier to change this sooner rather than later.


I've had a fair bit of i18n experience.  Using codes for for i18n has  
never went well.  It obfuscates code.  I've never run into a situation  
where having a code made it easer than a terse phrase:


return getMessage ("COMMW0002", key);

instead of

return getMessage ("tooManySubstitutions", key);

5)  Is there a way to have the .properties file(s) outside of the  
jar?  I'm sure there is, but I haven't stumbled across it yet.   
That's actually where I've been banging my head the last few days.


OSGi fragments?  :D


Regards,
Alan

Re: Connector problems

[Alan D. Cabrera]

I thought that I knew JCA pretty well.  What is a permit leak?


Regards,
Alan

On Feb 9, 2008, at 1:22 AM, David Jencks wrote:

Working with Tomasz Mazan we discovered that there was a permit leak  
in the connector pooling code (GERONIMO-3834).  While fixing this I  
revamped quite a bit of the pooling code and added several permit  
count and resizing tests, hopefully making it more reliable and  
reducing the bug count.


I think we should get this bug fix in g. 2.1 which will require  
releasing the "components" jars also.  I'm OK with a vote on the  
component jars + geronimo 2.1.


We might consider releasing 2.0.3 with this fix as well.

thanks
david jencks

Re: [VOTE] Release JAXR 1.0 spec, v 2.0

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 6:25 AM, Guillaume Nodet wrote:


I've uploaded a release of JAXR 1.0 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jaxr_1.0_spec-2.0/
Repo
   http://people.apache.org/~gnodet/staging/geronimo- 
jaxr_1.0_spec-2.0/


Please review and vote:
  [ ] +1 Release jaxr 1.0 spec
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release SAAJ 1.3 spec, v 1.0

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 6:37 AM, Guillaume Nodet wrote:


I've uploaded a release of JAAS 1.3 spec for vote.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jaas_1.3_spec-1.0/
Repo
   http://people.apache.org/~gnodet/staging/geronimo- 
jaas_1.3_spec-1.0/


Please review and vote:
  [ ] +1 Release jaas 1.3 spec
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release JAXRPC 1.1 spec, v 2.0

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 6:51 AM, Guillaume Nodet wrote:


I've uploaded a release of JAXRPC 1.1 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jaxrpc_1.1_spec-2.0/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-jaxrpc_1.1_spec-2.0/
Note that this release depends on the SAAJ 1.3 spec which is being  
released atm



Please review and vote:
  [ ] +1 Release jaxrpc 1.1 spec
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release JTA 1.1 spec, v 1.1.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 6:56 AM, Guillaume Nodet wrote:


I've uploaded a release of JTA 1.1 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jta_1.1_spec-1.1.1/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-jta_1.1_spec-1.1.1/


Please review and vote:
  [ ] +1 Release jta 1.1 spec, v 1.1.1
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release Connector 1.5 spec, v 2.0

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 7:06 AM, Guillaume Nodet wrote:


I've uploaded a release of J2EE Connector 1.5 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-j2ee-connector_1.5_spec-2.0/
Repo
   
http://people.apache.org/~gnodet/staging/geronimo-j2ee-connector_1.5_spec-2.0/
Note: this release depens on the JTA 1.1 spec currently being voted.

Please review and vote:
  [ ] +1 Release j2ee connector 1.5 spec, v 2.0
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release interceptor 3.0 spec, v 1.0.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 7:25 AM, Guillaume Nodet wrote:


I've uploaded a release of Interceptor 3.0 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_3.0_spec-1.0.1/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-interceptor_3.0_spec-1.0.1/


Please review and vote:
  [ ] +1 Release interceptor 3.0 spec, v 1.0.1
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release annotation 1.0 spec, v 1.1.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 7:19 AM, Guillaume Nodet wrote:


I've uploaded a release of annotations 1.0 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.0_spec-1.1.1
Repo
   http://people.apache.org/~gnodet/staging/geronimo-annotation_1.0_spec-1.1.1


Please review and vote:
  [ ] +1 Release annotation 1.0 spec, v 1.1.1
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release EJB 3.0 spec, v 1.0.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 30, 2008, at 8:19 AM, Guillaume Nodet wrote:


Btw, here's my +1

On Jan 29, 2008 4:33 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:

I've uploaded a release of EJB 3.0 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:

http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-ejb_3.0_spec-1.0.1/
Repo
  http://people.apache.org/~gnodet/staging/geronimo-ejb_3.0_spec-1.0.1/
This release depends on the following releases that are being voted  
on:

   geronimo-jta_1.1_spec
  geronimo-interceptor_3.0_spec
  geronimo-annotation_1.0_spec

Please review and vote:
  [ ] +1 Release ejb 3.0 spec, v 1.0.1
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/




--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release J2EE Management 1.1 spec, v 1.0.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 7:45 AM, Guillaume Nodet wrote:


I've uploaded a release of J2EE Management 1.1 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-j2ee-management_1.1_spec-1.0.1/
Repo
   
http://people.apache.org/~gnodet/staging/geronimo-j2ee-management_1.1_spec-1.0.1/
This release depends on the following releases that are being voted  
on:

   geronimo-ejb_3.0_spec
and its own dependencies

Please review and vote:
  [ ] +1 Release j2ee management 1.1 spec, v 1.0.1
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release JACC 1.1 spec, v 1.0.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 8:12 AM, Guillaume Nodet wrote:


I've uploaded a release of JACC 1.1 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0.1/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-jacc_1.1_spec-1.0.1/


Please review and vote:
  [ ] +1 Release JACC 1.1 spec, v 1.0.1
  [ ] -1 Do not release it

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release JPA 3.0 spec, v 1.1.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 8:18 AM, Guillaume Nodet wrote:


I've uploaded a release of JPA 3.0 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jpa_3.0_spec-1.1.1/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-jpa_3.0_spec-1.1.1/


Please review and vote:
  [ ] +1 Release JPA 3.0 spec, v 1.1.1
  [ ] -1 Do not release it



--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release JSP 2.1 spec, v 1.0.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 8:24 AM, Guillaume Nodet wrote:


I've uploaded a release of JSP 2.1 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0.1/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-jsp_2.1_spec-1.0.1/
This release depends on EL 1.0 spec which is being voted


Please review and vote:
  [ ] +1 Release JSP 2.1 spec, v 1.0.1
  [ ] -1 Do not release it



--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release ws-metadata 2.0 spec, 1.1.2

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 29, 2008, at 8:36 AM, Guillaume Nodet wrote:


I've uploaded a release of ws-metadata 2.0 spec for vote.
The main change is that the jar is packaged as an OSGi bundle.
Tag:
   
http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-ws-metadata_2.0_spec-1.1.2/
Repo
   http://people.apache.org/~gnodet/staging/geronimo-ws-metadata_2.0_spec-1.1.2/

Please review and vote:
  [ ] +1 Release ws-metadata 2.0 spec, v 1.1.2
  [ ] -1 Do not release it



--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

[YOKO] premature tools deletion?

[Alan D. Cabrera]

I was wondering if we prematurely deleted tools.  It would be nice to  
have our own IDL compiler.  I was thinking that we could move tools to  
a dir in the sandbox for someone to pick up.  Thoughts?



Regards,
Alan

Re: [YOKO] Yoko web site

[Alan D. Cabrera]

:)


What does XBean and GShell do?


Regards,
Alan

On Jan 16, 2008, at 5:18 PM, Jason Dillon wrote:

Well there is this thing called HTML and you use it to make things  
called "pages" and then put them on a "web server"...


:-P

What do you want... Something backed up by confluence?  Or static  
via svn?


--jason


-Original Message-
From: "Alan D. Cabrera" <[EMAIL PROTECTED]>

Date: Wed, 16 Jan 2008 16:41:30
To:Developers Geronimo 
Subject: [YOKO] Yoko web site


I want to start creating the new Yoko website and wiki.  How do I do
this?


Regards,
Alan

[YOKO] KEYS

[Alan D. Cabrera]

I have removed all the keys but Rick's from the KEYS file since I do  
not recognize who they belong to.  Yoko committers, please feel free  
to add your keys to this file.



Regards,
Alan

[YOKO] Yoko web site

[Alan D. Cabrera]

I want to start creating the new Yoko website and wiki.  How do I do  
this?



Regards,
Alan

Re: [ANNOUNCE] Kevan Miller has been approved as the new PMC Chair for Apache Geronimo

[Alan D. Cabrera]

On Jan 16, 2008, at 12:10 PM, Matt Hogstrom wrote:

Recently I have had several things change personally and I have  
found it increasingly difficult to keep up with the Geronimo mailing  
lists on a daily basis.  As a result, I did some soul searching and  
decided that my intentions to stay on top of Geronimo were good but  
my follow through wasn't   This was specifically in regard to being  
able to respond to people on issues that I needed to do as PMC chair.


I tendered my resignation to the Board earlier this week.  There was  
some discussion on the PMC list about a replacement and the PMC  
unanimously approved Kevan Miller as my successor.  The board just  
approved this request so Kevan now has the mantle for Geronimo as  
the PMC chair.


It is with great pleasure that I announce that Kevan has accepted  
this responsibility of PMC chair.  The beauty is that Kevan has  
already been doing most of the work of the PMC chair anyway and is  
the right person going forward.  Please give it up for Kevan Miller,  
VP, Apache Geronimo!


I'm still noodling with some performance work as time allows so I'm  
not gone.  I'll prolly continue to nag in my own unique way.


Thanks Matt for all the great work.

Congrats Kevan!  I know that you're going to make a great chair!


Regards,
Alan

[YOKO] Heads up

[Alan D. Cabrera]

I'm going to remove the WS that went to CXF tonight.


Regards,
Alan

Re: [YOKO]

[Alan D. Cabrera]

On Jan 15, 2008, at 7:03 AM, Rick McGuire wrote:

The Yoko ORB code still generates 1.4 compatible code.  Since the  
ORB doesn't have any direct dependencies on Geronimo, it probably  
can be maintained as just being dependent on 1.4.  On the other  
hand, there are many times I wished I could use some of the stuff in  
1.5 (such as the concurrency classes).  Harmony is a 1.5 JDK, so 1.4  
compatibility is not an issue for them.  Yoko is used in the never  
released 1.2 Geronimo version too.  I suspect that's going to remain  
in its never released state so I don't think Geronimo is an issue  
either.
I can go either way on the JDK issue depending on what the consensus  
is.



I would LOVE to use JDK1.5.  Maybe Yoko 2.0?  There are plenty of  
backport paths so it's not like we would  be abandoning JDK1.4.



Regards,
Alan

Re: [YOKO]

[Alan D. Cabrera]

On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote:

What cleanup steps need to be taken with the yoko code now that it's  
been made a subproject in Geronimo?  The first obvious one would be  
to remove the non-core components from the trunk.  The second would  
be to remove the "incubating" from the version names.


Agreed

Does the code need to be repackaged so that is  
"org.apache.geronimo.yoko.*"  I see that this is not the case with  
XBEAN, so perhaps we're ok there.  Same basic question about the  
generated artifacts.


I don't think that this needs to, or should be, done.  Let's keep it  
at org.apache.yoko.


The current code was never made into an official Yoko release.   
Should we attempt to get this out as an official v1 release as soon  
as the basic cleanup is completed?


I think that some people had some concerns about a release but I think  
that they were more focused on proper documentation and releasing a  
well rounded product.  It's my opinion that it's ok to release so long  
as the code is good enough.  With that said, I would like to make a  
1.0 release.



Regards,
Alan

Re: [VOTE] Release geronimo-txmanager-2.1

[Alan D. Cabrera]

+1


Regards,
Alan

On Jan 10, 2008, at 2:35 AM, David Blevins wrote:


Discuss thread (for reference):

 http://mail-archives.apache.org/mod_mbox/geronimo-dev/200711.mbox/[EMAIL 
PROTECTED]

Changes since last release:

  

 r585608 | dain | 2007-10-17 10:56:54 -0700 (Wed, 17 Oct 2007) | 1  
line


 Added generic types to all collections usage
  

 r585309 | dain | 2007-10-16 17:54:22 -0700 (Tue, 16 Oct 2007) | 1  
line


 clear proxy reference after returning to caller so the proxy can be  
garbage collected
  

 r584554 | akulshreshtha | 2007-10-14 08:19:58 -0700 (Sun, 14 Oct  
2007) | 1 line


 GERONIMO-3250 Adding counters to keep track of transaction  
activity, Patch by Viet H. Nguyen


Binaries:

 
http://people.apache.org/~dblevins/stage-txmanager/repo/org/apache/geronimo/components/

Branch:

 
http://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1/

Vote will be open for 72 hours and close on the 13th

[ ]  +1  -  Yes, release it
[ ]   0  -  Hmm...
[ ]  -1  -  No, because...


Vote away!

-David

Re: Yoko split

[Alan D. Cabrera]

Heh heh.  Yeah I caught up w/ all my holiday mail and saw that.

We've completed copying, though not paring down, Yoko to the Geronimo  
area.  Are you guys fine with me making the old Yoko area R/O?



Regards,
Alan

On Jan 9, 2008, at 1:32 PM, Daniel Kulp wrote:



Thanks Alan!

I've already started migrating the code over.   It's progressing  
slowly.


Dan


On Wednesday 09 January 2008, Alan D. Cabrera wrote:

On Jan 8, 2008, at 9:22 PM, Alan D. Cabrera wrote:

I can Jira issues over to CXF.  I'm guessing that issues in the
following components need to be moved over:

CorbaBinding
Idl2Wsdl
Wsdl2Idl

I'll leave these assigned to no component for the CXF team to pick
up.


I decided to create a component in CXF named Yoko to hold the old
issues.  It's simple enough to remove when the issues have been
properly classified.


Regards,
Alan




--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: ActiveMQ 5 for g 2.1?

[Alan D. Cabrera]

On Jan 9, 2008, at 1:49 PM, David Jencks wrote:

Anyone interested in seeing if we can upgrade to AMQ 5 for g 2.1?   
Apparently it has removed at least one of the annoying "lets put a  
non-string in system properties" behaviors AMQ 4 liked to foist on us.


cf GERONIMO-3243


Sounds good to me.


Regards,
Alan

Re: Yoko split

[Alan D. Cabrera]

On Jan 8, 2008, at 9:22 PM, Alan D. Cabrera wrote:

I can Jira issues over to CXF.  I'm guessing that issues in the  
following components need to be moved over:


CorbaBinding
Idl2Wsdl
Wsdl2Idl

I'll leave these assigned to no component for the CXF team to pick up.


I decided to create a component in CXF named Yoko to hold the old  
issues.  It's simple enough to remove when the issues have been  
properly classified.



Regards,
Alan