Re: Module restructure

[Jeremy Boynes]

Alan D. Cabrera wrote:


Anything in trunk or branch is unstable.  Anything in tag is stable.



A tag though represents a single point in time. We really need stable 
and unstable branches as I tried to characterise them in the mail that 
started this thread.




We can easily support your scenario and keep w/ standard SVN usage by 
doing:


geronimo/transaction/branches
geronimo/transaction/tags/1_0
geronimo/transaction/tags/1_2
geronimo/transaction/tags/1_3
geronimo/transaction/tags/2_0
geronimo/transaction/tags/2_3
geronimo/transaction/trunk




The problem I saw with that was how someone would easily check out the 
whole tree in order to build from source. I think DB had the same 
concern. 



Hmm, that's a good point.  I think that your example suffers the same 
problem, no?  I think that you either are able to treat modules as 
separate projects and get the configurability that you want or you get a 
nice way to svn co; I'm not sure that we can get both.




Brian's externals idea may address some of that but at the cost of 
additional commit complexity.


--
Jeremy

Re: Module restructure

[Jeremy Boynes]

Brian K. Wallace wrote:

Jeremy Boynes wrote:
| Brian K. Wallace wrote:
|
|> 
|> Wouldn't the proper use of svn:externals take care of a lot of this?
|> have svn co geronimo basically read from the externals to pull whatever
|> modules (as well as other components) you want while letting each module
|> handle its own stable/unstable structure? [obviously have a standard for
|> that structure would be HIGHLY desirable] Might be a chore setting up
|> those externals at first, but after that it'd just be there (unless new
|> modules/etc were added)
|> 
|
|
| All our modules are in the same SVN repo so we don't need to use
| externals, we can just copy. This would be a good option for integrating
| other projects if we needed to do that at the source level. AIUI though
| they would also need to be on SVN and not all are.
|
| --
| Jeremy
|
|
Don't need, and can't use aren't quite the same, tho'. This was the part
that led me to believe (erroneously) that this thread was about
deliverables only. In your example:

.../geronimo/stable/1.0/modules/transaction
.../geronimo/stable/1.2/modules/transaction
.../geronimo/stable/2.0/modules/transaction
.../geronimo/unstable/1.3/modules/transaction
.../geronimo/unstable/2.1/modules/transaction

I'd think that transaction (as well as all other modules) might have
stable, unstable, as well as 'releases'. stable (above) could just
externalize transaction's stable (along with all the other modules), as
could unstable and 'releases' at that higher level.

Obviously this would have to be an SVN only exercise, but if you can
allow a user/developer to check out X and hide that X is made up of 50
different 'externals', but also allow them to check out just 1 of those
50 modules without having to dig through an entire structure... ?

Not thinking you were on track to restructure quite that much, so I'll
go back to 'observing'. :-)


No, you're right to bring this up. This would be a good way to handle a 
module structure like Alan was proposing where the modules themselves 
were at the top level and we had a "J2EE assembly" module that just 
pulled the others together.


AIUI though you can't commit across externals which would mean any work 
that spanned modules would need to be committed from each one which 
would be a little awkward. I would hope that the number of such changes 
will decrease so this will become only an occasional problem. One area 
where we will be doing work in multiple modules are the runtime/builder 
pairs - perhaps we can do a hybrid where e.g. jetty-runtime and 
jetty-builder become a pair of sub-modules under a jetty module.


--
Jeremy

Re: Module restructure

[Alan D. Cabrera]

David Blevins wrote, On 5/27/2005 7:51 PM:

  On Fri, May 27, 2005 at 04:38:45PM -0700, Jeremy Boynes wrote:
  
  
Alan D. Cabrera wrote:


  
Jeremy Boynes wrote, On 5/27/2005 7:26 PM:

  
  
David Blevins wrote:

This one



  ../repos/asf/geronimo/unstable/modules/transaction
../repos/asf/geronimo/stable/modules/transaction

  

  
  Why would we have two versions of transaction?

  

I actually think there are going to be additional ones but was keeping 
it simple to indicate that "stable" came higher up than "transaction". 
Ultimately we might end up with (hypothetically)

.../geronimo/stable/1.0/modules/transaction
.../geronimo/stable/1.2/modules/transaction
.../geronimo/stable/2.0/modules/transaction
.../geronimo/unstable/1.3/modules/transaction
.../geronimo/unstable/2.1/modules/transaction


  
  
Oh, I get it.  You're just proposing to add the linux kernel odd/even spin on what we have now and dump trunk.
  

Anyone know the lore as to why they went odd even?  Was it the case
that the tool that they were using drove them to such an odd
nomenclature?


Regards,
Alan

Re: Module restructure

[Alan D. Cabrera]

Jeremy Boynes wrote, On 5/27/2005 7:52 PM:


Alan D. Cabrera wrote:



I don't particularly care for odd/even designations for 
stable/unstable.  Maybe that was a coincidence in your example.  




I'm not tied to any of the names - it was deliberate but illustrative. 
I do think it would be useful for users to be able to tell just from a 
jar's name whether it was stable or not.


Anything in trunk or branch is unstable.  Anything in tag is stable.



We can easily support your scenario and keep w/ standard SVN usage by 
doing:


geronimo/transaction/branches
geronimo/transaction/tags/1_0
geronimo/transaction/tags/1_2
geronimo/transaction/tags/1_3
geronimo/transaction/tags/2_0
geronimo/transaction/tags/2_3
geronimo/transaction/trunk




The problem I saw with that was how someone would easily check out the 
whole tree in order to build from source. I think DB had the same 
concern. 


Hmm, that's a good point.  I think that your example suffers the same 
problem, no?  I think that you either are able to treat modules as 
separate projects and get the configurability that you want or you get a 
nice way to svn co; I'm not sure that we can get both.



Regards,
Alan

Re: Module restructure

[anita kulshreshtha]

--- Stefan Arentz <[EMAIL PROTECTED]> wrote:
> On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote:
> 
> > 
> So, what I would really like to see wrt Geronimo is
> an absolute  
> minimal server with add-on packages for things like
> a web container,  
> jms provider, etc. You want to host a web app? Throw
> in the Tomcat or  
> Jetty personality. Need JMS too, add ActiveMQ.
> Persistence? Simply  
> add a hibernate deployer. Mix and match so that it
> does what your app  
> needs.

   This is my dream! 
> 
> This is where Geronimo could shine and even take
> away a large chunk  
> of Tomcat; most people just want to deploy their web
> app and  
> optionally add some more services without having to
> understand a full  
> J2EE stack. Geronimo can fill that void extremely
> well I think.  
> (Simple Web Container ..  .. J2EE Monolith)
 I strongly agree. People will have more trust in
their server, if they understand 'everything' running
inside it. As they understand more J2EE they can throw
in more components.

Thanks
Anita

> 
> Ok so just complaining doesn't work well for this
> project, so what I  
> really would like to do is start figuring out how I
> can give Geronimo  
> 'personalities' for popular combinations of
> technology. Like,
> 
>   - Geronimo Kernel + Tomcat + JSTL2.0 + Spring +
> Hibernate
>   - Geronimo Kernel + Web Services
>   - Geronimo Kernel + JMX Enabled custom network
> service
> 
The minimal server (Kernel + Jetty) already works.
I have been using it because of compiler error in
openejb core (CORBA) on jdk1.5. I am working on making
Jetty an add on component like Tomcat

> and then do some writing about it on the wiki. Make
> recipes for  
> people, or even complete packages that are
> downloadable.
> 
> I really think this is how Geronimo can also get
> acceptance with a  
> much larger crowd.
> 
>   S.
> 
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Module restructure

[Brian K. Wallace]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremy Boynes wrote:
| Brian K. Wallace wrote:
|
|> 
|> Wouldn't the proper use of svn:externals take care of a lot of this?
|> have svn co geronimo basically read from the externals to pull whatever
|> modules (as well as other components) you want while letting each module
|> handle its own stable/unstable structure? [obviously have a standard for
|> that structure would be HIGHLY desirable] Might be a chore setting up
|> those externals at first, but after that it'd just be there (unless new
|> modules/etc were added)
|> 
|
|
| All our modules are in the same SVN repo so we don't need to use
| externals, we can just copy. This would be a good option for integrating
| other projects if we needed to do that at the source level. AIUI though
| they would also need to be on SVN and not all are.
|
| --
| Jeremy
|
|
Don't need, and can't use aren't quite the same, tho'. This was the part
that led me to believe (erroneously) that this thread was about
deliverables only. In your example:

.../geronimo/stable/1.0/modules/transaction
.../geronimo/stable/1.2/modules/transaction
.../geronimo/stable/2.0/modules/transaction
.../geronimo/unstable/1.3/modules/transaction
.../geronimo/unstable/2.1/modules/transaction

I'd think that transaction (as well as all other modules) might have
stable, unstable, as well as 'releases'. stable (above) could just
externalize transaction's stable (along with all the other modules), as
could unstable and 'releases' at that higher level.

Obviously this would have to be an SVN only exercise, but if you can
allow a user/developer to check out X and hide that X is made up of 50
different 'externals', but also allow them to check out just 1 of those
50 modules without having to dig through an entire structure... ?

Not thinking you were on track to restructure quite that much, so I'll
go back to 'observing'. :-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCl7KKaCoPKRow/gARAqsSAJ9jd9TCHzDKo3Jevs9/3x22jEJLiQCg0rOd
rI/bBEIW5t8tUn/Gkq1SPOI=
=V9zh
-END PGP SIGNATURE-

Re: Module restructure

[Jeremy Boynes]

Alan D. Cabrera wrote:


I don't particularly care for odd/even designations for 
stable/unstable.  Maybe that was a coincidence in your example.  



I'm not tied to any of the names - it was deliberate but illustrative. I 
do think it would be useful for users to be able to tell just from a 
jar's name whether it was stable or not.


We can 
easily support your scenario and keep w/ standard SVN usage by doing:


geronimo/transaction/branches
geronimo/transaction/tags/1_0
geronimo/transaction/tags/1_2
geronimo/transaction/tags/1_3
geronimo/transaction/tags/2_0
geronimo/transaction/tags/2_3
geronimo/transaction/trunk




The problem I saw with that was how someone would easily check out the 
whole tree in order to build from source. I think DB had the same concern.


--
Jeremy

Re: Module restructure

[David Blevins]

On Fri, May 27, 2005 at 04:38:45PM -0700, Jeremy Boynes wrote:
> Alan D. Cabrera wrote:
> >
> >
> >Jeremy Boynes wrote, On 5/27/2005 7:26 PM:
> >
> >>David Blevins wrote:
> >>
> >>This one
> >>
> >>>
> >>> ../repos/asf/geronimo/unstable/modules/transaction
> >>> ../repos/asf/geronimo/stable/modules/transaction
> >>>
> >Why would we have two versions of transaction?
> >
> 
> I actually think there are going to be additional ones but was keeping 
> it simple to indicate that "stable" came higher up than "transaction". 
> Ultimately we might end up with (hypothetically)
> 
> .../geronimo/stable/1.0/modules/transaction
> .../geronimo/stable/1.2/modules/transaction
> .../geronimo/stable/2.0/modules/transaction
> .../geronimo/unstable/1.3/modules/transaction
> .../geronimo/unstable/2.1/modules/transaction
> 

Oh, I get it.  You're just proposing to add the linux kernel odd/even spin on 
what we have now and dump trunk.

-David

Re: Module restructure

[Alan D. Cabrera]

Jeremy Boynes wrote, On 5/27/2005 7:38 PM:


Alan D. Cabrera wrote:


Jeremy Boynes wrote, On 5/27/2005 7:26 PM:


David Blevins wrote:

This one



 ../repos/asf/geronimo/unstable/modules/transaction
 ../repos/asf/geronimo/stable/modules/transaction


Why would we have two versions of transaction?



I actually think there are going to be additional ones but was keeping 
it simple to indicate that "stable" came higher up than "transaction". 
Ultimately we might end up with (hypothetically)


.../geronimo/stable/1.0/modules/transaction
.../geronimo/stable/1.2/modules/transaction
.../geronimo/stable/2.0/modules/transaction
.../geronimo/unstable/1.3/modules/transaction
.../geronimo/unstable/2.1/modules/transaction

Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 
requiring JDK1.5. 


I don't particularly care for odd/even designations for 
stable/unstable.  Maybe that was a coincidence in your example.  We can 
easily support your scenario and keep w/ standard SVN usage by doing:


geronimo/transaction/branches
geronimo/transaction/tags/1_0
geronimo/transaction/tags/1_2
geronimo/transaction/tags/1_3
geronimo/transaction/tags/2_0
geronimo/transaction/tags/2_3
geronimo/transaction/trunk


Regards,
Alan

Re: Module restructure

[Jeremy Boynes]

Brian K. Wallace wrote:


Wouldn't the proper use of svn:externals take care of a lot of this?
have svn co geronimo basically read from the externals to pull whatever
modules (as well as other components) you want while letting each module
handle its own stable/unstable structure? [obviously have a standard for
that structure would be HIGHLY desirable] Might be a chore setting up
those externals at first, but after that it'd just be there (unless new
modules/etc were added)



All our modules are in the same SVN repo so we don't need to use 
externals, we can just copy. This would be a good option for integrating 
other projects if we needed to do that at the source level. AIUI though 
they would also need to be on SVN and not all are.


--
Jeremy

Re: Module restructure

[Jeremy Boynes]

Alan D. Cabrera wrote:



Jeremy Boynes wrote, On 5/27/2005 7:26 PM:


David Blevins wrote:

This one



 ../repos/asf/geronimo/unstable/modules/transaction
 ../repos/asf/geronimo/stable/modules/transaction


Why would we have two versions of transaction?



I actually think there are going to be additional ones but was keeping 
it simple to indicate that "stable" came higher up than "transaction". 
Ultimately we might end up with (hypothetically)


.../geronimo/stable/1.0/modules/transaction
.../geronimo/stable/1.2/modules/transaction
.../geronimo/stable/2.0/modules/transaction
.../geronimo/unstable/1.3/modules/transaction
.../geronimo/unstable/2.1/modules/transaction

Where, for example, 1.x is J2EE1.4 requiring JDK1.4 and 2.x is J2EE1.5 
requiring JDK1.5.


--
Jeremy

Re: Module restructure

[Brian K. Wallace]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alan D. Cabrera wrote:
|
|
| Jeremy Boynes wrote, On 5/27/2005 7:26 PM:
|
|> David Blevins wrote:
|>
|> This one
|>
|>>
|>>  ../repos/asf/geronimo/unstable/modules/transaction
|>>  ../repos/asf/geronimo/stable/modules/transaction
|>>
| Why would we have two versions of transaction?
|
|
| Regards,
| Alan
|
|
|

Wouldn't the proper use of svn:externals take care of a lot of this?
have svn co geronimo basically read from the externals to pull whatever
modules (as well as other components) you want while letting each module
handle its own stable/unstable structure? [obviously have a standard for
that structure would be HIGHLY desirable] Might be a chore setting up
those externals at first, but after that it'd just be there (unless new
modules/etc were added)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCl67YaCoPKRow/gARAlgcAJ49h37F3OBvnPiPpR5V2GPj+XqCUQCg2s8b
BhOfXzsntTFnFzw82VLIedY=
=wtD9
-END PGP SIGNATURE-

Re: Module restructure

[Alan D. Cabrera]

Jeremy Boynes wrote, On 5/27/2005 7:26 PM:


David Blevins wrote:

This one



 ../repos/asf/geronimo/unstable/modules/transaction
 ../repos/asf/geronimo/stable/modules/transaction


Why would we have two versions of transaction?


Regards,
Alan

Re: Module restructure

[Jeremy Boynes]

David Blevins wrote:

This one


 ../repos/asf/geronimo/unstable/modules/transaction
 ../repos/asf/geronimo/stable/modules/transaction



--
Jeremy

Re: Module restructure

[Jeremy Boynes]

Bruce Snyder wrote:

On 5/27/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:



One of the reasons for going with a modular structure in the first place
was to make the totality more manageable while still being able to
develop each module. For small projects I would agree it is probably not
worth it, but most large distributed projects have gone that way: look
at HTTPD + mod_*, Tomcat + commons-*, Maven + plugins, Eclipse +
plugins, ...

The community is asking for subsets of functionality - we should use the
module structure to give it to them rather than waiting for a release at
the global level (especially with the overhead of certification testing).



Are you now talking about what should be distributed to users as
opposed to the dir structure of the SVN repo? Or are you talking about
the two as one in the same (i.e. certain subsets of the project should
be reflected in the SVN repo dir structure, not hidden in the build
scripts)?



The two are related as we are already generating artifact jars for each 
of the modules that fit the functions that people are asking for (e.g. 
transaction, connector). All I am really saying is that we should have 
stable/unstable versions at the module level so that they know which 
ones are safe to use. The structure I proposed does this but also allows 
someone to easily check out and build an entire stable or unstable tree.


This also applies to us - for example, transaction is not changing so 
rather than build from a SNAPSHOT all the time we could use a known 
version. This would cut the build time too :-)


--
Jeremy

Re: Module restructure

[David Blevins]

On Fri, May 27, 2005 at 06:33:49PM -0400, Geir Magnusson Jr. wrote:
> 
> On May 27, 2005, at 4:25 PM, David Blevins wrote:
> 
> >Yea, I was just about to post that.  Stable/unstable refers to  
> >branches.
> >
> 
> But jeremy is right here (but forgot to say it) - because we're using  
> SVN, you want to keep the branches in a separate root so that
> 
>   svn co geronimo
> 
> doesn't bring down every branch, but just gets you the current head.
> 
> As long as we're in the same SVN repo, the fact that we have  
> different roots is irrelevant from the POV of making copies (aka  
> "branching"), but it's a big help for users.

Yea, I get that.  But I think Jeremy is proposing more of this:

 ../repos/asf/geronimo/transaction/unstable
 ../repos/asf/geronimo/transaction/stable

than this:

 ../repos/asf/geronimo/unstable/modules/transaction
 ../repos/asf/geronimo/stable/modules/transaction

Jeremy?

-David


> 
> geir
> 
> >-David
> >
> >On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote:
> >
> >>Clearly, we need something like this to get organized around the
> >>final push for certification and the 1.0 release, by why not just
> >>branch for the stable, and head is unstable?
> >>
> >>geir
> >>
> >>On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote:
> >>
> >>
> >>>Stefan brings up the question of whether we want to release sub-
> >>>modules of Geronimo separately. I think this is a good idea and
> >>>would propose the following restructure of the tree to move in this
> >>>direction.
> >>>
> >>>Rather than "trunk" in the root, we have three separate trees:
> >>>
> >>>stablesimilar to even-numbered versions of Linux, this tree
> >>> would contain stable code intended for production use
> >>> and operates with a focus on stability (i.e. well
> >>> documented stable APIs, backward compatibility, no
> >>> SNAPSHOT dependencies etc.)
> >>> There will be multiple branches as needed.
> >>>
> >>>unstable  similar to odd-numbered versions this is where new
> >>> development is done and APIs etc. are much more
> >>> likely to change. We may still do releases from here
> >>> but they are quite likely to be incompatible; it may
> >>> be all we package from here are nightlies.
> >>>
> >>>sandbox   as now, a free-for-all area for trying out new ideas
> >>> and experimenting with new technologies
> >>>
> >>>Given the size of the codebase, we need to preserve the module
> >>>structure that we have in the current trunk. However, even now some
> >>>modules are more stable than others (e.g. the transaction and
> >>>connector ones Thierry is looking to use) and I think are in a
> >>>position where they can be versioned separately.
> >>>
> >>>With the structure above in place, we can move modules into the
> >>>stable or unstable trees as appropriate. For those that we consider
> >>>stable (e.g. transaction) we can cut numbered releases that people
> >>>can use standalone.
> >>>
> >>>This will also speed the unstable build as we won't need to check
> >>>SNAPSHOTs for everything all the time.
> >>>
> >>>I would suggest we start on this as part of packaging for M4 and
> >>>would be willing to co-ordinate.
> >>>
> >>>--
> >>>Jeremy
> >>>
> >>>
> >>>
> >>
> >>-- 
> >>Geir Magnusson Jr  +1-203-665-6437
> >>[EMAIL PROTECTED]
> >>
> >>
> >
> >
> 
> -- 
> Geir Magnusson Jr  +1-203-665-6437
> [EMAIL PROTECTED]
> 

Re: Module restructure

[Bruce Snyder]

On 5/27/05, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

> One of the reasons for going with a modular structure in the first place
> was to make the totality more manageable while still being able to
> develop each module. For small projects I would agree it is probably not
> worth it, but most large distributed projects have gone that way: look
> at HTTPD + mod_*, Tomcat + commons-*, Maven + plugins, Eclipse +
> plugins, ...
> 
> The community is asking for subsets of functionality - we should use the
> module structure to give it to them rather than waiting for a release at
> the global level (especially with the overhead of certification testing).

Are you now talking about what should be distributed to users as
opposed to the dir structure of the SVN repo? Or are you talking about
the two as one in the same (i.e. certain subsets of the project should
be reflected in the SVN repo dir structure, not hidden in the build
scripts)?

Bruce 
-- 
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: Module restructure

[Jeremy Boynes]

David Blevins wrote:

On Fri, May 27, 2005 at 09:40:52AM -0700, Jeremy Boynes wrote:


Geir Magnusson Jr. wrote:


Clearly, we need something like this to get organized around the
final push for certification and the 1.0 release, by why not just
branch for the stable, and head is unstable?



The names are just suggestions - "trunk", "head", "unstable",
whatever.

The important thing is that you can easily checkout and build each
tree on its own so we can't have both stable and unstable branches
of modules (e.g. transaction) under trunk.




I think we are going to have a hard enough time managing and merging
between stable/unstable branches of the code in general let alone at
the submodule level.  I'd prefer to get used to that before trying it
at the submodule level.



One of the reasons for going with a modular structure in the first place 
was to make the totality more manageable while still being able to 
develop each module. For small projects I would agree it is probably not 
worth it, but most large distributed projects have gone that way: look 
at HTTPD + mod_*, Tomcat + commons-*, Maven + plugins, Eclipse + 
plugins, ...


The community is asking for subsets of functionality - we should use the 
module structure to give it to them rather than waiting for a release at 
the global level (especially with the overhead of certification testing).


--
Jeremy

Re: Why are gbeans not serialized but the gbean attributes are?

[Dain Sundstrom]

On May 25, 2005, at 7:24 AM, Aaron Mulder wrote:


The more interesting question is Hiram's point on providing more
advanced support for attribute contruction.  This seems to be one  
of the

advantages Dain's Spring-based kernel provides.


Right. One big advantage of the Spring based kernel is the attributes  
get the same quality of service as the top-level named service (a  
GBean in geronimo nomenclature).  In geronimo we save the "recipe"  
for a service, meaning we save the name of the class to construct,  
the attribute values to inject and the references to inject.  When  
the service is restarted, we follow the recipe to create a new  
instance of the service.  In the spring based kernel, not only do we  
have a recipe for the top-level named service, but the attributes can  
also be saved as a "recipe".  This means an attribute can be  
arbitrarily complex without having to support serialization.


-dain

Re: Why are gbeans not serialized but the gbean attributes are?

[Dain Sundstrom]

In geronimo only the attributes explicitly marked as "persistent" in  
the GBeanInfo are serialized.  The magic attributes are not allowed  
to be marked as persistent.


-dain


On May 25, 2005, at 6:23 AM, Srinath Perera wrote:


Hi Hiram;

I will try to give a possible reason ..

Not all the attributes in the GBeans are serializable, e.g.
ClassLoader, kernel attributes
in a GBean are not serializable, and have a special meaning in the
enviorment it runs.

those so called magic attributes get the values from the enviorment ..
so serializing them do not make sense. I belive this is a reason
making attributes Serializable (only the persitant ones), but not the
GBeans,

Thanks
Srinath

On 5/21/05, Hiram Chirino <[EMAIL PROTECTED]> wrote:

I've been trying to analyze the reason why gbean attributes HAVE  
to be

serializable.

The facts are that:
  1. A gbean itself does not need to be serializable.
  2. Only the gbean attributes are serialized.
  3. The de-serialized attributes are injected at runtime to  
construct

the gbean.

My question is why does a gbean get different treatment than  
attribute?

  I've got a feeling it's this way because gbeans are complex objects
while most gbean attributes are simple types.  But we are starting to
see gbean objects that have complex attribute types.

Why not also give gbean attributes the kind of runtime construction
support that is given to gbeans?  If this was done, then you don't
force complex attributes to implement the Serializable interfaces.
This could go a long way in helping solve some of the serialization
issues that are being discussed in other threads.

Regards,
Hiram Chirino

Re: Module restructure

[Geir Magnusson Jr.]

On May 27, 2005, at 4:25 PM, David Blevins wrote:

Yea, I was just about to post that.  Stable/unstable refers to  
branches.




But jeremy is right here (but forgot to say it) - because we're using  
SVN, you want to keep the branches in a separate root so that


  svn co geronimo

doesn't bring down every branch, but just gets you the current head.

As long as we're in the same SVN repo, the fact that we have  
different roots is irrelevant from the POV of making copies (aka  
"branching"), but it's a big help for users.


geir


-David

On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote:


Clearly, we need something like this to get organized around the
final push for certification and the 1.0 release, by why not just
branch for the stable, and head is unstable?

geir

On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote:



Stefan brings up the question of whether we want to release sub-
modules of Geronimo separately. I think this is a good idea and
would propose the following restructure of the tree to move in this
direction.

Rather than "trunk" in the root, we have three separate trees:

stablesimilar to even-numbered versions of Linux, this tree
 would contain stable code intended for production use
 and operates with a focus on stability (i.e. well
 documented stable APIs, backward compatibility, no
 SNAPSHOT dependencies etc.)
 There will be multiple branches as needed.

unstable  similar to odd-numbered versions this is where new
 development is done and APIs etc. are much more
 likely to change. We may still do releases from here
 but they are quite likely to be incompatible; it may
 be all we package from here are nightlies.

sandbox   as now, a free-for-all area for trying out new ideas
 and experimenting with new technologies

Given the size of the codebase, we need to preserve the module
structure that we have in the current trunk. However, even now some
modules are more stable than others (e.g. the transaction and
connector ones Thierry is looking to use) and I think are in a
position where they can be versioned separately.

With the structure above in place, we can move modules into the
stable or unstable trees as appropriate. For those that we consider
stable (e.g. transaction) we can cut numbered releases that people
can use standalone.

This will also speed the unstable build as we won't need to check
SNAPSHOTs for everything all the time.

I would suggest we start on this as part of packaging for M4 and
would be willing to co-ordinate.

--
Jeremy





--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]







--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Module restructure

[David Blevins]

On Fri, May 27, 2005 at 09:40:52AM -0700, Jeremy Boynes wrote:
> Geir Magnusson Jr. wrote:
> >Clearly, we need something like this to get organized around the  final 
> >push for certification and the 1.0 release, by why not just  branch for 
> >the stable, and head is unstable?
> >
> 
> The names are just suggestions - "trunk", "head", "unstable", whatever.
> 
> The important thing is that you can easily checkout and build each tree 
> on its own so we can't have both stable and unstable branches of modules 
> (e.g. transaction) under trunk.
> 

I think we are going to have a hard enough time managing and merging between 
stable/unstable branches of the code in general let alone at the submodule 
level.  I'd prefer to get used to that before trying it at the submodule level.

-David

Re: Module restructure

[David Blevins]

Yea, I was just about to post that.  Stable/unstable refers to branches.

-David

On Fri, May 27, 2005 at 12:18:03PM -0400, Geir Magnusson Jr. wrote:
> Clearly, we need something like this to get organized around the  
> final push for certification and the 1.0 release, by why not just  
> branch for the stable, and head is unstable?
> 
> geir
> 
> On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote:
> 
> >Stefan brings up the question of whether we want to release sub- 
> >modules of Geronimo separately. I think this is a good idea and  
> >would propose the following restructure of the tree to move in this  
> >direction.
> >
> >Rather than "trunk" in the root, we have three separate trees:
> >
> >stablesimilar to even-numbered versions of Linux, this tree
> >  would contain stable code intended for production use
> >  and operates with a focus on stability (i.e. well
> >  documented stable APIs, backward compatibility, no
> >  SNAPSHOT dependencies etc.)
> >  There will be multiple branches as needed.
> >
> >unstable  similar to odd-numbered versions this is where new
> >  development is done and APIs etc. are much more
> >  likely to change. We may still do releases from here
> >  but they are quite likely to be incompatible; it may
> >  be all we package from here are nightlies.
> >
> >sandbox   as now, a free-for-all area for trying out new ideas
> >  and experimenting with new technologies
> >
> >Given the size of the codebase, we need to preserve the module  
> >structure that we have in the current trunk. However, even now some  
> >modules are more stable than others (e.g. the transaction and  
> >connector ones Thierry is looking to use) and I think are in a  
> >position where they can be versioned separately.
> >
> >With the structure above in place, we can move modules into the  
> >stable or unstable trees as appropriate. For those that we consider  
> >stable (e.g. transaction) we can cut numbered releases that people  
> >can use standalone.
> >
> >This will also speed the unstable build as we won't need to check  
> >SNAPSHOTs for everything all the time.
> >
> >I would suggest we start on this as part of packaging for M4 and  
> >would be willing to co-ordinate.
> >
> >--
> >Jeremy
> >
> >
> 
> -- 
> Geir Magnusson Jr  +1-203-665-6437
> [EMAIL PROTECTED]
> 

Re: Limited purpose Geronimo assemblies

[Jeremy Boynes]

David Jencks wrote:
In the Module Restructuring thread a couple people indicated how nice it 
would be if it was easy to set up limited purpose geronimo versions, 
such as web-only.


Making this easy has always been one of our aims.  Two existing examples 
are openejb (ejb + jta + j2ca) and IBM gluecode se (formerly Gluecode 
Joe se) (web + portlets + jms + jta + j2ca)


Jeremy has been working on some maven plugins to make this kind of setup 
more systematic: the configuration plugin, designed to build a 
"pre-deployed" configuration ready to load into a geronimo kernel, and 
the assembly plugin, designed to package up a bunch of configurations, a 
repository, and the rest of what you need to have a packaged 
geronimo-in-a-jar.  I think it would be great if we could get these 
plugins working reliably and use them in our standard build.  We 
definitely want to have several standard limited geronimo assemblies as 
part of the build.




A technical issue here is being able to identify and resolve the 
dependencies defined by the MCP entries in the root jar. I want to add 
them into the plan so the service builder can handle them but have been 
holding off until after certification.


--
Jeremy

Re: Module restructure

[Jeremy Boynes]

Stefan

This is exactly what we have been aiming for :-)

To a large extent you can already do this today. You can mix-and-match 
the different modules simply by providing a custom configuration plan.


As a concrete example, this is what we did at Gluecode to build the JOE 
SE product which aimed at filling your : Servlet + JSP + JMS + 
services such as deployment, transactions and database access.


Geronimo is not a J2EE monolith - it is a collection of system services 
and a kernel to bind them together. What we certify is a J2EE monolith 
because it has to pass *ALL* the CTS tests but that is just one 
assembled form.


--
Jeremy

Stefan Arentz wrote:

On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote:

Stefan brings up the question of whether we want to release sub- 
modules of Geronimo separately. I think this is a good idea and  would 
propose the following restructure of the tree to move in this  direction.



Let me just explain my motivation a bit, maybe that will also help  for 
the plan.


In my original email I said something about not needing all the J2EE  
stuff. I exaggerated a bit of course, but most of the applications  that 
I have been writing in the last couple of years are done mostly  with a 
subset of the whole J2EE umbrella. Some apps were just some  network 
service wrapped in (JMX) beans, a service exposed with Spring  (Burlap, 
XML-RPC) other apps were simply a web app backed by a shared  Spring 
context. I've never needed all the stuff in J2EE.


So far I've always done this on JBoss. Their MBean stuff works ok,  but 
I wish it was easier to 'downsize' jboss to just a container with  the 
stuff I need. That never really seemed to be their goal however.  The 
complexity of their configuration files shows that.


So, what I would really like to see wrt Geronimo is an absolute  minimal 
server with add-on packages for things like a web container,  jms 
provider, etc. You want to host a web app? Throw in the Tomcat or  Jetty 
personality. Need JMS too, add ActiveMQ. Persistence? Simply  add a 
hibernate deployer. Mix and match so that it does what your app  needs.


This is where Geronimo could shine and even take away a large chunk  of 
Tomcat; most people just want to deploy their web app and  optionally 
add some more services without having to understand a full  J2EE stack. 
Geronimo can fill that void extremely well I think.  (Simple Web 
Container ..  .. J2EE Monolith)


Ok so just complaining doesn't work well for this project, so what I  
really would like to do is start figuring out how I can give Geronimo  
'personalities' for popular combinations of technology. Like,


 - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate
 - Geronimo Kernel + Web Services
 - Geronimo Kernel + JMX Enabled custom network service

and then do some writing about it on the wiki. Make recipes for  people, 
or even complete packages that are downloadable.


I really think this is how Geronimo can also get acceptance with a  much 
larger crowd.


 S.

Re: Module restructure

[Jeremy Boynes]

David Jencks wrote:
I'm worried that it would be a giant hassle to try to assemble a 
geronimo that is 90% stable and 10% unstable.


I would have thought that would be an assembly that used 90% stable 
module versions and 10% unstable ones. Where would the hassle be?


I also don't see the advantage of this plan over simply creating a 
branch whenever someone wants to do some disruptive experimentation, and 
merging the results back in when appropriate.  This worked fine for me 
for the work I did rewriting the jetty deployer. If I understand the svn 
docs this is more in line with "standard svn practice".




The big problem is the merge back. If the main branch is continually 
evolving then that becomes very painful. The intention here was to have 
an unstable tree that is continually and rapidly evolving and a stable 
tree where you can easily merge to because it isn't.


The other challenge is to support collaborative development of new 
features where more than one person can be working on it. That means 
making it easy to checkout and build the unstable tree.


There is nothing precluding what you are saying, either within the 
unstable tree or in the sandbox.


--
Jeremy

[jira] Created: (GERONIMO-657) Running configurations not saved on shutdown

[Dain Sundstrom (JIRA)]

Running configurations not saved on shutdown


 Key: GERONIMO-657
 URL: http://issues.apache.org/jira/browse/GERONIMO-657
 Project: Geronimo
Type: Bug
Reporter: Dain Sundstrom


When the server shuts down the current running configuration should be saved to 
var/config/config.list but it doesn't look like this code works anymore.  It 
would be nice if there were a test case for this functionality.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-631) Package Derby tools with Geronimo

[Dain Sundstrom (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]

Dain Sundstrom reassigned GERONIMO-631:
---

Assign To: John Sisson

Good idea.  Thanks for volunteering :)

> Package Derby tools with Geronimo
> -
>
>  Key: GERONIMO-631
>  URL: http://issues.apache.org/jira/browse/GERONIMO-631
>  Project: Geronimo
> Type: Improvement
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Minor

>
> IBM now has donated the JDBC network driver code to the Derby project (as a 
> patch) and it is under review (not committed).  Once it has been accepted and 
> included in a formal Derby release, it would be worthwhile including it with 
> Geronimo, along with some simple scripts to invoke Derby's ij tool, so 
> Geronimo users can easily manage the embedded Derby database(s).
> FYI.. the donated JDBC network driver supports XA.
> Here is a mail thread titled "Provision of derby tools JAR and JDBC network 
> driver JAR" from the dev list...
> [EMAIL PROTECTED] wrote:
> > If a Java application (not J2EE app) provides a database creation utility 
> > and expects to be able to use a JDBC network driver to connect to the 
> > Derby network server embedded in Geronimo, then currently the command line 
> > application (the database creation utility) needs access (assuming the IBM 
> > Universal Driver is used) to db2jcc.jar and db2jcc_license_c.jar . 
> > 
> > On the Derby lists I saw that IBM is planning on donating a JDBC network 
> > driver sometime in March. 
> > 
> > Q1. Would it make sense to place this driver jar and the derbytools jar in 
> > the  geronimo/repository/incubator-derby/jars directory to accompany the 
> > other derby jars so we provide all the required jars needed for connecting 
> > to and administering the Derby database embedded in Geronimo (even though 
> > the driver or tools won't be loaded by Geronimo)?
> > 
> Yes - we already configure and start the network server so having the 
> client jars available would make sense. These could also be used to 
> connect to a Derby instance in a different JVM.
> > Q2. Even if we do provide all the JARs in the repository, users of a 
> > command line Java application (running on the same machine) would probably 
> > have to edit their classpath to point to the correct  version of JDBC 
> > driver that matches the version of Derby embedded in Geronimo.  Any 
> > suggestions on how this could be automated (determining the version and 
> > getting the driver JAR)?
> > 
> I think it would depend on how the client app expected this to work and 
> whether it relied on having them in the system classpath or did some 
> fancy uber-jar type thing.
> One option would be to deploy the client along with the server (EAR) as 
> a J2EE Application Client. IIRC the app client can have a plan 
> associated with it where they can specify dependencies just like with 
> server-side modules.
> --
> Jeremy

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-636) Run Geronimo Server

[Dain Sundstrom (JIRA)]

 [ 
http://issues.apache.org/jira/browse/GERONIMO-636?page=comments#action_66488 ]
 
Dain Sundstrom commented on GERONIMO-636:
-

This is normally caused by the mx4j remoting jar not being on the system 
classpath.  The normal geronimo executable server.jar contains this jar, so I'm 
going to need more information.

What command did you execute?
What is the java vm vendor and version number?
What OS vendor and version are you using?
If you got a stack trace can you post it?

> Run Geronimo Server
> ---
>
>  Key: GERONIMO-636
>  URL: http://issues.apache.org/jira/browse/GERONIMO-636
>  Project: Geronimo
> Type: Bug
> Reporter: Night Blue

>
> I have downloaded the Geronimo installer and install Geronimo. When I have 
> attempted to start the server the following error is arised:
>  Caused by java.net.MalformedURLException: UnSupported protocol RMI
>  What is wrong here?
>  PS: I did not find any mailing list to send this, so I have sent it here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Limited purpose Geronimo assemblies

[David Jencks]

In the Module Restructuring thread a couple people indicated how nice 
it would be if it was easy to set up limited purpose geronimo versions, 
such as web-only.


Making this easy has always been one of our aims.  Two existing 
examples are openejb (ejb + jta + j2ca) and IBM gluecode se (formerly 
Gluecode Joe se) (web + portlets + jms + jta + j2ca)


Jeremy has been working on some maven plugins to make this kind of 
setup more systematic: the configuration plugin, designed to build a 
"pre-deployed" configuration ready to load into a geronimo kernel, and 
the assembly plugin, designed to package up a bunch of configurations, 
a repository, and the rest of what you need to have a packaged 
geronimo-in-a-jar.  I think it would be great if we could get these 
plugins working reliably and use them in our standard build.  We 
definitely want to have several standard limited geronimo assemblies as 
part of the build.


Many thanks,
david jencks

Re: Module restructure

[Bruce Snyder]

On 5/27/05, Brian K. Wallace <[EMAIL PROTECTED]> wrote:


> | Security-wise it is also a nightmare. There is so much stuff running  in
> | the container that I have no idea of. I usually bind the instance  to
> | localhost and do port translation for those TCP/IP services that  need
> | to be exposed, but even then there are still many ways to  connect to it
> | from localhost that could potentially expose  information or give
> | control to unauthorized people.
> |
> |  S.
> |
> Exactly. And seeing another huge "everything to everyone" server is why
> I never got motivated to do more than observe Geronimo. I'd be better
> served keeping up on what I have to do to keep my existing 'monolith' as
> secure as possible. If it can be broken down, re-arranged, reassembled -
> and still "just work", it would be THE server to use - not just
> "another" server.

I think that this discussion thread now has two distinctly different topics: 

a) Geronimo SVN repo restructuring 
b) Geronimo modules packaging for user consumption 

Can we please split this discussion and keep each one on topic? 

Bruce 
-- 
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: Module restructure

[Brian K. Wallace]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefan Arentz wrote:
| ...
|
| Security-wise it is also a nightmare. There is so much stuff running  in
| the container that I have no idea of. I usually bind the instance  to
| localhost and do port translation for those TCP/IP services that  need
| to be exposed, but even then there are still many ways to  connect to it
| from localhost that could potentially expose  information or give
| control to unauthorized people.
|
|  S.
|
Exactly. And seeing another huge "everything to everyone" server is why
I never got motivated to do more than observe Geronimo. I'd be better
served keeping up on what I have to do to keep my existing 'monolith' as
secure as possible. If it can be broken down, re-arranged, reassembled -
and still "just work", it would be THE server to use - not just
"another" server.

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCl2kZaCoPKRow/gARAtT0AKDTGdqFdKGwhwMqVOmsSGkKPLXkXgCeL2vr
ua9uF67yfhbZMVPcztRL7IM=
=qcty
-END PGP SIGNATURE-

Re: Module restructure

[David Jencks]

I'm worried that it would be a giant hassle to try to assemble a 
geronimo that is 90% stable and 10% unstable.


I also don't see the advantage of this plan over simply creating a 
branch whenever someone wants to do some disruptive experimentation, 
and merging the results back in when appropriate.  This worked fine for 
me for the work I did rewriting the jetty deployer. If I understand the 
svn docs this is more in line with "standard svn practice".


thanks
david jencks

On May 27, 2005, at 11:25 AM, Jeremy Boynes wrote:


Aaron Mulder wrote:

On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
so we have /trunk and /branches/stable and /branches/unstable, the  
former for release work, and the latter for really nutty stuff that  
people want to work on, and head is where mainline development  
continues?
	Who's responsible for merging changes between branches so that 
unstable gets all the changes that go into stable and trunk?  That 
seems likely to be painful.


We are. Stable is, well, stable, so there will be relatively few 
changes made directly there (mainly bugfixes). The biggest chore will 
be merging new features from (unstable,trunk) into stable as part of a 
new release.  For a major release, we may just say the unstable tree 
is now stable and  copy it over en-masse; for an incremental release 
we may need to merge.




Also, is the expectation that a given module only goes in one
place (so transactions, if high-quality, have source only in stable or
whatever), or is the same code in all 3 and you're just expected to 
know

where to work on it?  If the latter, that sounds unwieldy too.  If the
former, then we should just have 2 or 3 separate dirs with their own
trunk, branches, and tags, right?


Taking transaction as an example, let's say we consider it stable now. 
We would have that as a module in the stable tree and the build would 
output a specific version (say transaction-1.0.1). We would not need a 
copy in the unstable tree, the unstable assembly could just use that 
artifact.


Now, David decides to implement some new feature, he copies the stable 
branch into the unstable tree and starts implementing. At some point 
he wants to integrate that with the unstable assembly so updates it to 
use a SNAPSHOT version of his new module. When he's done and we all 
agree that this should be part of the stable build, we merge the 
changes back into the stable tree and re-release (say as 
transaction-1.2.0).  The merge should not be too painful because there 
would not have been a lot of changes in the stable tree.


If he's done, we can switch the unstable assembly back to using the 
new release build and delete the transaction module from the unstable 
tree; if he wants to keep working on it then we just leave it there.


The idea is to create a balance between users who want stable versions 
that they can use and the desire to innovate.


--
Jeremy

Re: Module restructure

[Stefan Arentz]

On May 27, 2005, at 8:25 PM, Brian K. Wallace wrote:

...


I'm not a committer, nor have I been more than an observer to what
Geronimo is doing and where it's going - primarily because everything
I've seen has placed it in the JBoss realm. I've used JBoss for  
quite a

while and am always amazed at the functionality it has ingrained in it
for which I just have no use. Most of my time spent upgrading is in
finding out how to turn things off that have changed.


Security-wise it is also a nightmare. There is so much stuff running  
in the container that I have no idea of. I usually bind the instance  
to localhost and do port translation for those TCP/IP services that  
need to be exposed, but even then there are still many ways to  
connect to it from localhost that could potentially expose  
information or give control to unauthorized people.


 S.

Re: Module restructure

[Brian K. Wallace]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefan Arentz wrote:
| On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote:
|
|> Stefan brings up the question of whether we want to release sub-
|> modules of Geronimo separately. I think this is a good idea and  would
|> propose the following restructure of the tree to move in this  direction.
|
|
| Let me just explain my motivation a bit, maybe that will also help  for
| the plan.
|
| In my original email I said something about not needing all the J2EE
| stuff. I exaggerated a bit of course, but most of the applications  that
| I have been writing in the last couple of years are done mostly  with a
| subset of the whole J2EE umbrella. Some apps were just some  network
| service wrapped in (JMX) beans, a service exposed with Spring  (Burlap,
| XML-RPC) other apps were simply a web app backed by a shared  Spring
| context. I've never needed all the stuff in J2EE.
|
| So far I've always done this on JBoss. Their MBean stuff works ok,  but
| I wish it was easier to 'downsize' jboss to just a container with  the
| stuff I need. That never really seemed to be their goal however.  The
| complexity of their configuration files shows that.
|
| So, what I would really like to see wrt Geronimo is an absolute  minimal
| server with add-on packages for things like a web container,  jms
| provider, etc. You want to host a web app? Throw in the Tomcat or  Jetty
| personality. Need JMS too, add ActiveMQ. Persistence? Simply  add a
| hibernate deployer. Mix and match so that it does what your app  needs.
|
| This is where Geronimo could shine and even take away a large chunk  of
| Tomcat; most people just want to deploy their web app and  optionally
| add some more services without having to understand a full  J2EE stack.
| Geronimo can fill that void extremely well I think.  (Simple Web
| Container ..  .. J2EE Monolith)
|
| Ok so just complaining doesn't work well for this project, so what I
| really would like to do is start figuring out how I can give Geronimo
| 'personalities' for popular combinations of technology. Like,
|
|  - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate
|  - Geronimo Kernel + Web Services
|  - Geronimo Kernel + JMX Enabled custom network service
|
| and then do some writing about it on the wiki. Make recipes for  people,
| or even complete packages that are downloadable.
|
| I really think this is how Geronimo can also get acceptance with a  much
| larger crowd.
|
|  S.
|
I'm not a committer, nor have I been more than an observer to what
Geronimo is doing and where it's going - primarily because everything
I've seen has placed it in the JBoss realm. I've used JBoss for quite a
while and am always amazed at the functionality it has ingrained in it
for which I just have no use. Most of my time spent upgrading is in
finding out how to turn things off that have changed.

This message caught my attention. For the first time, I've seen that I'm
not the only person who things this might be a good idea. I don't want
the world in a server - I just want to be able to add the pieces if/when
I need them to an existing server. This is something JBoss bypasses
entirely... you want to be able to add the pieces? voila - they're added
- - enjoy - whether you wanted them all 'built-in' or not.

I do think this will lead to greater adoption by new users (as well as
those others who want what I do - "the minimal server to do the job,
with expansion capabilities"), as well as greater 'user questions' ("Why
do I get this error?" "Because you don't have the Web Services package
installed/configured"). Questions can be documented all over the place
and users will still come to the mailing list and ask. That, however,
IMHO, is much better than those users already having a "monolith" and
sticking with it rather than move to a Geronimo "monolith" (monolith
used here not in a single application of monolithic proportions, but the
server with mandated functionality that, even when disabled, is still
taking up space). And I'm a firm believer that "it's on the Wiki" isn't
a substitute for good documentation included in the product - it's an
added method of documentation.

As for the pre-packaged versions - I think this would, indeed, be a boon
to Geronimo - - - as long as the individual 'services' were packaged for
some sort of 'drop-in deployment' into an existing Geronimo server as well.

My thoughts...

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCl2YbaCoPKRow/gARAnMNAJ9gxTlKzzp3pRHfd8i2GfQfvl8aIACgru71
6+OCdlthfHuBXTqUKB8JSR8=
=/uYw
-END PGP SIGNATURE-

Re: Module restructure

[Jeremy Boynes]

Aaron Mulder wrote:

On Fri, 27 May 2005, Geir Magnusson Jr. wrote:

so we have /trunk and /branches/stable and /branches/unstable, the  
former for release work, and the latter for really nutty stuff that  
people want to work on, and head is where mainline development  
continues?



	Who's responsible for merging changes between branches so that 
unstable gets all the changes that go into stable and trunk?  That seems 
likely to be painful.




We are. Stable is, well, stable, so there will be relatively few changes 
made directly there (mainly bugfixes). The biggest chore will be merging 
new features from (unstable,trunk) into stable as part of a new release. 
 For a major release, we may just say the unstable tree is now stable 
and  copy it over en-masse; for an incremental release we may need to merge.




Also, is the expectation that a given module only goes in one
place (so transactions, if high-quality, have source only in stable or
whatever), or is the same code in all 3 and you're just expected to know
where to work on it?  If the latter, that sounds unwieldy too.  If the
former, then we should just have 2 or 3 separate dirs with their own
trunk, branches, and tags, right?



Taking transaction as an example, let's say we consider it stable now. 
We would have that as a module in the stable tree and the build would 
output a specific version (say transaction-1.0.1). We would not need a 
copy in the unstable tree, the unstable assembly could just use that 
artifact.


Now, David decides to implement some new feature, he copies the stable 
branch into the unstable tree and starts implementing. At some point he 
wants to integrate that with the unstable assembly so updates it to use 
a SNAPSHOT version of his new module. When he's done and we all agree 
that this should be part of the stable build, we merge the changes back 
into the stable tree and re-release (say as transaction-1.2.0).  The 
merge should not be too painful because there would not have been a lot 
of changes in the stable tree.


If he's done, we can switch the unstable assembly back to using the new 
release build and delete the transaction module from the unstable tree; 
if he wants to keep working on it then we just leave it there.


The idea is to create a balance between users who want stable versions 
that they can use and the desire to innovate.


--
Jeremy

[jira] Closed: (GERONIMO-542) kernel.listGBeans returns mbeans that are not gbeans

[Dain Sundstrom (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-542?page=all ]
 
Dain Sundstrom closed GERONIMO-542:
---

 Resolution: Fixed
Fix Version: 1.0-M4

The GBean registry no longer consults JMX at all.

> kernel.listGBeans returns mbeans that are not gbeans
> 
>
>  Key: GERONIMO-542
>  URL: http://issues.apache.org/jira/browse/GERONIMO-542
>  Project: Geronimo
> Type: Bug
>   Components: kernel
> Versions: 1.0-M3
> Reporter: David Jencks
> Assignee: Dain Sundstrom
>  Fix For: 1.0-M4

>
> kernel.listGBeans returns all the mbeans, not just those that are from 
> gbeans.  Trying to access an attribute on one of these mbeans doesn't work, 
> you get a GBeanNotFound exception.
> For instance,
> JMImplementation:type=MBeanServerInterceptorConfigurator
> is in the set returned by querying for *:*.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Module restructure

[Stefan Arentz]

On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote:

Stefan brings up the question of whether we want to release sub- 
modules of Geronimo separately. I think this is a good idea and  
would propose the following restructure of the tree to move in this  
direction.


Let me just explain my motivation a bit, maybe that will also help  
for the plan.


In my original email I said something about not needing all the J2EE  
stuff. I exaggerated a bit of course, but most of the applications  
that I have been writing in the last couple of years are done mostly  
with a subset of the whole J2EE umbrella. Some apps were just some  
network service wrapped in (JMX) beans, a service exposed with Spring  
(Burlap, XML-RPC) other apps were simply a web app backed by a shared  
Spring context. I've never needed all the stuff in J2EE.


So far I've always done this on JBoss. Their MBean stuff works ok,  
but I wish it was easier to 'downsize' jboss to just a container with  
the stuff I need. That never really seemed to be their goal however.  
The complexity of their configuration files shows that.


So, what I would really like to see wrt Geronimo is an absolute  
minimal server with add-on packages for things like a web container,  
jms provider, etc. You want to host a web app? Throw in the Tomcat or  
Jetty personality. Need JMS too, add ActiveMQ. Persistence? Simply  
add a hibernate deployer. Mix and match so that it does what your app  
needs.


This is where Geronimo could shine and even take away a large chunk  
of Tomcat; most people just want to deploy their web app and  
optionally add some more services without having to understand a full  
J2EE stack. Geronimo can fill that void extremely well I think.  
(Simple Web Container ..  .. J2EE Monolith)


Ok so just complaining doesn't work well for this project, so what I  
really would like to do is start figuring out how I can give Geronimo  
'personalities' for popular combinations of technology. Like,


 - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate
 - Geronimo Kernel + Web Services
 - Geronimo Kernel + JMX Enabled custom network service

and then do some writing about it on the wiki. Make recipes for  
people, or even complete packages that are downloadable.


I really think this is how Geronimo can also get acceptance with a  
much larger crowd.


 S.

Re: Module restructure

[Aaron Mulder]

On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
> so we have /trunk and /branches/stable and /branches/unstable, the  
> former for release work, and the latter for really nutty stuff that  
> people want to work on, and head is where mainline development  
> continues?

Who's responsible for merging changes between branches so that 
unstable gets all the changes that go into stable and trunk?  That seems 
likely to be painful.

Also, is the expectation that a given module only goes in one
place (so transactions, if high-quality, have source only in stable or
whatever), or is the same code in all 3 and you're just expected to know
where to work on it?  If the latter, that sounds unwieldy too.  If the
former, then we should just have 2 or 3 separate dirs with their own
trunk, branches, and tags, right?

Aaron

Re: Integration of Geronimo modules (Tx / JCA) in Spring

[David Jencks]

I'm not entirely sure what you are asking.  Neither tranql nor anyone  
else has any magic xa elixir to wrap a non-xa database and make it have  
xa semantics.  However, you can deploy local-transaction only resource  
adapters in geronimo and have them participate in JTA transactions.   
Geronimo won't complain, but you wont get xa semantics if you have more  
than one transaction participant.  The standard tranql connector wraps  
a Driver implementation into a local-transaction only resource adapter.  
 If you have a database that really implements XADataSource, you can  
easily extend the tranql connector to a xa-transaction resource  
adapter.  The easiest way to do this is probably to copy the  
derby-connector and modify it.


Hope this helps
david jencks

On May 27, 2005, at 4:27 AM, Thierry Templier wrote:


Thanks a lot David! Your answer helps me a lot...
I'm working on the application to use TM and connector
modules without the entire Geronimo server.
I'm using Tranql to configure datasource. I see that
tranql connector doesn't support XA transactions
according to the ra.xml file... Is it possible to
create a datasource that supports XA transactions with
Tranql basing a non XA JDBC driver?
Thanks for your help.
Thierry


NPE -- see my explanation in my first reply, and ask
more specific
questions if what I wrote is incomprehensible :-)

TM initialization -- you should use the up to date
code :-)

Hmm. looking at this a bit I see we are using the
geronimo kernel
automatic collection management to register the
resource managers with
the tm.  What kind of environment are you targeting?
 Is this a static
environment intended to run a single application,
and restarted
whenever anything changes, or is it an environment
in which jca
adapters/resource managers will be deployed and
undeployed dynamically
while the container is running?  With the current
implementation you
will need to figure out a way to implement
ReferenceCollection so you
can add all the jca adapters to it... or if you
aren't interested in
recovery just implement an empty
ReferenceCollection.

ReferenceCollection resourceManagers = ??//don't
know what you want to
do here
TransactionLog transactionLog = new
UnrecoverableLog();
ExtendedTransactionManager transactionManager = new

TransactionManagerImpl(60, transactionLog,
resourceManagers);

TransactionContextManager transactionContextManager
= new
TransactionContextManager(transactionManager,
transactionManager);

If you are in spring, I'd think you could use spring
wiring to assemble
this -- we use gbeans to assemble it in geronimo.

Hope this helps
david jencks



Thierry


I think that would be a good idea.  We don't

really

have a generic xa
wrapper because you really want to expose the
XADatasource properties
as ManagedConnectionFactory properties.  This is
really easy to do,
however: see the derby xa wrapper in geronimo.
Since there aren't all
that many xa drivers, wrapping all of them may

not

be an infinitely
large task.  We do have a generic Driver wrapper,
and the j2ca
framework deals just fine with local transaction
adapters.  (you don't
get xa semantics, but you don't get exceptions
either).

Remember also that the pooling code itself is

inside

the
ConnectionManager implementation, thus in the
geronimo connector
module.

A couple other comments that might be a bit

advanced

for now...

One other hidden tidbit you might be interested

in

is, Jeremy figured
out how to make last-resource one phase commit
optimization actually
work with correct semantics if the last resource

is

a database and it
is used for the transaction log.  There's an
untested implementation of
this in o.a.g.connector.outbound.transactionlog.

I

think it could be
useful when you want to use jms and a non-xa
database.

Also, the "bridge" stuff for container managed
security is probably a
bad idea and should be replaced by just putting

more

login modules into
your original login configuration.

thanks!
david jencks




Here's part of the cvs connection string:


cvs.tranql.codehaus.org:/home/projects/tranql/scm


Generally each driver really should have a

driver

specific class to

indicate which sql exceptions it throws mean

that

a connection is

dead and should be discarded.  However, no one

has actually written

one of these yet :-)










Take a look at my blog:
http://templth.blogspot.com/










___



__
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace

de stockage pour vos

mails, photos et vidéos !
Créez votre Yahoo! Mail sur

http://fr.mail.yahoo.com








Take a look at my blog:
http://templth.blogspot.com/






___ 
__
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos  
mails, photos et vidéos !

Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

Re: Module restructure

[Alan D. Cabrera]

Geir Magnusson Jr. wrote, On 5/27/2005 12:27 PM:

BTW, however we resolve stable and unstable, I really do like the  
idea of a separate sandbox tree. That will make things very clear to  
people.


I like that idea as well.


Regards,
Alan

Re: Module restructure

[Geir Magnusson Jr.]

On May 27, 2005, at 12:48 PM, Geir Magnusson Jr. wrote:



On May 27, 2005, at 12:40 PM, Jeremy Boynes wrote:



Geir Magnusson Jr. wrote:


Clearly, we need something like this to get organized around the   
final push for certification and the 1.0 release, by why not  
just  branch for the stable, and head is unstable?





The names are just suggestions - "trunk", "head", "unstable",  
whatever.


The important thing is that you can easily checkout and build each  
tree on its own so we can't have both stable and unstable branches  
of modules (e.g. transaction) under trunk.





right - this is SVN, so the standard branching model actually  
doesn't work.  We'll need the branches outside of /trunk anyway


so we have /trunk and /branches/stable and /branches/unstable, the  
former for release work, and the latter for really nutty stuff that  
people want to work on, and head is where mainline development  
continues?




(What I'm saying is that I agree with you... we have no real choice  
because of how SVN does branches.  We clearly need to separate stable  
from unstable ongoing work)


geir


geir


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]





--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Module restructure

[Geir Magnusson Jr.]

On May 27, 2005, at 12:40 PM, Jeremy Boynes wrote:


Geir Magnusson Jr. wrote:

Clearly, we need something like this to get organized around the   
final push for certification and the 1.0 release, by why not just   
branch for the stable, and head is unstable?




The names are just suggestions - "trunk", "head", "unstable",  
whatever.


The important thing is that you can easily checkout and build each  
tree on its own so we can't have both stable and unstable branches  
of modules (e.g. transaction) under trunk.




right - this is SVN, so the standard branching model actually doesn't  
work.  We'll need the branches outside of /trunk anyway


so we have /trunk and /branches/stable and /branches/unstable, the  
former for release work, and the latter for really nutty stuff that  
people want to work on, and head is where mainline development  
continues?


geir


--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Module restructure

[Jeremy Boynes]

Geir Magnusson Jr. wrote:
Clearly, we need something like this to get organized around the  final 
push for certification and the 1.0 release, by why not just  branch for 
the stable, and head is unstable?




The names are just suggestions - "trunk", "head", "unstable", whatever.

The important thing is that you can easily checkout and build each tree 
on its own so we can't have both stable and unstable branches of modules 
(e.g. transaction) under trunk.


--
Jeremy

Re: Module restructure

[Geir Magnusson Jr.]

BTW, however we resolve stable and unstable, I really do like the  
idea of a separate sandbox tree. That will make things very clear to  
people.


geir

On May 27, 2005, at 12:18 PM, Geir Magnusson Jr. wrote:

Clearly, we need something like this to get organized around the  
final push for certification and the 1.0 release, by why not just  
branch for the stable, and head is unstable?


geir

On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote:


Stefan brings up the question of whether we want to release sub- 
modules of Geronimo separately. I think this is a good idea and  
would propose the following restructure of the tree to move in  
this direction.


Rather than "trunk" in the root, we have three separate trees:

stablesimilar to even-numbered versions of Linux, this tree
  would contain stable code intended for production use
  and operates with a focus on stability (i.e. well
  documented stable APIs, backward compatibility, no
  SNAPSHOT dependencies etc.)
  There will be multiple branches as needed.

unstable  similar to odd-numbered versions this is where new
  development is done and APIs etc. are much more
  likely to change. We may still do releases from here
  but they are quite likely to be incompatible; it may
  be all we package from here are nightlies.

sandbox   as now, a free-for-all area for trying out new ideas
  and experimenting with new technologies

Given the size of the codebase, we need to preserve the module  
structure that we have in the current trunk. However, even now  
some modules are more stable than others (e.g. the transaction and  
connector ones Thierry is looking to use) and I think are in a  
position where they can be versioned separately.


With the structure above in place, we can move modules into the  
stable or unstable trees as appropriate. For those that we  
consider stable (e.g. transaction) we can cut numbered releases  
that people can use standalone.


This will also speed the unstable build as we won't need to check  
SNAPSHOTs for everything all the time.


I would suggest we start on this as part of packaging for M4 and  
would be willing to co-ordinate.


--
Jeremy





--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]





--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: Module restructure

[Geir Magnusson Jr.]

Clearly, we need something like this to get organized around the  
final push for certification and the 1.0 release, by why not just  
branch for the stable, and head is unstable?


geir

On May 27, 2005, at 12:07 PM, Jeremy Boynes wrote:

Stefan brings up the question of whether we want to release sub- 
modules of Geronimo separately. I think this is a good idea and  
would propose the following restructure of the tree to move in this  
direction.


Rather than "trunk" in the root, we have three separate trees:

stablesimilar to even-numbered versions of Linux, this tree
  would contain stable code intended for production use
  and operates with a focus on stability (i.e. well
  documented stable APIs, backward compatibility, no
  SNAPSHOT dependencies etc.)
  There will be multiple branches as needed.

unstable  similar to odd-numbered versions this is where new
  development is done and APIs etc. are much more
  likely to change. We may still do releases from here
  but they are quite likely to be incompatible; it may
  be all we package from here are nightlies.

sandbox   as now, a free-for-all area for trying out new ideas
  and experimenting with new technologies

Given the size of the codebase, we need to preserve the module  
structure that we have in the current trunk. However, even now some  
modules are more stable than others (e.g. the transaction and  
connector ones Thierry is looking to use) and I think are in a  
position where they can be versioned separately.


With the structure above in place, we can move modules into the  
stable or unstable trees as appropriate. For those that we consider  
stable (e.g. transaction) we can cut numbered releases that people  
can use standalone.


This will also speed the unstable build as we won't need to check  
SNAPSHOTs for everything all the time.


I would suggest we start on this as part of packaging for M4 and  
would be willing to co-ordinate.


--
Jeremy




--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Module restructure

[Jeremy Boynes]

Stefan brings up the question of whether we want to release sub-modules 
of Geronimo separately. I think this is a good idea and would propose 
the following restructure of the tree to move in this direction.


Rather than "trunk" in the root, we have three separate trees:

stablesimilar to even-numbered versions of Linux, this tree
  would contain stable code intended for production use
  and operates with a focus on stability (i.e. well
  documented stable APIs, backward compatibility, no
  SNAPSHOT dependencies etc.)
  There will be multiple branches as needed.

unstable  similar to odd-numbered versions this is where new
  development is done and APIs etc. are much more
  likely to change. We may still do releases from here
  but they are quite likely to be incompatible; it may
  be all we package from here are nightlies.

sandbox   as now, a free-for-all area for trying out new ideas
  and experimenting with new technologies

Given the size of the codebase, we need to preserve the module structure 
that we have in the current trunk. However, even now some modules are 
more stable than others (e.g. the transaction and connector ones Thierry 
is looking to use) and I think are in a position where they can be 
versioned separately.


With the structure above in place, we can move modules into the stable 
or unstable trees as appropriate. For those that we consider stable 
(e.g. transaction) we can cut numbered releases that people can use 
standalone.


This will also speed the unstable build as we won't need to check 
SNAPSHOTs for everything all the time.


I would suggest we start on this as part of packaging for M4 and would 
be willing to co-ordinate.


--
Jeremy

Re: Logging in Tomcat

[Jeff Genender]

This is different then.

Jetty is using its own logging facility for its access log (requests), 
which is different than a log4j setup (which is used for INFO, DEBUG, 
and ERROR logging).


This same thing is capable through using the AccessLogValve, which 
exists in the j2ee-server-tomcat.xml plan.  If you are requiring that a 
request/access log be available on utilizing Tomcat (like Jetty) when 
enabling the Tomcat container, I would be happy to enable the valve in 
the plan.


Is this what you want?

Jeff

anita kulshreshtha wrote:

Jetty logs are directed to jetty__mm_dd.log using
JettyRequestLog gbean. When we decide to provide the
facility to replace Jetty with Tomcat, the Logger
gbean in tomcat can be used to replace JettyRequestLog
in j2ee-server-plan.xml.
--- Jeff Genender <[EMAIL PROTECTED]> wrote:


Lets get this out for discussion.  AFAIK, currently
Jetty does not come 
with these things automatically enabled (correct me
if I am wrong but 
did not notice a config for Jetty).  Deployer and
client do, but I do 
not see Jetty.


Therefore, I think we need to be consistent...if we
make this change, 
then I would assume Jetty need to would also.


So, whats the consensus on this?  Do we allow the
web containers to 
automaticlly log to a new file out-of-the-box, or
leave it in the 
geronimo.log?  And instead of Tomcat logging to a
tomcat.log, would it 
be more prudent to go to a generic web.log, so
matter which container 
you use, you know where it will go?


Thoughts?

Jeff

anita kulshreshtha wrote:


Jeff,
   Yes it does. By default the Digester should be
turned off and a comment out line to turn it on.


As an


application developer, I would like my tomcat


output


to be free of gbeans. I also think we should have


a


separate  tomcat-log4j.properties file just like
jetty, deployer and client. I will be glad to


submit


the code.

Thanks
Anita

--- Jeff Genender <[EMAIL PROTECTED]>


wrote:


Anita,

I believe a log4j configuration should allow you


to

do what you want. 
You should be able to control certain packages


(i.e.

Digester) to go to 
its own log file and you should be able to set the

level of debugging.

Jeff

anita kulshreshtha wrote:



I find it convenient to log only INFO level logs


from



tomcat to geronimo.log and DEBUG level logs to a
separate file. Digester produces too much output


and


it is hard to sift through the logs. 


Thanks
Anita
--- Jeff Genender <[EMAIL PROTECTED]>


wrote:



Anita,

Can you be more specific in your question?  Are


you



saying you want a Tomcat
log to go to another log file?

Jeff 


-Original Message-
From: anita kulshreshtha
[mailto:[EMAIL PROTECTED] 
Sent: Monday, May 23, 2005 3:07 AM

To: dev@geronimo.apache.org
Subject: Logging in Tomcat

Jeff and Jacek,
 Is there a specific reason/problem because of
which the digester logs
are not written to a separate log file.

TIA
Anita




__


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com 








__


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam


protection around 



http://mail.yahoo.com 





__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site

http://smallbusiness.yahoo.com/resources/


--
Jeff Genender
http://geronimo.apache.org







__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site

http://smallbusiness.yahoo.com/resources/


--
Jeff Genender
http://geronimo.apache.org

Re: Integration of Geronimo modules (Tx / JCA) in Spring

[Jeremy Boynes]

Thierry Templier wrote:

Thanks a lot David! Your answer helps me a lot...
I'm working on the application to use TM and connector
modules without the entire Geronimo server.
I'm using Tranql to configure datasource. I see that
tranql connector doesn't support XA transactions
according to the ra.xml file... Is it possible to
create a datasource that supports XA transactions with
Tranql basing a non XA JDBC driver?
Thanks for your help.
Thierry




The TranQL connector stuff is really a framework that handles the J2CA 
interface and which can form the base for wrapping any JDBC driver. The 
generic connector uses this framework to wrap JDBC using the Driver 
interface which is why is does not do XA.


There is an implementation at tranql for Oracle (vendors/oracle module) 
which supports XA with Oracle. You can also look at the derby-connector 
module in Geronimo for one that supports Derby.


If you have a different database it should be fairly easy to add a 
bridge for it.


--
Jeremy

Testing

[Stefan Arentz]

Ok cool, I did a build on

 OS X 10.4.1 / Java 1.4.2_07

took an hour (I was also watching a movie on my slow powerbook).

The build works, and the server starts.

So what is next? :-)

I have a bunch of Spring applications that I would like to deploy. I  
think I'm just going to see how that works and give feedback.


 S.

Mail, was: Who wants an M4 release?

[Jeremy Boynes]

Thilina Gunarathne wrote:

Hi,
I can also give a hand on testing. Specially on the Spec side( Java mail, 
activation).
At the moment i'm using the Geronimo spec Java mail & Activation 
implementations to give the Attachment support for the Axis 2 project.
At the moment I found out that Java Mail implementation has bug when it 
comes to creating mime message.




Please open a Jira issue for this and assign it to me.


I would also like to contribute to Geronimo as time permits.



Testing things out and logging bugs is a great way to get started.
--
Jeremy

Re: Logging in Tomcat

[anita kulshreshtha]

Jetty logs are directed to jetty__mm_dd.log using
JettyRequestLog gbean. When we decide to provide the
facility to replace Jetty with Tomcat, the Logger
gbean in tomcat can be used to replace JettyRequestLog
in j2ee-server-plan.xml.
--- Jeff Genender <[EMAIL PROTECTED]> wrote:
> Lets get this out for discussion.  AFAIK, currently
> Jetty does not come 
> with these things automatically enabled (correct me
> if I am wrong but 
> did not notice a config for Jetty).  Deployer and
> client do, but I do 
> not see Jetty.
> 
> Therefore, I think we need to be consistent...if we
> make this change, 
> then I would assume Jetty need to would also.
> 
> So, whats the consensus on this?  Do we allow the
> web containers to 
> automaticlly log to a new file out-of-the-box, or
> leave it in the 
> geronimo.log?  And instead of Tomcat logging to a
> tomcat.log, would it 
> be more prudent to go to a generic web.log, so
> matter which container 
> you use, you know where it will go?
> 
> Thoughts?
> 
> Jeff
> 
> anita kulshreshtha wrote:
> > Jeff,
> > Yes it does. By default the Digester should be
> > turned off and a comment out line to turn it on.
> As an
> > application developer, I would like my tomcat
> output
> > to be free of gbeans. I also think we should have
> a
> > separate  tomcat-log4j.properties file just like
> > jetty, deployer and client. I will be glad to
> submit
> > the code.
> > 
> > Thanks
> > Anita
> > 
> > --- Jeff Genender <[EMAIL PROTECTED]>
> wrote:
> > 
> >>Anita,
> >>
> >>I believe a log4j configuration should allow you
> to
> >>do what you want. 
> >>You should be able to control certain packages
> (i.e.
> >>Digester) to go to 
> >>its own log file and you should be able to set the
> >>level of debugging.
> >>
> >>Jeff
> >>
> >>anita kulshreshtha wrote:
> >>
> >>>I find it convenient to log only INFO level logs
> >>
> >>from
> >>
> >>>tomcat to geronimo.log and DEBUG level logs to a
> >>>separate file. Digester produces too much output
> >>
> >>and
> >>
> >>>it is hard to sift through the logs. 
> >>>
> >>>Thanks
> >>>Anita
> >>>--- Jeff Genender <[EMAIL PROTECTED]>
> >>
> >>wrote:
> >>
> Anita,
> 
> Can you be more specific in your question?  Are
> >>
> >>you
> >>
> saying you want a Tomcat
> log to go to another log file?
> 
> Jeff 
> 
> -Original Message-
> From: anita kulshreshtha
> [mailto:[EMAIL PROTECTED] 
> Sent: Monday, May 23, 2005 3:07 AM
> To: dev@geronimo.apache.org
> Subject: Logging in Tomcat
> 
> Jeff and Jacek,
>    Is there a specific reason/problem because of
> which the digester logs
> are not written to a separate log file.
> 
> TIA
> Anita
> 
>
__
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com 
> 
> 
> 
> >>>
> >>>
>
>>>__
> >>>Do You Yahoo!?
> >>>Tired of spam?  Yahoo! Mail has the best spam
> >>
> >>protection around 
> >>
> >>>http://mail.yahoo.com 
> >>
> > 
> > 
> > 
> > __ 
> > Do you Yahoo!? 
> > Yahoo! Small Business - Try our new Resources site
> > http://smallbusiness.yahoo.com/resources/
> 
> -- 
> Jeff Genender
> http://geronimo.apache.org
> 
> 



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[jira] Created: (GERONIMO-656) Invalid Login in deployer should not print the stack trace

[anita kulshreshtha (JIRA)]

Invalid Login in deployer should not print the stack trace
--

 Key: GERONIMO-656
 URL: http://issues.apache.org/jira/browse/GERONIMO-656
 Project: Geronimo
Type: Bug
Versions: 1.0-M4
 Environment: All environments
Reporter: anita kulshreshtha
Priority: Trivial


The deployer should not print out the following stack trace for invalid logins 
caused by null/bad  Username/Password. Just an invalid login message should be 
enough.

Username:
Password:
Error: Unable to connect to server

org.apache.geronimo.deployment.plugin.factories.AuthenticationFailedException: 
Invalid login.
at 
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManager(DeploymentFactoryI
mpl.java:87)
at 
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManag
er.java:109)
at 
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:182)
at 
org.apache.geronimo.deployment.cli.ServerConnection.doAuthPromptAndRetry(ServerConnection.java:238)
at 
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:185)
at 
org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:147)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:111)
at 
org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:254)
Caused by: java.lang.SecurityException: Invalid login
at 
org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:61)
at javax.management.remote.rmi.RMIServerImpl.newClient(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown 
Source)
at java.lang.Thread.run(Unknown Source)
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source)
at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown 
Source)
at javax.management.remote.rmi.RMIConnector.getConnection(Unknown 
Source)
at javax.management.remote.rmi.RMIConnector.connect(Unknown Source)
at javax.management.remote.JMXConnectorFactory.connect(Unknown Source)
at 
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManager(DeploymentFactoryI
mpl.java:81)
... 7 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-655) Logging in Tomcat

[Jeff Genender (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-655?page=all ]

Jeff Genender reassigned GERONIMO-655:
--

Assign To: Jeff Genender

> Logging in Tomcat
> -
>
>  Key: GERONIMO-655
>  URL: http://issues.apache.org/jira/browse/GERONIMO-655
>  Project: Geronimo
> Type: New Feature
>   Components: Tomcat
> Versions: 1.0-M4
>  Environment: All Environments
> Reporter: anita kulshreshtha
> Assignee: Jeff Genender
> Priority: Minor
>  Attachments: tomcatlogging.zip, tomcatlogging.zip
>
> Currently Tomcat logs are interspersed with gbeans. A separate logging 
> configuration file for Tomcat will allow more control over Tomcat output. The 
> attached patches will allow tomcat-log4j.properties to be used as the 
> configuration file. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Who wants an M4 release?

[Thilina Gunarathne]

Hi,
I can also give a hand on testing. Specially on the Spec side( Java mail, activation).
At the moment i'm using the Geronimo spec Java mail & Activation
implementations to give the Attachment support for the Axis 2 project.
At the moment I  found out that Java Mail implementation has bug when it comes to creating mime message.

I would also like to contribute to Geronimo as time permits.

regards,

~ ThilinaOn 5/27/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
The unstable release or the source code is the closest to M4...use thatfor now.Jeffsanjaya gayan wrote:> Is the M4 not available for download?>> sanjaya.>> - Original Message -
> From: "Thushantha De Alwis" <[EMAIL PROTECTED]>> To: > Sent: Friday, May 27, 2005 2:38 PM
> Subject: Re: Who wants an M4 release?>HiI'm new to Geronimo. But these days I'm going>> through M3. But I will try>>>to do some work. Please let me know what I suppoed
>> to do.>>>Thushantha De Alwis>>>David Blevins wrote:>>>On Wed, May 25, 2005 at 11:31:40PM -0700, David>> Blevins wrote:
>>...now that I have your attention :)   More>> importantly, who is willing>>to volunteer to test and give a "works" or>> "doesn't work" report?
>>Any volunteers?  Consider this the signup sheet.>We have three so far.  Gonna need at least three>
> more people (a dozen>would be great) or we'll end up with a broken>> release like M3.  We>should be able to handle pretty much any J2EE app>
> at this point.>Deploy an app, give a thumbs up or thumbs down.>> Easy.>Any more volunteers?  You don't have to be a>> committer.>
>>>In that case, count me in.>>-->>>Panagiotis Astithas>>>EBS, Electronic Business Systems Ltd.>>>18 Evgenidou Street, 115 25, Athens GREECE
>>>Phone: +30 210 674 7631>>>Fax: +30 210 674 7601>>>http://www.ebs.gr>
>> ___> How much free photo storage do you get? Store your holiday> snaps for FREE with Yahoo! Photos 
http://uk.photos.yahoo.com-- Lanka Software Foundation --"May the SourcE be with u" 

Re: Logging in Tomcat

[Jeff Genender]

Lets get this out for discussion.  AFAIK, currently Jetty does not come 
with these things automatically enabled (correct me if I am wrong but 
did not notice a config for Jetty).  Deployer and client do, but I do 
not see Jetty.


Therefore, I think we need to be consistent...if we make this change, 
then I would assume Jetty need to would also.


So, whats the consensus on this?  Do we allow the web containers to 
automaticlly log to a new file out-of-the-box, or leave it in the 
geronimo.log?  And instead of Tomcat logging to a tomcat.log, would it 
be more prudent to go to a generic web.log, so matter which container 
you use, you know where it will go?


Thoughts?

Jeff

anita kulshreshtha wrote:

Jeff,
Yes it does. By default the Digester should be
turned off and a comment out line to turn it on. As an
application developer, I would like my tomcat output
to be free of gbeans. I also think we should have a
separate  tomcat-log4j.properties file just like
jetty, deployer and client. I will be glad to submit
the code.

Thanks
Anita

--- Jeff Genender <[EMAIL PROTECTED]> wrote:


Anita,

I believe a log4j configuration should allow you to
do what you want. 
You should be able to control certain packages (i.e.
Digester) to go to 
its own log file and you should be able to set the

level of debugging.

Jeff

anita kulshreshtha wrote:


I find it convenient to log only INFO level logs


from


tomcat to geronimo.log and DEBUG level logs to a
separate file. Digester produces too much output


and

it is hard to sift through the logs. 


Thanks
Anita
--- Jeff Genender <[EMAIL PROTECTED]>


wrote:


Anita,

Can you be more specific in your question?  Are


you


saying you want a Tomcat
log to go to another log file?

Jeff 


-Original Message-
From: anita kulshreshtha
[mailto:[EMAIL PROTECTED] 
Sent: Monday, May 23, 2005 3:07 AM

To: dev@geronimo.apache.org
Subject: Logging in Tomcat

Jeff and Jacek,
  Is there a specific reason/problem because of
which the digester logs
are not written to a separate log file.

TIA
Anita

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com 







__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam


protection around 

http://mail.yahoo.com 






__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site

http://smallbusiness.yahoo.com/resources/


--
Jeff Genender
http://geronimo.apache.org

[jira] Created: (GERONIMO-655) Logging in Tomcat

[anita kulshreshtha (JIRA)]

Logging in Tomcat
-

 Key: GERONIMO-655
 URL: http://issues.apache.org/jira/browse/GERONIMO-655
 Project: Geronimo
Type: New Feature
  Components: Tomcat  
Versions: 1.0-M4
 Environment: All Environments
Reporter: anita kulshreshtha
Priority: Minor


Currently Tomcat logs are interspersed with gbeans. A separate logging 
configuration file for Tomcat will allow more control over Tomcat output. The 
attached patches will allow tomcat-log4j.properties to be used as the 
configuration file. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Integration of Geronimo modules (Tx / JCA) in Spring

[Thierry Templier]

Thanks a lot David! Your answer helps me a lot...
I'm working on the application to use TM and connector
modules without the entire Geronimo server.
I'm using Tranql to configure datasource. I see that
tranql connector doesn't support XA transactions
according to the ra.xml file... Is it possible to
create a datasource that supports XA transactions with
Tranql basing a non XA JDBC driver?
Thanks for your help.
Thierry

> NPE -- see my explanation in my first reply, and ask
> more specific  
> questions if what I wrote is incomprehensible :-)
> 
> TM initialization -- you should use the up to date
> code :-)
> 
> Hmm. looking at this a bit I see we are using the
> geronimo kernel  
> automatic collection management to register the
> resource managers with  
> the tm.  What kind of environment are you targeting?
>  Is this a static  
> environment intended to run a single application,
> and restarted  
> whenever anything changes, or is it an environment
> in which jca  
> adapters/resource managers will be deployed and
> undeployed dynamically  
> while the container is running?  With the current
> implementation you  
> will need to figure out a way to implement
> ReferenceCollection so you  
> can add all the jca adapters to it... or if you
> aren't interested in  
> recovery just implement an empty
> ReferenceCollection.
> 
> ReferenceCollection resourceManagers = ??//don't
> know what you want to  
> do here
> TransactionLog transactionLog = new
> UnrecoverableLog();
> ExtendedTransactionManager transactionManager = new 
> 
> TransactionManagerImpl(60, transactionLog,
> resourceManagers);
> 
> TransactionContextManager transactionContextManager
> = new  
> TransactionContextManager(transactionManager,
> transactionManager);
> 
> If you are in spring, I'd think you could use spring
> wiring to assemble  
> this -- we use gbeans to assemble it in geronimo.
> 
> Hope this helps
> david jencks
> 
> 
> > Thierry
> >
> >> I think that would be a good idea.  We don't
> really
> >> have a generic xa
> >> wrapper because you really want to expose the
> >> XADatasource properties
> >> as ManagedConnectionFactory properties.  This is
> >> really easy to do,
> >> however: see the derby xa wrapper in geronimo.
> >> Since there aren't all
> >> that many xa drivers, wrapping all of them may
> not
> >> be an infinitely
> >> large task.  We do have a generic Driver wrapper,
> >> and the j2ca
> >> framework deals just fine with local transaction
> >> adapters.  (you don't
> >> get xa semantics, but you don't get exceptions
> >> either).
> >>
> >> Remember also that the pooling code itself is
> inside
> >> the
> >> ConnectionManager implementation, thus in the
> >> geronimo connector
> >> module.
> >>
> >> A couple other comments that might be a bit
> advanced
> >> for now...
> >>
> >> One other hidden tidbit you might be interested
> in
> >> is, Jeremy figured
> >> out how to make last-resource one phase commit
> >> optimization actually
> >> work with correct semantics if the last resource
> is
> >> a database and it
> >> is used for the transaction log.  There's an
> >> untested implementation of
> >> this in o.a.g.connector.outbound.transactionlog. 
> I
> >> think it could be
> >> useful when you want to use jms and a non-xa
> >> database.
> >>
> >> Also, the "bridge" stuff for container managed
> >> security is probably a
> >> bad idea and should be replaced by just putting
> more
> >> login modules into
> >> your original login configuration.
> >>
> >> thanks!
> >> david jencks
> >>
> >>>
>  Here's part of the cvs connection string:
> 
> cvs.tranql.codehaus.org:/home/projects/tranql/scm
> 
>  Generally each driver really should have a
> driver
> >> specific class to
>  indicate which sql exceptions it throws mean
> that
> >> a connection is
>  dead and should be discarded.  However, no one
> >> has actually written
>  one of these yet :-)
> 
> >>>
> >>
> >>
> >
> >
> >
> > Take a look at my blog:
> > http://templth.blogspot.com/
> >
> >
> > 
> >
> > 
> > 
> >
>
___
> 
> > __
> > Découvrez le nouveau Yahoo! Mail : 1 Go d'espace
> de stockage pour vos  
> > mails, photos et vidéos !
> > Créez votre Yahoo! Mail sur
> http://fr.mail.yahoo.com
> >
> 
> 


Take a look at my blog:
http://templth.blogspot.com/






_ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, 
photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

Re: Who wants an M4 release?

[Jeff Genender]

The unstable release or the source code is the closest to M4...use that 
for now.


Jeff

sanjaya gayan wrote:

Is the M4 not available for download?

sanjaya.

- Original Message -
From: "Thushantha De Alwis" <[EMAIL PROTECTED]>
To: 
Sent: Friday, May 27, 2005 2:38 PM
Subject: Re: Who wants an M4 release?




Hi

I'm new to Geronimo. But these days I'm going


through M3. But I will try


to do some work. Please let me know what I suppoed


to do.


Thushantha De Alwis



David Blevins wrote:


On Wed, May 25, 2005 at 11:31:40PM -0700, David


Blevins wrote:


...now that I have your attention :)   More


importantly, who is willing


to volunteer to test and give a "works" or


"doesn't work" report?


Any volunteers?  Consider this the signup sheet.




We have three so far.  Gonna need at least three


more people (a dozen


would be great) or we'll end up with a broken


release like M3.  We


should be able to handle pretty much any J2EE app


at this point.

Deploy an app, give a thumbs up or thumbs down. 


Easy.


Any more volunteers?  You don't have to be a


committer.


In that case, count me in.

--
Panagiotis Astithas
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601
http://www.ebs.gr










___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

[jira] Updated: (GERONIMO-655) Logging in Tomcat

[anita kulshreshtha (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-655?page=all ]

anita kulshreshtha updated GERONIMO-655:


Attachment: tomcatlogging.zip

> Logging in Tomcat
> -
>
>  Key: GERONIMO-655
>  URL: http://issues.apache.org/jira/browse/GERONIMO-655
>  Project: Geronimo
> Type: New Feature
>   Components: Tomcat
> Versions: 1.0-M4
>  Environment: All Environments
> Reporter: anita kulshreshtha
> Priority: Minor
>  Attachments: tomcatlogging.zip, tomcatlogging.zip
>
> Currently Tomcat logs are interspersed with gbeans. A separate logging 
> configuration file for Tomcat will allow more control over Tomcat output. The 
> attached patches will allow tomcat-log4j.properties to be used as the 
> configuration file. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-655) Logging in Tomcat

[anita kulshreshtha (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-655?page=all ]

anita kulshreshtha updated GERONIMO-655:


Attachment: tomcatlogging.zip

Oops.., Here is the permission.

> Logging in Tomcat
> -
>
>  Key: GERONIMO-655
>  URL: http://issues.apache.org/jira/browse/GERONIMO-655
>  Project: Geronimo
> Type: New Feature
>   Components: Tomcat
> Versions: 1.0-M4
>  Environment: All Environments
> Reporter: anita kulshreshtha
> Priority: Minor
>  Attachments: tomcatlogging.zip, tomcatlogging.zip
>
> Currently Tomcat logs are interspersed with gbeans. A separate logging 
> configuration file for Tomcat will allow more control over Tomcat output. The 
> attached patches will allow tomcat-log4j.properties to be used as the 
> configuration file. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Who wants an M4 release?

[Mujibur Rahman Shaik]

Hi,

I am intrested in doing some contribution to geronimo.
Best way to start is to test. Iam not an expert of
j2ee, but will do my best. Pls let me know the
expected .

Thanks
Rahman

--- Thushantha De Alwis <[EMAIL PROTECTED]> wrote:
> Hi
> 
> I'm new to Geronimo. But these days I'm going
> through M3. But I will try
> to do some work. Please let me know what I suppoed
> to do.
> 
> Thushantha De Alwis
> 
> > David Blevins wrote:
> >> On Wed, May 25, 2005 at 11:31:40PM -0700, David
> Blevins wrote:
> >>
> >>>...now that I have your attention :)   More
> importantly, who is willing
> >>> to volunteer to test and give a "works" or
> "doesn't work" report?
> >>>
> >>>Any volunteers?  Consider this the signup sheet.
> >>>
> >>
> >>
> >> We have three so far.  Gonna need at least three
> more people (a dozen
> >> would be great) or we'll end up with a broken
> release like M3.  We
> >> should be able to handle pretty much any J2EE app
> at this point.
> >>
> >> Deploy an app, give a thumbs up or thumbs down. 
> Easy.
> >>
> >> Any more volunteers?  You don't have to be a
> committer.
> >
> > In that case, count me in.
> >
> > --
> > Panagiotis Astithas
> > EBS, Electronic Business Systems Ltd.
> > 18 Evgenidou Street, 115 25, Athens GREECE
> > Phone: +30 210 674 7631
> > Fax: +30 210 674 7601
> > http://www.ebs.gr
> >
> >
> 
> 



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

Re: Who wants an M4 release?

[sanjaya gayan]

Is the M4 not available for download?

sanjaya.

- Original Message -
From: "Thushantha De Alwis" <[EMAIL PROTECTED]>
To: 
Sent: Friday, May 27, 2005 2:38 PM
Subject: Re: Who wants an M4 release?


> Hi
>
> I'm new to Geronimo. But these days I'm going
through M3. But I will try
> to do some work. Please let me know what I suppoed
to do.
>
> Thushantha De Alwis
>
> > David Blevins wrote:
> >> On Wed, May 25, 2005 at 11:31:40PM -0700, David
Blevins wrote:
> >>
> >>>...now that I have your attention :)   More
importantly, who is willing
> >>> to volunteer to test and give a "works" or
"doesn't work" report?
> >>>
> >>>Any volunteers?  Consider this the signup sheet.
> >>>
> >>
> >>
> >> We have three so far.  Gonna need at least three
more people (a dozen
> >> would be great) or we'll end up with a broken
release like M3.  We
> >> should be able to handle pretty much any J2EE app
at this point.
> >>
> >> Deploy an app, give a thumbs up or thumbs down. 
Easy.
> >>
> >> Any more volunteers?  You don't have to be a
committer.
> >
> > In that case, count me in.
> >
> > --
> > Panagiotis Astithas
> > EBS, Electronic Business Systems Ltd.
> > 18 Evgenidou Street, 115 25, Athens GREECE
> > Phone: +30 210 674 7631
> > Fax: +30 210 674 7601
> > http://www.ebs.gr
> >
> >
>
>




___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: Who wants an M4 release?

[Thushantha De Alwis]

Hi

I'm new to Geronimo. But these days I'm going through M3. But I will try
to do some work. Please let me know what I suppoed to do.

Thushantha De Alwis

> David Blevins wrote:
>> On Wed, May 25, 2005 at 11:31:40PM -0700, David Blevins wrote:
>>
>>>...now that I have your attention :)   More importantly, who is willing
>>> to volunteer to test and give a "works" or "doesn't work" report?
>>>
>>>Any volunteers?  Consider this the signup sheet.
>>>
>>
>>
>> We have three so far.  Gonna need at least three more people (a dozen
>> would be great) or we'll end up with a broken release like M3.  We
>> should be able to handle pretty much any J2EE app at this point.
>>
>> Deploy an app, give a thumbs up or thumbs down.  Easy.
>>
>> Any more volunteers?  You don't have to be a committer.
>
> In that case, count me in.
>
> --
> Panagiotis Astithas
> EBS, Electronic Business Systems Ltd.
> 18 Evgenidou Street, 115 25, Athens GREECE
> Phone: +30 210 674 7631
> Fax: +30 210 674 7601
> http://www.ebs.gr
>
>

Re: Who wants an M4 release?

[Panagiotis Astithas]

David Blevins wrote:

On Wed, May 25, 2005 at 11:31:40PM -0700, David Blevins wrote:


...now that I have your attention :)   More importantly, who is willing to volunteer to test and 
give a "works" or "doesn't work" report?

Any volunteers?  Consider this the signup sheet.




We have three so far.  Gonna need at least three more people (a dozen would be 
great) or we'll end up with a broken release like M3.  We should be able to 
handle pretty much any J2EE app at this point.

Deploy an app, give a thumbs up or thumbs down.  Easy.

Any more volunteers?  You don't have to be a committer.


In that case, count me in.

--
Panagiotis Astithas
EBS, Electronic Business Systems Ltd.
18 Evgenidou Street, 115 25, Athens GREECE
Phone: +30 210 674 7631
Fax: +30 210 674 7601
http://www.ebs.gr