date:20060105


David Jencks wrote:

It is possible (I think) to do what you want, but I do not recommend  
it.  I would prefer that you use external plans, and write 2 new  
modules inside configs, to deploy your sample to jetty and to  
tomcat.  Take the geronimo-web.xml out of the app and put it in src/ 
plan/plan.xml.


However, if you wish to defy me :-) you can use the generic schema  
http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo- 
web-1.0.xsd) with sections in a container-config for the jetty and  
tomcat specific parts.  These would use the namespace/schemas e.g.  
http://geronimo.apache.org/xml/ns/web/jetty/config-1.0 (geronimo- 
jetty-config-1.0.xsd).



I really feel that it is valuable for WADI-enabled apps to port easily 
between Jetty and Tomcat (and hopefully other)-based containers.


I would be much happier with one proprietary dd or plan, than two. So, I 
am still on course for somehow merging the two.


As to whether this dd/plan lives in or outside the deployable - I'm not 
to worried. I imagine that WADI will ship its demo webapp with the dd 
inside for self-containedness' sake, but I have no religious views on 
the subject.


A problem with this approach might be that you are including a gbean  
in the tomcat config that is not needed in the jetty config.  I don't  
understand why this would be there anyway, but I don't think you can  
have gbeans in the container-config part.


Is it possible to adjust the jetty and tomcat clustering configs to  
be roughly the same and include the element in geronimo-web-1.0.xsd?


I think some form of adjustment here will be the sensible way forward.

Thanks for the pointers,


Jules



hope this helps
david jencks

On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:


Aaron, David, or anyone in the know :-)

Maybe you can help me with this:

I have a WADI demo webapp.

To get it running with Jetty, I need a WEB-INF/geronimo-web.xml  that 
looks like this:


http://geronimo.apache.org/xml/ns/j2ee/web/ 
jetty-1.0" configId="wadi">


   /wadi
   false
   org.codehaus.wadi.jetty5.JettyManagermanager>




To get it running with Tomcat, I have to have a geronimo-web.xml  
that looks like this:


http://geronimo.apache.org/xml/ns/j2ee/web/ 
tomcat-1.0" configId="wadi">


   /wadi
   false
   WADI

   class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>





What I would like, is a single geronimo-web.xml that contains both  
Jetty and TC configs, merged.


Do you know if this is possible, if so, would you mind pointing me  
in the right direction ?


Much appreciated,


Jules



Aaron Mulder wrote:


David J,

I thought when you added the separate Tomcat and Jetty namespaces,  you
were going to remove the container-config section from the generic
geronimo-web.xml, but it seems that it's still there.  Jeff thinks
maybe it's for something like the console, where we want it to  work in
both Tomcat and Jetty yet we might still require some
container-specific extensions (makes sense to me).

If we're going to keep the generic geronimo-web.xml and keep the
container-config section in it, can we drop the container-specific
namespaces?  I think you favored the namespaces because if you use a
container-specific namespace then any container-specific settings
could be validated in XML, but I think that's pretty useless if it
only applies if you're willing to force your app to only deploy in  one
container or the other.  (That is to say, if you want your web app to
run in either Tomcat or Jetty -- which is probably the normal case,
then you can't use a container-specific namespace so it doesn't  matter
what the benefits of container-specific namespaces are.)

The only way I can see the container-specific namespaces being
beneficial is if the container-config became an "any" and then we
namespaced the content that went within it -- so the overall file
always used the generic namespace but then you used a
container-specific one for the contents of the container-config
element only.

Am I missing something?

Thanks,
   Aaron




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Re: geronimo-web.xml, container-config, container-specific namespaces


Aaron Mulder wrote:


Well...  is it possible to make this not specific to WADI?  Perhaps
make it a generic "clustering manager" tag, and is "just so happens"
that the only classes we let you configure so far are the WADI ones? 
Ideally, we'd put some generic interface in the Geronimo space, and

then the WADI ones would implement or extend that, so if we ever
wanted to integrate other clustering options we'd leave that door
open.

Thanks,
   Aaron
 

This is a good idea but - The choice of WADI class passed in is 
container specific. For Jetty you use a WADI class that implements the 
Jetty Session Manager interface, for TC likewise. Jetty and TC Session 
Managers do not implement a common interface. We could look at defining 
a third interface - e.g. GeronimoWebSessionManager - but I see no gain 
in that, since by implementing it, you do not guarantee that your 
session manager will work in Jetty or TC. It just adds yet more layers 
of abstraction.


WADI will soon be in the incubator and an integral part of Geronimo. If 
we want to abstract anything between web session managers, I think it 
should be done in WADI, as it is (Jetty and TC managers both wrap and 
translate/delegate calls to a single WADI Manager interface).


How does that sound ?

Jules


On 1/4/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
 


Hi,

Actually...this is quite simple...

Use the generic web.  Have a new tag...call it , or whatever.

Each of the container's builders can then have a flag set that is passed
into its web context.  The web context can then set its own
implementation...i.e. for Jetty, it then can create and apply its own
org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and
apply its org.codehaus.wadi.tomcat55.TomcatManager.  No need for GBeans
if WADI is to become a first class citizen.  The Tomcat GBean is purely
for the ability to declaratively swap out managers.

Thus, this will allow for a single ability to set up a generic tag that
both containers can understand how to act upon.

Jeff

David Jencks wrote:
   


It is possible (I think) to do what you want, but I do not recommend
it.  I would prefer that you use external plans, and write 2 new modules
inside configs, to deploy your sample to jetty and to tomcat.  Take the
geronimo-web.xml out of the app and put it in src/plan/plan.xml.

However, if you wish to defy me :-) you can use the generic schema
http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo-web-1.0.xsd)
with sections in a container-config for the jetty and tomcat specific
parts.  These would use the namespace/schemas e.g.
http://geronimo.apache.org/xml/ns/web/jetty/config-1.0
(geronimo-jetty-config-1.0.xsd).

A problem with this approach might be that you are including a gbean in
the tomcat config that is not needed in the jetty config.  I don't
understand why this would be there anyway, but I don't think you can
have gbeans in the container-config part.

Is it possible to adjust the jetty and tomcat clustering configs to be
roughly the same and include the element in geronimo-web-1.0.xsd?

hope this helps
david jencks

On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:

 


Aaron, David, or anyone in the know :-)

Maybe you can help me with this:

I have a WADI demo webapp.

To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that
looks like this:

http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0";
configId="wadi">

  /wadi
  false

org.codehaus.wadi.jetty5.JettyManager



To get it running with Tomcat, I have to have a geronimo-web.xml that
looks like this:

http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";
configId="wadi">

  /wadi
  false
  WADI

  




What I would like, is a single geronimo-web.xml that contains both
Jetty and TC configs, merged.

Do you know if this is possible, if so, would you mind pointing me in
the right direction ?

Much appreciated,


Jules



Aaron Mulder wrote:

   


David J,

I thought when you added the separate Tomcat and Jetty namespaces, you
were going to remove the container-config section from the generic
geronimo-web.xml, but it seems that it's still there.  Jeff thinks
maybe it's for something like the console, where we want it to work in
both Tomcat and Jetty yet we might still require some
container-specific extensions (makes sense to me).

If we're going to keep the generic geronimo-web.xml and keep the
container-config section in it, can we drop the container-specific
namespaces?  I think you favored the namespaces because if you use a
container-specific namespace then any container-specific settings
could be validated in XML, but I think that's pretty useless if it
only applies if you're willing to force your app to only deploy in one
container or the other.  (That is to say, if you want your web app to
run in either Tomcat or Jetty -- which is probably the normal case,
then you can't use a container-specific namespace so it doesn't matter
what the benefits of container-specific namespaces are.)

Th

Re: [wadi-dev] Re: geronimo-web.xml, container-config, container-specific namespaces


After further thought...

I imagine it going like this:

container checks for the WEB-INF/web.xml/ tag.

If it exists, container looks at the e.g. 
geronimo-web.xml/ tag.


The value of this tag could be either an enum (e.g. {WADI,...}), a 
classname or the name of some existing component (GBean) (any other ideas?)


I don't like the enum based solution - it just leads to more code and 
documentation to ties the key to its value.


The classname version assumes a void ctor and a separate instance of the 
class for each webapp (I think there may be a case for being able to 
share a session manager across web contexts - but the jury is still out).


The GBean version delegates full control over the construction and 
configuration to Geronimo whilst allowing the possibility of either 
shared or individual session manager instances. I think that I would 
prefer this route.


Ultimately, I might also like to see an e.g.  tag 
in the geronimo-web.xml as well, allowing the selection of session 
managers in a non-distributable mode. WADI willl run in this mode, as do 
other Tomcat session managers that might be selected via this mechanism 
(I'm not sure whether the standalone mechanism for session manager 
selection has been exposed for TC or not).


Thoughts ?


Jules


Jules Gosnell wrote:


Aaron Mulder wrote:


Well...  is it possible to make this not specific to WADI?  Perhaps
make it a generic "clustering manager" tag, and is "just so happens"
that the only classes we let you configure so far are the WADI ones? 
Ideally, we'd put some generic interface in the Geronimo space, and

then the WADI ones would implement or extend that, so if we ever
wanted to integrate other clustering options we'd leave that door
open.

Thanks,
   Aaron
 

This is a good idea but - The choice of WADI class passed in is 
container specific. For Jetty you use a WADI class that implements the 
Jetty Session Manager interface, for TC likewise. Jetty and TC Session 
Managers do not implement a common interface. We could look at 
defining a third interface - e.g. GeronimoWebSessionManager - but I 
see no gain in that, since by implementing it, you do not guarantee 
that your session manager will work in Jetty or TC. It just adds yet 
more layers of abstraction.


WADI will soon be in the incubator and an integral part of Geronimo. 
If we want to abstract anything between web session managers, I think 
it should be done in WADI, as it is (Jetty and TC managers both wrap 
and translate/delegate calls to a single WADI Manager interface).


How does that sound ?

Jules


On 1/4/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
 


Hi,

Actually...this is quite simple...

Use the generic web.  Have a new tag...call it , or 
whatever.


Each of the container's builders can then have a flag set that is 
passed

into its web context.  The web context can then set its own
implementation...i.e. for Jetty, it then can create and apply its own
org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and
apply its org.codehaus.wadi.tomcat55.TomcatManager.  No need for GBeans
if WADI is to become a first class citizen.  The Tomcat GBean is purely
for the ability to declaratively swap out managers.

Thus, this will allow for a single ability to set up a generic tag that
both containers can understand how to act upon.

Jeff

David Jencks wrote:
  


It is possible (I think) to do what you want, but I do not recommend
it.  I would prefer that you use external plans, and write 2 new 
modules
inside configs, to deploy your sample to jetty and to tomcat.  Take 
the

geronimo-web.xml out of the app and put it in src/plan/plan.xml.

However, if you wish to defy me :-) you can use the generic schema
http://geronimo.apache.org/xml/ns/j2ee/web-1.0  (geronimo-web-1.0.xsd)
with sections in a container-config for the jetty and tomcat specific
parts.  These would use the namespace/schemas e.g.
http://geronimo.apache.org/xml/ns/web/jetty/config-1.0
(geronimo-jetty-config-1.0.xsd).

A problem with this approach might be that you are including a 
gbean in

the tomcat config that is not needed in the jetty config.  I don't
understand why this would be there anyway, but I don't think you can
have gbeans in the container-config part.

Is it possible to adjust the jetty and tomcat clustering configs to be
roughly the same and include the element in geronimo-web-1.0.xsd?

hope this helps
david jencks

On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:




Aaron, David, or anyone in the know :-)

Maybe you can help me with this:

I have a WADI demo webapp.

To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that
looks like this:

http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0";
configId="wadi">

  /wadi
  false

org.codehaus.wadi.jetty5.JettyManager 





To get it running with Tomcat, I have to have a geronimo-web.xml that
looks like this:

xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";

configId="wadi">

  /wadi
  false
  WADI

Regd OpenEJB

2006-01-05 Thread Manu George

Hi Gianny,
    I have a question on CMR
   Consider a Bean A and a bean B in a one to many CMR relationship
    Here A has 2 fields in the PK say a1 and a2
   
B has b1 fka1 and fka2 as the pk where fka1 and fka2 are the foreign
keys corressponding to the a1 and a2 of A.
    In
the ejbCreate of B when we set fka1 and fka2 won't OpenEJB throw an
error saying that they are readonly fields. This will happen even
after  implementing the logic for the special case where the
CompoundPK has 1 field.  Is this scenario a valid scenario? If so
can we change the check in createCMPFieldAccessors to check for primary
key and allow write access to CMR fields if they are parts of Primary
Keys? What should be the correct behaviour?

Thanks 
Manu

Re: geronimo-web.xml, container-config, container-specific namespaces

2006-01-05 Thread Greg Wilkins

Aaron Mulder wrote:
> Well...  is it possible to make this not specific to WADI?  Perhaps
> make it a generic "clustering manager" tag, and is "just so happens"
> that the only classes we let you configure so far are the WADI ones? 
> Ideally, we'd put some generic interface in the Geronimo space, and
> then the WADI ones would implement or extend that, so if we ever
> wanted to integrate other clustering options we'd leave that door
> open.

+1

I really think that clustering contents of geronimo-web.xml needs to
be moved out of the webapplication.  Clustering should be configured once 
and only once for the whole server - not within each web application (also
we have to consider EJB clustering which does not have a webapp).

So I really see that we need a new module called "cluster" (or "wadi" if
we want to persist with the implementation exposure we have with
jetty and tomcat).

If the only web container specific part of the configuration is to 
choose the class type of the session manager, then I think that this could
almost be hard coded in the jetty and tomcat modules - when they see
a distributable tag, they look for a cluster/wadi gbean and instantiate
a specific session manager that is required to work with it.

If there is other web app specific configuration, then it can be
left in a geronimo-web.xml, but hopefully as a non container specific
nature.

cheers

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

2006-01-05 Thread Greg Wilkins


Sorry guys but

-1

I've just had a report of a security issue in Jetty that reveals the
contents of WEB-INF on win32 platforms.Happy f*&#ing new year!

I have a fix and will be making a release very shortly.  To avoid any
other issues, I will probably roll back the other changes in HEAD so 
only this fix will go in.

But if it really is too late to change the jetty version, then -0

regards

Re: geronimo-web.xml, container-config, container-specific namespaces


Greg Wilkins wrote:


Aaron Mulder wrote:
 


Well...  is it possible to make this not specific to WADI?  Perhaps
make it a generic "clustering manager" tag, and is "just so happens"
that the only classes we let you configure so far are the WADI ones? 
Ideally, we'd put some generic interface in the Geronimo space, and

then the WADI ones would implement or extend that, so if we ever
wanted to integrate other clustering options we'd leave that door
open.
   



+1

I really think that clustering contents of geronimo-web.xml needs to
be moved out of the webapplication.  Clustering should be configured once 
and only once for the whole server - not within each web application (also

we have to consider EJB clustering which does not have a webapp).

So I really see that we need a new module called "cluster" (or "wadi" if
we want to persist with the implementation exposure we have with
jetty and tomcat).

If the only web container specific part of the configuration is to 
choose the class type of the session manager, then I think that this could

almost be hard coded in the jetty and tomcat modules - when they see
a distributable tag, they look for a cluster/wadi gbean and instantiate
a specific session manager that is required to work with it.

If there is other web app specific configuration, then it can be
left in a geronimo-web.xml, but hopefully as a non container specific
nature.

cheers
 


We are having a discussion about this on wadi-dev at the moment.

There are two approaches - per-app and per-server. Setting up clustering 
in the geronimo-web.xml corresponds to the per-app approach. Perhaps we 
could have an e.g. default-geronimo-web.xml in the server somewhere that 
sets up a server wide configuration.


For the per-server model that you advocate, we need some way of allowing 
webapps to 'own' their own session manager instance, whilst sharing 
components between these session managers, such as distribution medium etc.


WADI has initially been very focussed on the per-app approach, as this 
is currently the only way to shoe-horn it into the various containers 
that it supports, so further thought is needed here.


I suggest that Geronimo will want to support both approaches and that we 
come up with a framework that can do this, whilst pursuing the immediate 
goal of a per-app solution and then later on pushing towards a 
per-server based one.


Check out my other posting on this thread that advocates a 
top-level-gbean approach, using the geronimo-web.xml to hook it into the 
web-app context. Perhaps a SessionManagerFactoryGBean could be used on a 
per-server basis to create individual SessionManagers (for each app) 
that can then share further server-wide resources ?


Jules


--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Re: geronimo-web.xml, container-config, container-specific namespaces



Greg Wilkins wrote:
> Aaron Mulder wrote:
>> Well...  is it possible to make this not specific to WADI?  Perhaps
>> make it a generic "clustering manager" tag, and is "just so happens"
>> that the only classes we let you configure so far are the WADI ones? 
>> Ideally, we'd put some generic interface in the Geronimo space, and
>> then the WADI ones would implement or extend that, so if we ever
>> wanted to integrate other clustering options we'd leave that door
>> open.
> 
> +1
> 
> I really think that clustering contents of geronimo-web.xml needs to
> be moved out of the webapplication.  Clustering should be configured once 
> and only once for the whole server - not within each web application (also
> we have to consider EJB clustering which does not have a webapp).

I don't agree on this point.  You should be able to specify certain web
apps that need clustering and others that do not.  IMHO, you should be
able to cluster the components that you want, and not turn it on for the
entire server.  The Tomcat clustering works this way today.  I can turn
on clustering at the Engine, host, or context level.

> 
> So I really see that we need a new module called "cluster" (or "wadi" if
> we want to persist with the implementation exposure we have with
> jetty and tomcat).
> 
> If the only web container specific part of the configuration is to 
> choose the class type of the session manager, then I think that this could
> almost be hard coded in the jetty and tomcat modules - when they see
> a distributable tag, they look for a cluster/wadi gbean and instantiate
> a specific session manager that is required to work with it.
> 
> If there is other web app specific configuration, then it can be
> left in a geronimo-web.xml, but hopefully as a non container specific
> nature.
> 
> cheers
> 
> 
>

[jira] Created: (GERONIMO-1419) javax.mail.internet.InternetHeaders has some non implemented features

2006-01-05 Thread Guillaume Nodet (JIRA)

javax.mail.internet.InternetHeaders has some non implemented features
-

 Key: GERONIMO-1419
 URL: http://issues.apache.org/jira/browse/GERONIMO-1419
 Project: Geronimo
Type: Bug
  Components: specs  
Reporter: Guillaume Nodet
 Attachments: GERONIMO-1419.patch

Some methods throw a UnsupportedOperationException

-- 
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-1419) javax.mail.internet.InternetHeaders has some non implemented features

2006-01-05 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet updated GERONIMO-1419:
--

Attachment: GERONIMO-1419.patch

Patch for non implemented methods in javax.mail.internet.InternetHeaders

> javax.mail.internet.InternetHeaders has some non implemented features
> -
>
>  Key: GERONIMO-1419
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1419
>  Project: Geronimo
> Type: Bug
>   Components: specs
> Reporter: Guillaume Nodet
>  Attachments: GERONIMO-1419.patch
>
> Some methods throw a UnsupportedOperationException

-- 
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: geronimo-web.xml, container-config, container-specific namespaces

2006-01-05 Thread Aaron Mulder

In my personal experience, any machine in a cluster is fully in a
cluster -- I haven't seen something like 10 machines running 1
clustered app and then each running something else on the side.

However, it is kind of nice in WebLogic that you can deploy to either
a cluster or a single machine.  I would lean toward that kind of
approach.  You set up clustering at the server level, and then each
application can either be deployed to individual servers or to the
cluster, but if you don't set up clustering at the server level,
there's no cluster to deploy to and you have to deploy to individual
servers.   (There's plumbing in our deployer so it could support that
kind of approach.)

Aaron

On 1/5/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>
> Greg Wilkins wrote:
> > Aaron Mulder wrote:
> >> Well...  is it possible to make this not specific to WADI?  Perhaps
> >> make it a generic "clustering manager" tag, and is "just so happens"
> >> that the only classes we let you configure so far are the WADI ones?
> >> Ideally, we'd put some generic interface in the Geronimo space, and
> >> then the WADI ones would implement or extend that, so if we ever
> >> wanted to integrate other clustering options we'd leave that door
> >> open.
> >
> > +1
> >
> > I really think that clustering contents of geronimo-web.xml needs to
> > be moved out of the webapplication.  Clustering should be configured once
> > and only once for the whole server - not within each web application (also
> > we have to consider EJB clustering which does not have a webapp).
>
> I don't agree on this point.  You should be able to specify certain web
> apps that need clustering and others that do not.  IMHO, you should be
> able to cluster the components that you want, and not turn it on for the
> entire server.  The Tomcat clustering works this way today.  I can turn
> on clustering at the Engine, host, or context level.
>
> >
> > So I really see that we need a new module called "cluster" (or "wadi" if
> > we want to persist with the implementation exposure we have with
> > jetty and tomcat).
> >
> > If the only web container specific part of the configuration is to
> > choose the class type of the session manager, then I think that this could
> > almost be hard coded in the jetty and tomcat modules - when they see
> > a distributable tag, they look for a cluster/wadi gbean and instantiate
> > a specific session manager that is required to work with it.
> >
> > If there is other web app specific configuration, then it can be
> > left in a geronimo-web.xml, but hopefully as a non container specific
> > nature.
> >
> > cheers
> >
> >
> >
>

Re: geronimo-web.xml, container-config, container-specific namespaces



Aaron Mulder wrote:
> In my personal experience, any machine in a cluster is fully in a
> cluster -- I haven't seen something like 10 machines running 1
> clustered app and then each running something else on the side.

I can't agree...I may want to cluster my app, but I surely do not want
to cluster the console.  I think there are various use cases that can be
applied here.

> 
> However, it is kind of nice in WebLogic that you can deploy to either
> a cluster or a single machine.  I would lean toward that kind of
> approach.  You set up clustering at the server level, and then each
> application can either be deployed to individual servers or to the
> cluster, but if you don't set up clustering at the server level,
> there's no cluster to deploy to and you have to deploy to individual
> servers.   (There's plumbing in our deployer so it could support that
> kind of approach.)
> 
> Aaron
> 
> On 1/5/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>
>> Greg Wilkins wrote:
>>> Aaron Mulder wrote:
 Well...  is it possible to make this not specific to WADI?  Perhaps
 make it a generic "clustering manager" tag, and is "just so happens"
 that the only classes we let you configure so far are the WADI ones?
 Ideally, we'd put some generic interface in the Geronimo space, and
 then the WADI ones would implement or extend that, so if we ever
 wanted to integrate other clustering options we'd leave that door
 open.
>>> +1
>>>
>>> I really think that clustering contents of geronimo-web.xml needs to
>>> be moved out of the webapplication.  Clustering should be configured once
>>> and only once for the whole server - not within each web application (also
>>> we have to consider EJB clustering which does not have a webapp).
>> I don't agree on this point.  You should be able to specify certain web
>> apps that need clustering and others that do not.  IMHO, you should be
>> able to cluster the components that you want, and not turn it on for the
>> entire server.  The Tomcat clustering works this way today.  I can turn
>> on clustering at the Engine, host, or context level.
>>
>>> So I really see that we need a new module called "cluster" (or "wadi" if
>>> we want to persist with the implementation exposure we have with
>>> jetty and tomcat).
>>>
>>> If the only web container specific part of the configuration is to
>>> choose the class type of the session manager, then I think that this could
>>> almost be hard coded in the jetty and tomcat modules - when they see
>>> a distributable tag, they look for a cluster/wadi gbean and instantiate
>>> a specific session manager that is required to work with it.
>>>
>>> If there is other web app specific configuration, then it can be
>>> left in a geronimo-web.xml, but hopefully as a non container specific
>>> nature.
>>>
>>> cheers
>>>
>>>
>>>

Re: [wadi-dev] Re: [Geronimo] Clustering

2006-01-05 Thread Rajith Attapattu

Hmm,  again we have stopped the discussion :). Lets get it started again.
 
So can we all come to some agreement (with more discussion) on which direction we might be taking !!
 
Like merging ActiveCluster and WADI or getting best of both worlds ?
 
And also if we can define expectations/requirments for what we like for the next possible release (1.01 or whatever) in terms of clustering would give folks like me more direction as to where we should concentrate on?

 
If we decide on a direction maybe a few of us can start on a few prototypes and see what works best for Geronimo.
 
Regards,
 
Rajith Attapattu. 
On 1/5/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
-Original Message-From: Jules Gosnell [mailto:
[EMAIL PROTECTED]]Sent: Monday, December 19, 2005 9:55 AMTo: [EMAIL PROTECTED]Cc: wadi-dev@incubator.apache.org
; dev@geronimo.apache.orgSubject: Re: [wadi-dev] Re: [Geronimo] ClusteringJames Strachan wrote:>> On 19 Dec 2005, at 14:14, Jules Gosnell wrote:
>>> James Strachan wrote:> On 19 Dec 2005, at 11:53, Jules Gosnell wrote:>>> , whether there is other suitable Geronimo or ASF-licensed code
 available, or whether we will need to write our own WADI- autodiscovery classes. The important thing is to impose as few dependencies on the client as possible. The client side code
 should  literally be a few lines. Clients using clusters should not  suddenly find themselves sucking down e.g. the whole of activemq,  just to do a once off autodiscovery. Early versions of
 WADI had its  own autodiscovery code. If we need them, they could be resuscitated. There's no reason why you can't do a simple implementation of
>>> ActiveCluster which doesn't use ActiveMQ - its just a simple API.>> Sure - but I'm talking about the EJB-client side - where we just>> want to throw across as thin a line as possible, in order to haul a
>> decent strength cable back. An EJB client would not need the>> ActiveCluster API (I'm not thinking in terms of making EJB clients>> fully fledged cluster members), but simply a way of locating the
>> cluster and requesting a membership snapshot of it.>>> Thats exactly what the ActiveCluster API is for :). Though by all> means come up with another API if you can think of a better way of
> doing it.>>> This could be done by just broadcasting a query packet at a well>> known multicast address and waiting for the first well-formedresponse.>>> Sure - an *implementation* of ActiveCluster API could do exactly that.
>???well, maybe I'm thinking of the wrong piece of activecluster then ?any piece of code could broadcast a packet... which piece ofactivecluster's API are you suggesting here ?we really are talking about just a remoting proxy which needs to find,
but not 'join' a cluster.can you be more specific ?Jules> James> ---> http://radio.weblogs.com/0112098/--
"Open Source is a self-assembling organism. You dangle a piece ofstring into a super-saturated solution and a whole operating-systemcrystallises out around it."/**
* Jules Gosnell* Partner* Core Developers Network (Europe)**www.coredevelopers.net** Open Source Training & Support.**/

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

2006-01-05 Thread Matt Hogstrom


Greg,

I was wrapping up the release last night and was releasing it today based on the 
prior feedback.  Can you provide some more details on the exposure?  My 
preference would be to release G 1.0 as is and fix this in 1.0.1.  I need your 
expert opinion of the exposure WRT to security.


There will always be something left to fix this will delay releasing about 1 
week to allow for a new review of the code, re-certification, etc.


I see a few options at this point.

1. Continue with the release despite this information.

2. Hold the release until this can be fixed (which then also begs the question 
of moving to the more recent Tomcat version with their fix for 0 content length 
on POST requests).  This will delay the release for at least one week.


3. Ship Geronimo with Tomcat and get 1.0 out the door.  We ship with both Tomcat 
and Jetty for 1.0.1 with this security fix inclued.


The security hole you've outlined sounds serious but I was wondering if its a 
specific set of implementations that could be documented (ie. is this something 
that someone just found and its a rather obscure config?)


Other input welcome.  I'm going to complete getting the release ready but defer 
punching the button until this afternoon (about 1500 PT).


Matt

Greg Wilkins wrote:

Sorry guys but

-1

I've just had a report of a security issue in Jetty that reveals the
contents of WEB-INF on win32 platforms.Happy f*&#ing new year!

I have a fix and will be making a release very shortly.  To avoid any
other issues, I will probably roll back the other changes in HEAD so 
only this fix will go in.


But if it really is too late to change the jetty version, then -0

regards

[jira] Created: (GERONIMO-1420) HTTP Status 500 message should refer to geronimo logs

2006-01-05 Thread anita kulshreshtha (JIRA)

HTTP Status 500 message should refer to geronimo logs
-

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


When an exception trace is produced by a web app,  the message refers to Apache 
Tomcat/5.5.12 logs. This might be a hard coded message given by tomcat. See if 
it can be easily changed.

HTTP Status 500 -

type Exception report


message

description The server encountered an internal error () that prevented it from 
fulfilling this request.

exception

java.lang.NullPointerException
org.apache.geronimo.stats.JSR77Servlet.doGet(JSR77Servlet.java:78)
javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
javax.servlet.http.HttpServlet.service(HttpServlet.java:688)

note The full stack trace of the root cause is available in the Apache 
Tomcat/5.5.12 logs.

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

Geronimo 2.0

2006-01-05 Thread Alan D. Cabrera

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It's my understading that we're going for JEE 5.  I think that our
re-arch of security should go into that as well.

How do we want to stage this effort in terms of SVN organization?  When
should we cut a 2.0 development branch?


Regards,
Alan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvWPm1xC6qnMLUpYRAmQWAJ0eCHtNjhMH/IO4+LtNR3sUaLTmNgCfZ0YU
aTEL53hKe+hA9qF54wt3yWI=
=UMhP
-END PGP SIGNATURE-

Re: Geronimo 2.0

+1...I really like this idea.

Alan D. Cabrera wrote:
> It's my understading that we're going for JEE 5.  I think that our
> re-arch of security should go into that as well.
> 
> How do we want to stage this effort in terms of SVN organization?  When
> should we cut a 2.0 development branch?
> 
> 
> Regards,
> Alan
>

Can we get the Geronimo IRC archive working again?

2006-01-05 Thread Joe Bohn



Does anybody know who initially setup the IRC archive and/or how to get 
it back again?  It looks like somebody with id "bevinbot" set it up ... 
similar enough to make me wonder if it was Blevins but different enough 
so that I can't be sure.  I'd be glad to help get this working again if 
I can get some pointers.  It's been down for nearly 2 months now and I 
really miss it.


Joe

--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: Commit of r366236

Jan,

Per the commit of r366236...

-1 on including Axiom.  That is just for the web app.  We should not be
including that in the container.  Also, you can use the standard
ActiveMQ..there is no need to use the WADI version.  The WADI version
was due to M2 POMs being incorrect and it broke the WADI builds.  They
are identical to 3.2.1.

Jeff


Index: project.xml
===
--- project.xml (revision 366235)
+++ project.xml (working copy)
@@ -190,6 +190,9 @@
 concurrent
 concurrent
 ${concurrent_version}
+
+ true
+ 
 

 
@@ -197,6 +200,9 @@
 regexp
 ${regexp_version}
 http://jakarta.apache.org/regexp
+
+ true
+ 
 

 
@@ -241,6 +247,22 @@
  
 
 
+commons-collections
+commons-collections
+${commons_collections_version}
+
+ true
+ 
+
+
+commons-primitives
+commons-primitives
+${commons_primitives_version}
+
+ true
+ 
+
+
 springframework
 spring
 ${wadi_spring_version}
@@ -250,6 +272,14 @@
  
 
 
+backport-util-concurrent
+backport-util-concurrent
+${backport_util_concurrent_version}
+
+ true
+ 
+
+
 activecluster
 activecluster
 ${wadi_activecluster_version}
@@ -258,6 +288,23 @@
  
 
 
+activemq
+activemq
+${wadi_activemq_version}
+
+ true
+ 
+
+
+axion
+axion
+${wadi_axion_version}
+
+ true
+ 
+
+
+
 wadi
 wadi-core
 ${wadi_version}

Re: Can we get the Geronimo IRC archive working again?

2006-01-05 Thread Daniel S. Haischt

Joe Bohn schrieb:
> I'd be glad to help get this working again if
> I can get some pointers.  It's been down for nearly 2 months now and I
> really miss it.
> 
> Joe
> 

Maybe it would be even possible to register the Geronimo project at ...

 * The CIA Open Source Notification System
   -> http://cia.navi.cx/

 * A lisppaste bot instance
   -> http://common-lisp.net/project/lisppaste/

 * At -> http://meme.b9.com/

-- 
Mit freundlichen Gruessen / With kind regards
DAn.I.El S. Haischt

Spammers, please please send any mail to:
Daniel S. Haischt <[EMAIL PROTECTED]>

Want a complete signature??? Type at a shell prompt:
$ > finger -l [EMAIL PROTECTED]

Re: Building 1.0 release candidate from source - URL for svn checkout

2006-01-05 Thread Joe Bohn



For the moment these are identical so it really doesn't matter.  Once 
1.0 is official then you would use the tag to get back to level that is 
released as 1.0.  I imagine that the branch will be used for maintenance 
on 1.0 with tags created for specific fixpacks.


Joe

Vamsavardhana Reddy wrote:

Hi,

Which URL should be used with svn to checkout the source for building 
1.0 release candidate?  Is it 
https://svn.apache.org/repos/asf/geronimo/branches/1.0/ or 
https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ or something else?


Thanks,
Vamsi


--
Joe Bohn
[EMAIL PROTECTED]

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: Building 1.0 release candidate from source - URL for svn checkout


Vamsavardhana,

It should be built from the 1.0.0 tag (the 2nd url you had below), as 
the 1.0 branch will soon contain changes for 1.0.1.


John

Vamsavardhana Reddy wrote:


Hi,

Which URL should be used with svn to checkout the source for building 
1.0 release candidate?  Is it 
https://svn.apache.org/repos/asf/geronimo/branches/1.0/ or 
https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/ or something else?


Thanks,
Vamsi

1.0 Build failure on WinXP

2006-01-05 Thread Joe Bohn

I've been trying to build 1.0 for a while now on winXP and I always get
a failure preparing the CRLF endings (actually I get this failure about
90% of the time and it works the other 10%).

assemble:package-assembly:
[echo] Preparing CRLF line endings in text based files for zip
distribution

BUILD FAILED
File.. C:\geronimo1.0\maven.xml
Element... maven:reactor
Line.. 63
Column -1
Unable to obtain goal [multiproject:install-callback] -- C:\Documents
and
Settings\Administrator\.maven\cache\geronimo-assembly-plugin-1.0.2\plugin.jelly:285:-1
: java.io.FileNotFoundException:
C:\geronimo1.0\assemblies\j2ee-jetty-server\target\geronimo-1.0\config-store\21\war\index.html
(Access is denied)

Total time : 26 minutes 17 seconds
Finished at : Thursday, January 5, 2006 12:39:55 PM EST

I've been ignoring this because I typically run right off of the
assemblies that are created ... but it bothers me that I can't get a
clean 1.0 build on Windows as we are about to release. The
configuration in "21" appears to be the demo application and it doesn't
include an index.html (hence the failure). I'm not altogether sure why
the CRLF code thinks there should be an index.html to convert.

One other curious thing I noticed is that there are 32 configurations in
config-store for the jetty image but only 31 for tomcat. Anybody know
offhand what the difference is and why?

Thanks,
Joe

--
Joe Bohn
[EMAIL PROTECTED]

"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot

Re: Geronimo Installation Document Section

2006-01-05 Thread Hernan Cunico

Hi Jason,
how is the installation doc coming, do you need any help on the confluence side?

I saw what you started to work on the "Getting the source code" section, I would suggest to keep
this task simple. We do not want to _scare_ the users with way too complicated commands and
parameters, all at once.

There are basically four steps to get the source and build Geronimo, so I would
focus on those first.

1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/

2.- cd
3.- maven m:fresh-checkout
4.- maven new

Then, the next time you want to build you just do an update

1.- cd
2.- maven m:update
3.- maven m:fresh-checkout
4.- maven new

(BTW, all the steps should be validated and make sure they are up-to-date)

Once you explained the basics then you can go more in detail with all the other options for
retrieving the source code and building Geronimo. It would also be nice to include common building
errors, how to identify them, probable causes and solutions.

Again, this is just a suggestion. What you think about this approach?

As for update preference, I think is best to update as you go so everybody can test your
instructions and provide early comments that will make corrections (if any) easier.

Cheers!
Hernan

Jason Lenhart wrote:

Hi,

I am starting on the Installation section of the docs
- I have been running around like a maniac doing stuff
(mostly holiday things) - so I am a bit slow to
produce. But I am setting aside some time each day to
contribute more and more to the docs. If you start to
see me go off base - please feel free to call me out
:-D

Also - is the preference to complete a section and
then update? I started and updated but it is not
complete.

Thanks,

Jason

__
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com

Re: Geronimo Installation Document Section

2006-01-05 Thread Sachin Patel



- sachin



On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote:


Hi Jason,
how is the installation doc coming, do you need any help on the  
confluence side?


I saw what you started to work on the "Getting the source code"  
section, I would suggest to keep this task simple. We do not want  
to _scare_ the users with way too complicated commands and  
parameters, all at once.


There are basically four steps to get the source and build  
Geronimo, so I would focus on those first.


1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 
1.0.0/ 

2.- cd 
3.- maven m:fresh-checkout
4.- maven new

Then, the next time you want to build you just do an update

1.- cd 
2.- maven m:update
3.- maven m:fresh-checkout


Take out #3


4.- maven new


add -o



(BTW, all the steps should be validated and make sure they are up- 
to-date)


Once you explained the basics then you can go more in detail with  
all the other options for retrieving the source code and building  
Geronimo. It would also be nice to include common building errors,  
how to identify them, probable causes and solutions.


Again, this is just a suggestion. What you think about this approach?

As for update preference, I think is best to update as you go so  
everybody can test your instructions and provide early comments  
that will make corrections (if any) easier.


Cheers!
Hernan

Jason Lenhart wrote:

Hi,
I am starting on the Installation section of the docs
- I have been running around like a maniac doing stuff
(mostly holiday things) - so I am a bit slow to
produce.  But I am setting aside some time each day to
contribute more and more to the docs.  If you start to
see me go off base - please feel free to call me out
:-D
Also - is the preference to complete a section and
then update?  I started and updated but it is not
complete.
Thanks,
Jason

__ Yahoo! DSL – Something  
to write home about. Just $16.99/mo. or less. dsl.yahoo.com

[jira] Created: (GERONIMO-1421) DB portlet failure in Tomcat only

2006-01-05 Thread Aaron Mulder (JIRA)

DB portlet failure in Tomcat only
-

 Key: GERONIMO-1421
 URL: http://issues.apache.org/jira/browse/GERONIMO-1421
 Project: Geronimo
Type: Bug
  Components: console, Tomcat  
Versions: 1.0
Reporter: Aaron Mulder
 Fix For: 1.1


 - create a new database pool using the DB portlet
 - select the "Derby Embedded" type
 - pick the derby or derby-client JAR
 - give it a new or existing database name
 - add ;create=true to the end of the generated URL
 - click test

This procedure works in the Jetty build but does not work in the Tomcat build.  
In Tomcat, it just redirects to the main screen for that portlet without any 
error message.  The database is actually created (visible in the DB Manager 
portlet).  This does not happen if you remove ;create=true from the URL and use 
an existing database.

-- 
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: Geronimo Installation Document Section

2006-01-05 Thread Hernan Cunico

On my machine, if I don't do a fresh-checkout the build fails. In fact it always fails the first
attempt and the second round works as long as I do the fresh-checkout.

Any idea why this is happening?

Cheers!
Hernan

Sachin Patel wrote:

- sachin

On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote:

Hi Jason,
how is the installation doc coming, do you need any help on the
confluence side?

I saw what you started to work on the "Getting the source code"
section, I would suggest to keep this task simple. We do not want to
_scare_ the users with way too complicated commands and parameters,
all at once.

There are basically four steps to get the source and build Geronimo,
so I would focus on those first.

1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/
1.0.0/

2.- cd
3.- maven m:fresh-checkout
4.- maven new

Then, the next time you want to build you just do an update

1.- cd
2.- maven m:update
3.- maven m:fresh-checkout

Take out #3

4.- maven new

add -o

(BTW, all the steps should be validated and make sure they are up-
to-date)

Once you explained the basics then you can go more in detail with all
the other options for retrieving the source code and building
Geronimo. It would also be nice to include common building errors,
how to identify them, probable causes and solutions.

Again, this is just a suggestion. What you think about this approach?

As for update preference, I think is best to update as you go so
everybody can test your instructions and provide early comments that
will make corrections (if any) easier.

Cheers!
Hernan

Jason Lenhart wrote:

Hi,
I am starting on the Installation section of the docs
- I have been running around like a maniac doing stuff
(mostly holiday things) - so I am a bit slow to
produce. But I am setting aside some time each day to
contribute more and more to the docs. If you start to
see me go off base - please feel free to call me out
:-D
Also - is the preference to complete a section and
then update? I started and updated but it is not
complete.
Thanks,
Jason

__ Yahoo! DSL – Something to
write home about. Just $16.99/mo. or less. dsl.yahoo.com

Re: Geronimo 2.0

2006-01-05 Thread Jacek Laskowski

2006/1/5, Alan D. Cabrera <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> It's my understading that we're going for JEE 5.  I think that our
> re-arch of security should go into that as well.
>
> How do we want to stage this effort in terms of SVN organization?  When
> should we cut a 2.0 development branch?

Hi Alan,

I think there's no point holding it any longer. Since the 1.0 release
is on its own branch, we can safely change all of the build artefacts
to 2.0-SNAPSHOT.

> Alan

Jacek

Re: [Fwd: [Vote] 1.0 Release - Do we ship it?]

2006-01-05 Thread Greg Wilkins

After chatting on IM, it does appear that it is too late to 
change the jetty version, so I retract my -1 and make it a -0.

The 1.0 release can go out with the windows security problem - I don't 
think many will be rushing it into production.

The Jetty 5.1.10 release is available and the can be used to replace
the jar if security is paramount.

Some text for the release notes:

There is a security issue with the Jetty 5.1.9 used by geronimo 1.0, which
allows a crafted URL to access the contents of a WEB-INF directory if the
server is running on a windows platform.   This issue is fixed in Jetty 5.1.10
and the 5.1.9 jar in geronimo 1.0 can be replaced with the jar from 5.1.10.
It is not recommended that Geronimo-jetty 1.0 be used on to serve a non-open
web application from a windows platform.

cheers

Matt Hogstrom wrote:
> Greg,
> 
> I was wrapping up the release last night and was releasing it today
> based on the prior feedback.  Can you provide some more details on the
> exposure?  My preference would be to release G 1.0 as is and fix this in
> 1.0.1.  I need your expert opinion of the exposure WRT to security.
> 
> There will always be something left to fix this will delay releasing
> about 1 week to allow for a new review of the code, re-certification, etc.
> 
> I see a few options at this point.
> 
> 1. Continue with the release despite this information.
> 
> 2. Hold the release until this can be fixed (which then also begs the
> question of moving to the more recent Tomcat version with their fix for
> 0 content length on POST requests).  This will delay the release for at
> least one week.
> 
> 3. Ship Geronimo with Tomcat and get 1.0 out the door.  We ship with
> both Tomcat and Jetty for 1.0.1 with this security fix inclued.
> 
> The security hole you've outlined sounds serious but I was wondering if
> its a specific set of implementations that could be documented (ie. is
> this something that someone just found and its a rather obscure config?)
> 
> Other input welcome.  I'm going to complete getting the release ready
> but defer punching the button until this afternoon (about 1500 PT).
> 
> Matt
> 
> Greg Wilkins wrote:
> 
>> Sorry guys but
>>
>> -1
>>
>> I've just had a report of a security issue in Jetty that reveals the
>> contents of WEB-INF on win32 platforms.Happy f*&#ing new year!
>>
>> I have a fix and will be making a release very shortly.  To avoid any
>> other issues, I will probably roll back the other changes in HEAD so
>> only this fix will go in.
>>
>> But if it really is too late to change the jetty version, then -0
>>
>> regards
>>
>>
>>
>

Re: Can we get the Geronimo IRC archive working again?

2006-01-05 Thread Daniel S. Haischt

If there are no objections I can register the Geronimo project with ...

 * http://meme.b9.com/ - That's a channel logger
   with a search interface.

 * lisppaste - that's a pastbot with a corresponding web interface.

 * CIA - That's an open source tracking system. which tracks the
   project's progress. Tho - requires to install a little shell
   script on the SVN server that will be executed on each commit.

Daniel S. Haischt schrieb:
> Joe Bohn schrieb:
> 
>>I'd be glad to help get this working again if
>>I can get some pointers.  It's been down for nearly 2 months now and I
>>really miss it.
>>
>>Joe
>>
> 
> 
> Maybe it would be even possible to register the Geronimo project at ...
> 
>  * The CIA Open Source Notification System
>-> http://cia.navi.cx/
> 
>  * A lisppaste bot instance
>-> http://common-lisp.net/project/lisppaste/
> 
>  * At -> http://meme.b9.com/
> 


-- 
Mit freundlichen Gruessen / With kind regards
DAn.I.El S. Haischt

Spammers, please please send any mail to:
Daniel S. Haischt <[EMAIL PROTECTED]>

Want a complete signature??? Type at a shell prompt:
$ > finger -l [EMAIL PROTECTED]

Re: Geronimo 2.0

2006-01-05 Thread Bruce Snyder

On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:

> It's my understading that we're going for JEE 5.  I think that our
> re-arch of security should go into that as well.

Agreed.

> How do we want to stage this effort in terms of SVN organization?  When
> should we cut a 2.0 development branch?

I suppose that the JEE 5 work would be best suited to a 2.0 branch.
That means that there is a potential to have to do a lot of double
work. What I mean to say is that any new innovations being committed
to the HEAD will need to be refactored and committed to the 2.0
branch. And this work will increase more with the addition of more
branches (e.g., 1.1, 1.2, etc.).

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

Re: Geronimo Installation Document Section

You need to do the fresh-checkout the first time you get the source so 
that you get the OpenEJB code (from CVS).  AFAIK, you shouldn't need to 
do a fresh-checkout again because an m:update will update both svn and 
OpenEJB CVS files.


Not sure why you would need to do a fresh-checkout a second time for the 
second round to work.


John

Hernan Cunico wrote:

On my machine, if I don't do a fresh-checkout the build fails. In fact 
it always fails the first attempt and the second round works as long 
as I do the fresh-checkout.


Any idea why this is happening?

Cheers!
Hernan

Sachin Patel wrote:



- sachin



On Jan 5, 2006, at 4:16 PM, Hernan Cunico wrote:


Hi Jason,
how is the installation doc coming, do you need any help on the  
confluence side?


I saw what you started to work on the "Getting the source code"  
section, I would suggest to keep this task simple. We do not want  
to _scare_ the users with way too complicated commands and  
parameters, all at once.


There are basically four steps to get the source and build  
Geronimo, so I would focus on those first.


1.- svn checkout https://svn.apache.org/repos/asf/geronimo/tags/ 
1.0.0/ 

2.- cd 
3.- maven m:fresh-checkout
4.- maven new

Then, the next time you want to build you just do an update

1.- cd 
2.- maven m:update
3.- maven m:fresh-checkout




Take out #3


4.- maven new




add -o



(BTW, all the steps should be validated and make sure they are up- 
to-date)


Once you explained the basics then you can go more in detail with  
all the other options for retrieving the source code and building  
Geronimo. It would also be nice to include common building errors,  
how to identify them, probable causes and solutions.


Again, this is just a suggestion. What you think about this approach?

As for update preference, I think is best to update as you go so  
everybody can test your instructions and provide early comments  
that will make corrections (if any) easier.


Cheers!
Hernan

Jason Lenhart wrote:


Hi,
I am starting on the Installation section of the docs
- I have been running around like a maniac doing stuff
(mostly holiday things) - so I am a bit slow to
produce.  But I am setting aside some time each day to
contribute more and more to the docs.  If you start to
see me go off base - please feel free to call me out
:-D
Also - is the preference to complete a section and
then update?  I started and updated but it is not
complete.
Thanks,
Jason
   __ Yahoo! DSL – 
Something  to write home about. Just $16.99/mo. or less. dsl.yahoo.com

Re: Geronimo 2.0

2006-01-05 Thread Alan D. Cabrera

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bruce Snyder wrote, On 1/5/2006 3:43 PM:
> On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> 
> 
>>It's my understading that we're going for JEE 5.  I think that our
>>re-arch of security should go into that as well.
> 
> 
> Agreed.
> 
> 
>>How do we want to stage this effort in terms of SVN organization?  When
>>should we cut a 2.0 development branch?
> 
> 
> I suppose that the JEE 5 work would be best suited to a 2.0 branch.
> That means that there is a potential to have to do a lot of double
> work. What I mean to say is that any new innovations being committed
> to the HEAD will need to be refactored and committed to the 2.0
> branch. And this work will increase more with the addition of more
> branches (e.g., 1.1, 1.2, etc.).

You touched on the concern that I had.  I'm thinking that once we cut
this, there will be no further work on 1.x, because everyone will want
to work on 2.x.


Regards,
Alan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvba11xC6qnMLUpYRAuAEAJ9c0uQDLeGgIzcqqR/iKv2l99QC5wCdGhVB
foYWLFogfXXWxoMY/OEXtI8=
=zGE8
-END PGP SIGNATURE-

Re: Geronimo 2.0

2006-01-05 Thread Bruce Snyder

On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:

> >>How do we want to stage this effort in terms of SVN organization?  When
> >>should we cut a 2.0 development branch?
> >
> >
> > I suppose that the JEE 5 work would be best suited to a 2.0 branch.
> > That means that there is a potential to have to do a lot of double
> > work. What I mean to say is that any new innovations being committed
> > to the HEAD will need to be refactored and committed to the 2.0
> > branch. And this work will increase more with the addition of more
> > branches (e.g., 1.1, 1.2, etc.).
>
> You touched on the concern that I had.  I'm thinking that once we cut
> this, there will be no further work on 1.x, because everyone will want
> to work on 2.x.

Then we should probably consider making a decision that the HEAD
should contain 2.x work only. If any fixes need to be done to the 1.x
code then proper branching and tagging should occur to facilitate that
work.

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

Re: Geronimo 2.0

2006-01-05 Thread Alan D. Cabrera

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bruce Snyder wrote, On 1/5/2006 4:26 PM:
> On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> 
> 
How do we want to stage this effort in terms of SVN organization?  When
should we cut a 2.0 development branch?
>>>
>>>
>>>I suppose that the JEE 5 work would be best suited to a 2.0 branch.
>>>That means that there is a potential to have to do a lot of double
>>>work. What I mean to say is that any new innovations being committed
>>>to the HEAD will need to be refactored and committed to the 2.0
>>>branch. And this work will increase more with the addition of more
>>>branches (e.g., 1.1, 1.2, etc.).
>>
>>You touched on the concern that I had.  I'm thinking that once we cut
>>this, there will be no further work on 1.x, because everyone will want
>>to work on 2.x.
> 
> 
> Then we should probably consider making a decision that the HEAD
> should contain 2.x work only. If any fixes need to be done to the 1.x
> code then proper branching and tagging should occur to facilitate that
> work.

Good point.  What do others think?


Regards,
Alan


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt
0ThTQUdCzTdCaaapV71OgZ8=
=L4zh
-END PGP SIGNATURE-

[jira] Created: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds

2006-01-05 Thread John Sisson (JIRA)

Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect 
endpoints to broker every 30 seconds


 Key: GERONIMO-1422
 URL: http://issues.apache.org/jira/browse/GERONIMO-1422
 Project: Geronimo
Type: Bug
  Components: ActiveMQ  
Versions: 1.0
 Environment: Solaris 10 x86 under VMWare player 1.01
Java 1.4.2_10
tomcat build of geronimo
Reporter: John Sisson
 Fix For: 1.1
 Attachments: geronimo_shutdown_stdout.txt

Can anyone reproduce this problem on other platforms?

If I start the tomcat build of the release candidate and then shut it down once 
the startup has completed it shuts down almost cleanly:

Server shutdown begun  
11:25:47,951 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
http-0.0.0.0-8443
11:25:48,986 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
http-0.0.0.0-8080
11:25:49,001 INFO  [StandardContext] Container 
org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been 
started
Server shutdown completed

I have shutdown issues If I do the following:

* start the tomcat build of release candidate using geronimo.sh run --long
* connect to the daytrader web app
*  populate the daytrader database via the daytrader configuration page
* log into daytrader and view account, portfolio etc.
* press ctrl-C in the window that geronimo was started in to shut it down.  
* You will see ActiveMQAsfEndpointWorker messages every 30 seconds.  

I will attach a capture of stdout also including a thread dump to this issue.





-- 
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-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds

2006-01-05 Thread John Sisson (JIRA)

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

John Sisson updated GERONIMO-1422:
--

Attachment: geronimo_shutdown_stdout.txt

> Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect 
> endpoints to broker every 30 seconds
> 
>
>  Key: GERONIMO-1422
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1422
>  Project: Geronimo
> Type: Bug
>   Components: ActiveMQ
> Versions: 1.0
>  Environment: Solaris 10 x86 under VMWare player 1.01
> Java 1.4.2_10
> tomcat build of geronimo
> Reporter: John Sisson
>  Fix For: 1.1
>  Attachments: geronimo_shutdown_stdout.txt
>
> Can anyone reproduce this problem on other platforms?
> If I start the tomcat build of the release candidate and then shut it down 
> once the startup has completed it shuts down almost cleanly:
> Server shutdown begun  
> 11:25:47,951 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8443
> 11:25:48,986 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8080
> 11:25:49,001 INFO  [StandardContext] Container 
> org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not 
> been started
> Server shutdown completed
> I have shutdown issues If I do the following:
> * start the tomcat build of release candidate using geronimo.sh run --long
> * connect to the daytrader web app
> *  populate the daytrader database via the daytrader configuration page
> * log into daytrader and view account, portfolio etc.
> * press ctrl-C in the window that geronimo was started in to shut it down.  
> * You will see ActiveMQAsfEndpointWorker messages every 30 seconds.  
> I will attach a capture of stdout also including a thread dump to this issue.

-- 
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-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds

2006-01-05 Thread John Sisson (JIRA)

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

John Sisson updated GERONIMO-1422:
--

Fix Version: 1.1
Version: 1.0

> Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect 
> endpoints to broker every 30 seconds
> 
>
>  Key: GERONIMO-1422
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1422
>  Project: Geronimo
> Type: Bug
>   Components: ActiveMQ
> Versions: 1.0
>  Environment: Solaris 10 x86 under VMWare player 1.01
> Java 1.4.2_10
> tomcat build of geronimo
> Reporter: John Sisson
>  Fix For: 1.1
>  Attachments: geronimo_shutdown_stdout.txt
>
> Can anyone reproduce this problem on other platforms?
> If I start the tomcat build of the release candidate and then shut it down 
> once the startup has completed it shuts down almost cleanly:
> Server shutdown begun  
> 11:25:47,951 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8443
> 11:25:48,986 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8080
> 11:25:49,001 INFO  [StandardContext] Container 
> org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not 
> been started
> Server shutdown completed
> I have shutdown issues If I do the following:
> * start the tomcat build of release candidate using geronimo.sh run --long
> * connect to the daytrader web app
> *  populate the daytrader database via the daytrader configuration page
> * log into daytrader and view account, portfolio etc.
> * press ctrl-C in the window that geronimo was started in to shut it down.  
> * You will see ActiveMQAsfEndpointWorker messages every 30 seconds.  
> I will attach a capture of stdout also including a thread dump to this issue.

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

Shutdown problems encountered on 1.0 RC

I have encountered some Geronimo shutdown issues with ActiveMQ on the 
1.0 release candidate on Solaris 10 x86 under VMWare.


Can anyone else reproduce this issue (see GERONIMO-1422 for details) on 
other OSes?

RELEASE-NOTES-1.0.txt

2006-01-05 Thread Ken Perl

Is the slash after the word deploy in the file RELEASE-NOTES-1.0.txt intended?

 * Hot Deploy by copying your deployment artifact to the deploy/
   directory

--
perl -e 'print unpack(u,"62V5N\"FME;G\!E

[jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds

2006-01-05 Thread anita kulshreshtha (JIRA)

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

anita kulshreshtha updated GERONIMO-1422:
-

Attachment: shutdown.txt

I am seeing the same on win XP when -
* start using java -jar 
* connect to the daytrader web app
* populate the daytrader database via the daytrader configuration 
page
 * log into daytrader with uid:0 .
> * press ctrl-C in the window that geronimo was started in to shut it 
down.  

> Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect 
> endpoints to broker every 30 seconds
> 
>
>  Key: GERONIMO-1422
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1422
>  Project: Geronimo
> Type: Bug
>   Components: ActiveMQ
> Versions: 1.0
>  Environment: Solaris 10 x86 under VMWare player 1.01
> Java 1.4.2_10
> tomcat build of geronimo
> Reporter: John Sisson
>  Fix For: 1.1
>  Attachments: geronimo_shutdown_stdout.txt, shutdown.txt
>
> Can anyone reproduce this problem on other platforms?
> If I start the tomcat build of the release candidate and then shut it down 
> once the startup has completed it shuts down almost cleanly:
> Server shutdown begun  
> 11:25:47,951 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8443
> 11:25:48,986 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8080
> 11:25:49,001 INFO  [StandardContext] Container 
> org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not 
> been started
> Server shutdown completed
> I have shutdown issues If I do the following:
> * start the tomcat build of release candidate using geronimo.sh run --long
> * connect to the daytrader web app
> *  populate the daytrader database via the daytrader configuration page
> * log into daytrader and view account, portfolio etc.
> * press ctrl-C in the window that geronimo was started in to shut it down.  
> * You will see ActiveMQAsfEndpointWorker messages every 30 seconds.  
> I will attach a capture of stdout also including a thread dump to this issue.

-- 
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: svn commit: r366389 - in /geronimo/site: docs/downloads.html xdocs/downloads.xml

We should mention in the download information that the installer isn't 
available in this release and will be available in the upcoming 1.0.1 
release.


Thanks,

John

Re: Geronimo 2.0


Bruce Snyder wrote:


On 1/5/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:

 


How do we want to stage this effort in terms of SVN organization?  When
should we cut a 2.0 development branch?
   


I suppose that the JEE 5 work would be best suited to a 2.0 branch.
That means that there is a potential to have to do a lot of double
work. What I mean to say is that any new innovations being committed
to the HEAD will need to be refactored and committed to the 2.0
branch. And this work will increase more with the addition of more
branches (e.g., 1.1, 1.2, etc.).
 


You touched on the concern that I had.  I'm thinking that once we cut
this, there will be no further work on 1.x, because everyone will want
to work on 2.x.
   



Then we should probably consider making a decision that the HEAD
should contain 2.x work only. If any fixes need to be done to the 1.x
code then proper branching and tagging should occur to facilitate that
work.

 


I agree we don't want too many branches.

Will fixes for the 1.0.1 release (hopefully we can get out in a few 
weeks) be committed to the 1.0 branch and then we create another tag for 
the 1.0.1 release?


My thoughts..

Do we have any guesstimates on when we would have JEE 5 development 
completed? 

How long it will be before we can deliver a release with some 
innovations in it, since we previously agreed we want to release 
frequently? 

If this is going to be a while then we should discuss the work that is 
planned for the near future and whether there are enhancements that can 
be delivered in a releases before JEE 5, and if so, how that could be 
managed. 

Could some of the planned enhancements impact the stability of head 
development and therefore should be done in a branch? E.G. would we have 
stability problems doing JEE 5 development, re-arch of security, maven 1 
to maven 2 migration, xbean support, corba impl etc. all in head?


John


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

ANNOUNCE Geronimo Version 1.0 Available for Download

2006-01-05 Thread Matt Hogstrom

The Apache Geronimo team is proud to announce the availability of Geronimo 
Version 1.0 for immediate download.  Please visit 
http://geronimo.apache.org/downloads.html.


The release has passed all J2EE 1.4 Certification Tests.  In addition, many 
thanks to our community and volunteers that have tested Geronimo on many 
operating systems including Linux, Windows, MacOS and zLinux as well as many 
hardware platforms.


Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for Java 
Business Integration (JBI), Jetty or Tomcat Web container deployment options, a 
complete Web-enabled management console based on Java Portlets, full integration 
with the Eclipse Web Tools Project, and integration of Apache Derby and the 
Apache Directory Server.


Included in this e-mail are relevant sections from the RELEASE-NOTES which can 
be found in the distributions that are available for download.  For up to the 
minute Release Notes and information you can check the Geronimo home page at 
http://geronimo.apache.org.


===

Release Notes -- Apache Geronimo -- Version 1.0

Geronimo URLs
-
Home Page: http://geronimo.apache.org/
Downloads: http://geronimo.apache.org/downloads.html
Documentation: http://geronimo.apache.org/documentation.html
Mailing Lists: http://geronimo.apache.org/mailing.html
Source Code:   http://geronimo.apache.org/svn.html
Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
Wiki:  http://wiki.apache.org/geronimo


System Requirements
---
You need a platform that supports the Sun JDK 1.4.2.  CORBA
support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08
or a higher 1.4.2_* release).

Most testing has been done on Linux, Mac OS X, and Windows.


Installing & Starting Geronimo
--
To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
containing Geronimo.

Documentation is included in the docs directory in your unpacked server.

If you wish to modify the default ports that
Geronimo will use, edit the file var/config/config.xml in your
Geronimo directory.

Geronimo comes with batch and script files to control server start
and stop functions.  To see usage examples simply type geronimo.bat
or geronimo.sh command as appropriate for your platform.  It is
necessary to set JAVA_HOME to the copy of your Sun 1.4.2 JDK/JRE
prior to executing the command.  Here is an example:

export JAVA_HOME=/directory_to_the_JRE/
bin/geronimo.sh

The command will display help text instructing you as to how to start
and stop the Geronimo server.

If you prefer to start the server without a script file you can simply type:

java -jar bin/server.jar

Once the server has started, you can access the administration console
at http://localhost:8080/console/ . The default user name is "system" and
the default password is "manager".


Administration Console Security Configuration
-
The default administration user/password for the admin console and
deployment is system/manager.  To change this edit the
var/security/users.properties and var/security/groups.properties
files.

Future Road Map at a Glance
---
http://issues.apache.org/jira/browse/GERONIMO?
  report=com.atlassian.jira.plugin.system.project:roadmap-panel

  (the above URL must be all on one line)


Late Release News (not in RELEASE-NOTES-1.0.txt in build)
-
Just as the Geronimo Release was being prepared a report was made about a
potential security issue when using the Jetty Web Conatiner.  The issue was 
noted
on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to access 
the
contents of a WEB-INF directory if the server is running on a Windows platform.
This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 which 
will

be available in the near future.


Significant Changes Since the M5 Release

 * the ConfigID format has been updated in anticipatation of future
   enhancements.  Application plans that include configIds of
   configurations included in Geronimo M5 and earlier will require
   modifications.  See the Wiki at http://wiki.apache.org/geronimo
   for more information.
 * More functionality and new look and feel for the Administrative
   Console (http://localhost:8080/console/)
 * Added HTTP session clustering to the Tomcat configuration
   included with Geronimo
 * Hot Deploy by copying your deployment artifact to the deploy/
   directory
 * Ability to run the deploy tool from a machine other than the
   application server (remote deployment)
 * Packages that represented experimental, pre-release or obsolete
   versions were removed.
 * Clustering
   - Tomcat support for clustering is available in this release.
   - WADI has been included as a technology preview for both Jetty
 and Tomcat.  See http://wadi.codehaus.org for additional
 infor

Re: ANNOUNCE Geronimo Version 1.0 Available for Download

2006-01-05 Thread Davanum Srinivas

Congrats

-- dims

On 1/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> The Apache Geronimo team is proud to announce the availability of Geronimo
> Version 1.0 for immediate download.  Please visit
> http://geronimo.apache.org/downloads.html.
>
> The release has passed all J2EE 1.4 Certification Tests.  In addition, many
> thanks to our community and volunteers that have tested Geronimo on many
> operating systems including Linux, Windows, MacOS and zLinux as well as many
> hardware platforms.
>
> Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for 
> Java
> Business Integration (JBI), Jetty or Tomcat Web container deployment options, 
> a
> complete Web-enabled management console based on Java Portlets, full 
> integration
> with the Eclipse Web Tools Project, and integration of Apache Derby and the
> Apache Directory Server.
>
> Included in this e-mail are relevant sections from the RELEASE-NOTES which can
> be found in the distributions that are available for download.  For up to the
> minute Release Notes and information you can check the Geronimo home page at
> http://geronimo.apache.org.
>
> ===
>
> Release Notes -- Apache Geronimo -- Version 1.0
>
> Geronimo URLs
> -
> Home Page: http://geronimo.apache.org/
> Downloads: http://geronimo.apache.org/downloads.html
> Documentation: http://geronimo.apache.org/documentation.html
> Mailing Lists: http://geronimo.apache.org/mailing.html
> Source Code:   http://geronimo.apache.org/svn.html
> Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
> Wiki:  http://wiki.apache.org/geronimo
>
>
> System Requirements
> ---
> You need a platform that supports the Sun JDK 1.4.2.  CORBA
> support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08
> or a higher 1.4.2_* release).
>
> Most testing has been done on Linux, Mac OS X, and Windows.
>
>
> Installing & Starting Geronimo
> --
> To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
> containing Geronimo.
>
> Documentation is included in the docs directory in your unpacked server.
>
> If you wish to modify the default ports that
> Geronimo will use, edit the file var/config/config.xml in your
> Geronimo directory.
>
> Geronimo comes with batch and script files to control server start
> and stop functions.  To see usage examples simply type geronimo.bat
> or geronimo.sh command as appropriate for your platform.  It is
> necessary to set JAVA_HOME to the copy of your Sun 1.4.2 JDK/JRE
> prior to executing the command.  Here is an example:
>
> export JAVA_HOME=/directory_to_the_JRE/
> bin/geronimo.sh
>
> The command will display help text instructing you as to how to start
> and stop the Geronimo server.
>
> If you prefer to start the server without a script file you can simply type:
>
> java -jar bin/server.jar
>
> Once the server has started, you can access the administration console
> at http://localhost:8080/console/ . The default user name is "system" and
> the default password is "manager".
>
>
> Administration Console Security Configuration
> -
> The default administration user/password for the admin console and
> deployment is system/manager.  To change this edit the
> var/security/users.properties and var/security/groups.properties
> files.
>
> Future Road Map at a Glance
> ---
> http://issues.apache.org/jira/browse/GERONIMO?
>report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
>(the above URL must be all on one line)
>
>
> Late Release News (not in RELEASE-NOTES-1.0.txt in build)
> -
> Just as the Geronimo Release was being prepared a report was made about a
> potential security issue when using the Jetty Web Conatiner.  The issue was 
> noted
> on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to 
> access the
> contents of a WEB-INF directory if the server is running on a Windows 
> platform.
> This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1 
> which
> will
> be available in the near future.
>
>
> Significant Changes Since the M5 Release
> 
>   * the ConfigID format has been updated in anticipatation of future
> enhancements.  Application plans that include configIds of
> configurations included in Geronimo M5 and earlier will require
> modifications.  See the Wiki at http://wiki.apache.org/geronimo
> for more information.
>   * More functionality and new look and feel for the Administrative
> Console (http://localhost:8080/console/)
>   * Added HTTP session clustering to the Tomcat configuration
> included with Geronimo
>   * Hot Deploy by copying your deployment artifact to the deploy/
> directory
>   * Ability to run the deploy tool from a machine other than the
> application server (remote deployment)
>   * Pac

Re: ANNOUNCE Geronimo Version 1.0 Available for Download

2006-01-05 Thread Erin Mulder

Matt Hogstrom wrote:
> The Apache Geronimo team is proud to announce the availability of
> Geronimo Version 1.0 for immediate download.  Please visit
> http://geronimo.apache.org/downloads.html.

CONGRATULATIONS

Cheers,
Erin

Re: ANNOUNCE Geronimo Version 1.0 Available for Download

Great work to the team...especially Matt for taking a beating getting us
here.  This was a long hard roadand important milestone.  Special
thanks to *everyone* in the community for helping to test this and find
the hidden nasties.

Jeff

Matt Hogstrom wrote:
> The Apache Geronimo team is proud to announce the availability of
> Geronimo Version 1.0 for immediate download.  Please visit
> http://geronimo.apache.org/downloads.html.
> 
> The release has passed all J2EE 1.4 Certification Tests.  In addition,
> many thanks to our community and volunteers that have tested Geronimo on
> many operating systems including Linux, Windows, MacOS and zLinux as
> well as many hardware platforms.
> 
> Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support
> for Java Business Integration (JBI), Jetty or Tomcat Web container
> deployment options, a complete Web-enabled management console based on
> Java Portlets, full integration with the Eclipse Web Tools Project, and
> integration of Apache Derby and the Apache Directory Server.
> 
> Included in this e-mail are relevant sections from the RELEASE-NOTES
> which can be found in the distributions that are available for
> download.  For up to the minute Release Notes and information you can
> check the Geronimo home page at http://geronimo.apache.org.
> 
> ===
> 
> Release Notes -- Apache Geronimo -- Version 1.0
> 
> Geronimo URLs
> -
> Home Page: http://geronimo.apache.org/
> Downloads: http://geronimo.apache.org/downloads.html
> Documentation: http://geronimo.apache.org/documentation.html
> Mailing Lists: http://geronimo.apache.org/mailing.html
> Source Code:   http://geronimo.apache.org/svn.html
> Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
> Wiki:  http://wiki.apache.org/geronimo
> 
> 
> System Requirements
> ---
> You need a platform that supports the Sun JDK 1.4.2.  CORBA
> support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08
> or a higher 1.4.2_* release).
> 
> Most testing has been done on Linux, Mac OS X, and Windows.
> 
> 
> Installing & Starting Geronimo
> --
> To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
> containing Geronimo.
> 
> Documentation is included in the docs directory in your unpacked server.
> 
> If you wish to modify the default ports that
> Geronimo will use, edit the file var/config/config.xml in your
> Geronimo directory.
> 
> Geronimo comes with batch and script files to control server start
> and stop functions.  To see usage examples simply type geronimo.bat
> or geronimo.sh command as appropriate for your platform.  It is
> necessary to set JAVA_HOME to the copy of your Sun 1.4.2 JDK/JRE
> prior to executing the command.  Here is an example:
> 
> export JAVA_HOME=/directory_to_the_JRE/
> bin/geronimo.sh
> 
> The command will display help text instructing you as to how to start
> and stop the Geronimo server.
> 
> If you prefer to start the server without a script file you can simply
> type:
> 
> java -jar bin/server.jar
> 
> Once the server has started, you can access the administration console
> at http://localhost:8080/console/ . The default user name is "system" and
> the default password is "manager".
> 
> 
> Administration Console Security Configuration
> -
> The default administration user/password for the admin console and
> deployment is system/manager.  To change this edit the
> var/security/users.properties and var/security/groups.properties
> files.
> 
> Future Road Map at a Glance
> ---
> http://issues.apache.org/jira/browse/GERONIMO?
>   report=com.atlassian.jira.plugin.system.project:roadmap-panel
> 
>   (the above URL must be all on one line)
> 
> 
> Late Release News (not in RELEASE-NOTES-1.0.txt in build)
> -
> Just as the Geronimo Release was being prepared a report was made about a
> potential security issue when using the Jetty Web Conatiner.  The issue
> was noted
> on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to
> access the
> contents of a WEB-INF directory if the server is running on a Windows
> platform.
> This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo
> 1.0.1 which will
> be available in the near future.
> 
> 
> Significant Changes Since the M5 Release
> 
>  * the ConfigID format has been updated in anticipatation of future
>enhancements.  Application plans that include configIds of
>configurations included in Geronimo M5 and earlier will require
>modifications.  See the Wiki at http://wiki.apache.org/geronimo
>for more information.
>  * More functionality and new look and feel for the Administrative
>Console (http://localhost:8080/console/)
>  * Added HTTP session clustering to the Tomcat configuration
>included with Geronimo
>  * Hot Deploy by

Re: ANNOUNCE Geronimo Version 1.0 Available for Download

2006-01-05 Thread Dan Diephouse


Awesome work guys. This is a great accomplishment!
- Dan

Matt Hogstrom wrote:
The Apache Geronimo team is proud to announce the availability of 
Geronimo Version 1.0 for immediate download.  Please visit 
http://geronimo.apache.org/downloads.html.


The release has passed all J2EE 1.4 Certification Tests.  In addition, 
many thanks to our community and volunteers that have tested Geronimo 
on many operating systems including Linux, Windows, MacOS and zLinux 
as well as many hardware platforms.


Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, 
support for Java Business Integration (JBI), Jetty or Tomcat Web 
container deployment options, a complete Web-enabled management 
console based on Java Portlets, full integration with the Eclipse Web 
Tools Project, and integration of Apache Derby and the Apache 
Directory Server.


Included in this e-mail are relevant sections from the RELEASE-NOTES 
which can be found in the distributions that are available for 
download.  For up to the minute Release Notes and information you can 
check the Geronimo home page at http://geronimo.apache.org.


===

Release Notes -- Apache Geronimo -- Version 1.0

Geronimo URLs
-
Home Page: http://geronimo.apache.org/
Downloads: http://geronimo.apache.org/downloads.html
Documentation: http://geronimo.apache.org/documentation.html
Mailing Lists: http://geronimo.apache.org/mailing.html
Source Code:   http://geronimo.apache.org/svn.html
Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
Wiki:  http://wiki.apache.org/geronimo


System Requirements
---
You need a platform that supports the Sun JDK 1.4.2.  CORBA
support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08
or a higher 1.4.2_* release).

Most testing has been done on Linux, Mac OS X, and Windows.


Installing & Starting Geronimo
--
To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
containing Geronimo.

Documentation is included in the docs directory in your unpacked server.

If you wish to modify the default ports that
Geronimo will use, edit the file var/config/config.xml in your
Geronimo directory.

Geronimo comes with batch and script files to control server start
and stop functions.  To see usage examples simply type geronimo.bat
or geronimo.sh command as appropriate for your platform.  It is
necessary to set JAVA_HOME to the copy of your Sun 1.4.2 JDK/JRE
prior to executing the command.  Here is an example:

export JAVA_HOME=/directory_to_the_JRE/
bin/geronimo.sh

The command will display help text instructing you as to how to start
and stop the Geronimo server.

If you prefer to start the server without a script file you can simply 
type:


java -jar bin/server.jar

Once the server has started, you can access the administration console
at http://localhost:8080/console/ . The default user name is "system" and
the default password is "manager".


Administration Console Security Configuration
-
The default administration user/password for the admin console and
deployment is system/manager.  To change this edit the
var/security/users.properties and var/security/groups.properties
files.

Future Road Map at a Glance
---
http://issues.apache.org/jira/browse/GERONIMO?
  report=com.atlassian.jira.plugin.system.project:roadmap-panel

  (the above URL must be all on one line)


Late Release News (not in RELEASE-NOTES-1.0.txt in build)
-
Just as the Geronimo Release was being prepared a report was made about a
potential security issue when using the Jetty Web Conatiner.  The 
issue was noted
on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL 
to access the
contents of a WEB-INF directory if the server is running on a Windows 
platform.
This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 
1.0.1 which will

be available in the near future.


Significant Changes Since the M5 Release

 * the ConfigID format has been updated in anticipatation of future
   enhancements.  Application plans that include configIds of
   configurations included in Geronimo M5 and earlier will require
   modifications.  See the Wiki at http://wiki.apache.org/geronimo
   for more information.
 * More functionality and new look and feel for the Administrative
   Console (http://localhost:8080/console/)
 * Added HTTP session clustering to the Tomcat configuration
   included with Geronimo
 * Hot Deploy by copying your deployment artifact to the deploy/
   directory
 * Ability to run the deploy tool from a machine other than the
   application server (remote deployment)
 * Packages that represented experimental, pre-release or obsolete
   versions were removed.
 * Clustering
   - Tomcat support for clustering is available in this release.
   - WADI has been included as a technology preview for

RE: ANNOUNCE Geronimo Version 1.0 Available for Download

2006-01-05 Thread Christopher Chan

Congrats and nice work to all!!

-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 05, 2006 6:18 PM
To: dev@geronimo.apache.org; user@geronimo.apache.org; [EMAIL PROTECTED]
Subject: ANNOUNCE Geronimo Version 1.0 Available for Download

The Apache Geronimo team is proud to announce the availability of Geronimo 
Version 1.0 for immediate download.  Please visit 
http://geronimo.apache.org/downloads.html.

The release has passed all J2EE 1.4 Certification Tests.  In addition, many 
thanks to our community and volunteers that have tested Geronimo on many 
operating systems including Linux, Windows, MacOS and zLinux as well as many

hardware platforms.

Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for
Java 
Business Integration (JBI), Jetty or Tomcat Web container deployment
options, a 
complete Web-enabled management console based on Java Portlets, full
integration 
with the Eclipse Web Tools Project, and integration of Apache Derby and the 
Apache Directory Server.

Included in this e-mail are relevant sections from the RELEASE-NOTES which
can 
be found in the distributions that are available for download.  For up to
the 
minute Release Notes and information you can check the Geronimo home page at

http://geronimo.apache.org.

===

Release Notes -- Apache Geronimo -- Version 1.0

Geronimo URLs
-
Home Page: http://geronimo.apache.org/
Downloads: http://geronimo.apache.org/downloads.html
Documentation: http://geronimo.apache.org/documentation.html
Mailing Lists: http://geronimo.apache.org/mailing.html
Source Code:   http://geronimo.apache.org/svn.html
Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
Wiki:  http://wiki.apache.org/geronimo

System Requirements
---
You need a platform that supports the Sun JDK 1.4.2.  CORBA
support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08
or a higher 1.4.2_* release).

Most testing has been done on Linux, Mac OS X, and Windows.

Installing & Starting Geronimo
--
To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
containing Geronimo.

Documentation is included in the docs directory in your unpacked server.

If you wish to modify the default ports that
Geronimo will use, edit the file var/config/config.xml in your
Geronimo directory.

Geronimo comes with batch and script files to control server start
and stop functions.  To see usage examples simply type geronimo.bat
or geronimo.sh command as appropriate for your platform.  It is
necessary to set JAVA_HOME to the copy of your Sun 1.4.2 JDK/JRE
prior to executing the command.  Here is an example:

export JAVA_HOME=/directory_to_the_JRE/
bin/geronimo.sh

The command will display help text instructing you as to how to start
and stop the Geronimo server.

If you prefer to start the server without a script file you can simply type:

java -jar bin/server.jar

Once the server has started, you can access the administration console
at http://localhost:8080/console/ . The default user name is "system" and
the default password is "manager".

Administration Console Security Configuration
-
The default administration user/password for the admin console and
deployment is system/manager.  To change this edit the
var/security/users.properties and var/security/groups.properties
files.

Future Road Map at a Glance
---
http://issues.apache.org/jira/browse/GERONIMO?
   report=com.atlassian.jira.plugin.system.project:roadmap-panel

   (the above URL must be all on one line)

Late Release News (not in RELEASE-NOTES-1.0.txt in build)
-
Just as the Geronimo Release was being prepared a report was made about a
potential security issue when using the Jetty Web Conatiner.  The issue was
noted
on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to
access the
contents of a WEB-INF directory if the server is running on a Windows
platform.
This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1
which 
will
be available in the near future.

Significant Changes Since the M5 Release

  * the ConfigID format has been updated in anticipatation of future
enhancements.  Application plans that include configIds of
configurations included in Geronimo M5 and earlier will require
modifications.  See the Wiki at http://wiki.apache.org/geronimo
for more information.
  * More functionality and new look and feel for the Administrative
Console (http://localhost:8080/console/)
  * Added HTTP session clustering to the Tomcat configuration
included with Geronimo
  * Hot Deploy by copying your deployment artifact to the deploy/
directory
  * Ability to run the deploy tool from a machine other than the
application server (remote deployment)
  * Packages that r

Re: ANNOUNCE Geronimo Version 1.0 Available for Download

2006-01-05 Thread Ken Perl

really good news, but the release notes link is broken.

On 1/6/06, Christopher Chan <[EMAIL PROTECTED]> wrote:
> Congrats and nice work to all!!
>
> -Original Message-
> From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 05, 2006 6:18 PM
> To: dev@geronimo.apache.org; user@geronimo.apache.org; [EMAIL PROTECTED]
> Subject: ANNOUNCE Geronimo Version 1.0 Available for Download
>
> The Apache Geronimo team is proud to announce the availability of Geronimo
> Version 1.0 for immediate download.  Please visit
> http://geronimo.apache.org/downloads.html.
>
> The release has passed all J2EE 1.4 Certification Tests.  In addition, many
> thanks to our community and volunteers that have tested Geronimo on many
> operating systems including Linux, Windows, MacOS and zLinux as well as many
>
> hardware platforms.
>
> Apache Geronimo 1.0 introduces complete J2EE 1.4 certification, support for
> Java
> Business Integration (JBI), Jetty or Tomcat Web container deployment
> options, a
> complete Web-enabled management console based on Java Portlets, full
> integration
> with the Eclipse Web Tools Project, and integration of Apache Derby and the
> Apache Directory Server.
>
> Included in this e-mail are relevant sections from the RELEASE-NOTES which
> can
> be found in the distributions that are available for download.  For up to
> the
> minute Release Notes and information you can check the Geronimo home page at
>
> http://geronimo.apache.org.
>
> ===
>
> Release Notes -- Apache Geronimo -- Version 1.0
>
> Geronimo URLs
> -
> Home Page: http://geronimo.apache.org/
> Downloads: http://geronimo.apache.org/downloads.html
> Documentation: http://geronimo.apache.org/documentation.html
> Mailing Lists: http://geronimo.apache.org/mailing.html
> Source Code:   http://geronimo.apache.org/svn.html
> Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
> Wiki:  http://wiki.apache.org/geronimo
>
>
> System Requirements
> ---
> You need a platform that supports the Sun JDK 1.4.2.  CORBA
> support requires a Sun Java 1.4.2 VM (specifically 1.4.2_08
> or a higher 1.4.2_* release).
>
> Most testing has been done on Linux, Mac OS X, and Windows.
>
>
> Installing & Starting Geronimo
> --
> To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
> containing Geronimo.
>
> Documentation is included in the docs directory in your unpacked server.
>
> If you wish to modify the default ports that
> Geronimo will use, edit the file var/config/config.xml in your
> Geronimo directory.
>
> Geronimo comes with batch and script files to control server start
> and stop functions.  To see usage examples simply type geronimo.bat
> or geronimo.sh command as appropriate for your platform.  It is
> necessary to set JAVA_HOME to the copy of your Sun 1.4.2 JDK/JRE
> prior to executing the command.  Here is an example:
>
> export JAVA_HOME=/directory_to_the_JRE/
> bin/geronimo.sh
>
> The command will display help text instructing you as to how to start
> and stop the Geronimo server.
>
> If you prefer to start the server without a script file you can simply type:
>
> java -jar bin/server.jar
>
> Once the server has started, you can access the administration console
> at http://localhost:8080/console/ . The default user name is "system" and
> the default password is "manager".
>
>
> Administration Console Security Configuration
> -
> The default administration user/password for the admin console and
> deployment is system/manager.  To change this edit the
> var/security/users.properties and var/security/groups.properties
> files.
>
> Future Road Map at a Glance
> ---
> http://issues.apache.org/jira/browse/GERONIMO?
>report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
>(the above URL must be all on one line)
>
>
> Late Release News (not in RELEASE-NOTES-1.0.txt in build)
> -
> Just as the Geronimo Release was being prepared a report was made about a
> potential security issue when using the Jetty Web Conatiner.  The issue was
> noted
> on Jetty 5.1.9 which used by geronimo 1.0, which allows a crafted URL to
> access the
> contents of a WEB-INF directory if the server is running on a Windows
> platform.
> This issue is fixed in Jetty 5.1.10 and will be provided in Geronimo 1.0.1
> which
> will
> be available in the near future.
>
>
> Significant Changes Since the M5 Release
> 
>   * the ConfigID format has been updated in anticipatation of future
> enhancements.  Application plans that include configIds of
> configurations included in Geronimo M5 and earlier will require
> modifications.  See the Wiki at http://wiki.apache.org/geronimo
> for more information.
>   * More functionality and new look and feel for the Administrative
> Console

Re: ANNOUNCE Geronimo Version 1.0 Available for Download