Please update the road map

[Bruce Snyder <br...@gmail.com>]

This is just a quick note to ask everyone to please take a few moments
to update the road map on the wiki:

http://wiki.apache.org/geronimo/RoadMap

It would really help the community if this page was updated to better
reflect the current status of the project.

Thanks! 

Bruce 
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

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

Re: New Tomcat Changes

[Jeff Genender <jg...@savoirtech.com>]

Jacek,

IMHO, the following is required to finish up Tomcat...

1) The Context GBean object (should be a no brainer).  This is a
placeholder descriptor for predeclaring a Tomcat Context in our plan
(similar to the server.xml).  Then when deploying the TomcatContext
through the deployer, the TomcatContainer will need to marry-up the
deployment with the predeclared Context.

2) The Valve GBean (Another no brainer).  This will allow us to declare
Valves in the plan and have it placed at the (IIRC) Engine, Host, and
Context levels.  This is a near copy of the Engine and Host GBeans, with a
few dependency modifications.

3) A nice default ROOT context that shows a pretty Geronimo/Tomcat web
page, so it does not have a default view of the Catalina configuration
which could be a security issue. (This is a call for any of you Web
layout/ Graphics gurus to produce a polished Geronimo/Tomcat page).

4) Much needed additional unit tests for the deployer and tomcat modules. 
I have manually tested many items (such as SSL), but it would be nice to
have these as unit tests.  The current unit tests apply to JAAS, JACC,
Standard Tomcat execution, and generic deployment.  I would love to see
some more transaction, inital context, root context and JNDI, and virtual
host tests.

5) Clustering?  We could write GBeans to use Tomcat clustering, but I
think that Application Server based clustering is much more appropriate,
so I think this can probably be placed on the back-burner.

Other than this, IMHO, it is pretty much complete.

I can handle 1 and 2...and will probably have these done this week.  I can
use some help on 3 and 4...and get comments on 5.

Also, it would be great to get folks pounding on the Tomcat module and see
what bugs we may have.

Thanks,

Jeff

> Jeff Genender wrote:
>> I have made some major changes to the Tomcat module that makes it much
>> more viable in Geronimo.
>
> Wow! Excellent! The list of changes is very impressive. I wish I had
> helped you in them.
>
> What do you envision is yet necessary to have Tomcat fully integrated?
>
>> Jeff
>
> Jacek
>

Re: New Tomcat Changes

[Jacek Laskowski <jl...@apache.org>]

Jeff Genender wrote:
> I have made some major changes to the Tomcat module that makes it much 
> more viable in Geronimo.

Wow! Excellent! The list of changes is very impressive. I wish I had 
helped you in them.

What do you envision is yet necessary to have Tomcat fully integrated?

> Jeff

Jacek

Re: New Tomcat Changes

[Jeff Genender <jg...@savoirtech.com>]

Good point about JACC.  IIRC, the only requirement for JACC was that is 
if we are to support virtual hosting, the contexts must be unique.  This 
may require that we add the host name to the policy context id if the 
virtual host identifier is used.

David Jencks wrote:
> 
> On Apr 25, 2005, at 4:07 PM, Jeff Genender wrote:
> 
>> I am not sure if we are utilizing this for Jetty...I didn't see a 
>> virtual-server style parameter in the geronimo-jetty.xsd.  Perhaps it 
>> is somewhere else...which leads me to a discussion we have had in the 
>> past...
> 
> 
> I think jetty supports virtual hosts but we haven't implemented support 
> for it in the geronimo integration.  I can never remember what they are 
> :-( but if you remind me I might be able to suggest how to do it.
> 
>>
>> I would very much be interested in taking the geronimo-jetty.xml and 
>> geronimo-tomcat.xml files and merge them as a common version, such as 
>> a geronimo-web.xml...and remove the jetty namespace attributes from 
>> the xsd.  This way both containers can surf off the same file....and 
>> reuse the xmlbean code. I did not see anything in the xds that was 
>> container specific.  If anything is container specific, the builder 
>> could ignore the parameter.
> 
> 
> +100.  I don't think there is anything jetty specific in the jetty 
> module builder.  If you can figure out how to add vhost support that can 
> continue to be the case :-)
> 
> Were there some JACC requirements about contextID and virtual hosts?
> 
> thanks
> david jencks
> 
>>
>> Thoughts?
>>
>>
>> Jeremy Boynes wrote:
>>
>>> Jeff Genender wrote:
>>>
>>>>
>>>> I also added a Tomcat Builder so we will no longer rely on the Jetty 
>>>> version.  The main reason for this is that Tomcat supports virtual 
>>>> hosts (declared by additional HostGBean objects in the plan).  The 
>>>> web applications can now include a geronimo-tomcat.xml file in the 
>>>> WEB-INF file which is very similar to the Jetty version.  The only 
>>>> difference is support for the <virtual-server> parameter.  This 
>>>> allows you to deploy your web application to a specific virtual host.
>>>>
>>> IIRC Jetty has this function as well - can we merge the vhost changes 
>>> back into the jetty-builder?
>>> -- 
>>> Jeremy
>>
>>

Re: New Tomcat Changes

[David Jencks <da...@yahoo.com>]

On Apr 25, 2005, at 4:07 PM, Jeff Genender wrote:

> I am not sure if we are utilizing this for Jetty...I didn't see a 
> virtual-server style parameter in the geronimo-jetty.xsd.  Perhaps it 
> is somewhere else...which leads me to a discussion we have had in the 
> past...

I think jetty supports virtual hosts but we haven't implemented support 
for it in the geronimo integration.  I can never remember what they are 
:-( but if you remind me I might be able to suggest how to do it.
>
> I would very much be interested in taking the geronimo-jetty.xml and 
> geronimo-tomcat.xml files and merge them as a common version, such as 
> a geronimo-web.xml...and remove the jetty namespace attributes from 
> the xsd.  This way both containers can surf off the same file....and 
> reuse the xmlbean code. I did not see anything in the xds that was 
> container specific.  If anything is container specific, the builder 
> could ignore the parameter.

+100.  I don't think there is anything jetty specific in the jetty 
module builder.  If you can figure out how to add vhost support that 
can continue to be the case :-)

Were there some JACC requirements about contextID and virtual hosts?

thanks
david jencks

>
> Thoughts?
>
>
> Jeremy Boynes wrote:
>> Jeff Genender wrote:
>>>
>>> I also added a Tomcat Builder so we will no longer rely on the Jetty 
>>> version.  The main reason for this is that Tomcat supports virtual 
>>> hosts (declared by additional HostGBean objects in the plan).  The 
>>> web applications can now include a geronimo-tomcat.xml file in the 
>>> WEB-INF file which is very similar to the Jetty version.  The only 
>>> difference is support for the <virtual-server> parameter.  This 
>>> allows you to deploy your web application to a specific virtual 
>>> host.
>>>
>> IIRC Jetty has this function as well - can we merge the vhost changes 
>> back into the jetty-builder?
>> -- 
>> Jeremy
>

Re: New Tomcat Changes

[Jeff Genender <jg...@savoirtech.com>]

I am not sure if we are utilizing this for Jetty...I didn't see a 
virtual-server style parameter in the geronimo-jetty.xsd.  Perhaps it is 
somewhere else...which leads me to a discussion we have had in the past...

I would very much be interested in taking the geronimo-jetty.xml and 
geronimo-tomcat.xml files and merge them as a common version, such as a 
geronimo-web.xml...and remove the jetty namespace attributes from the 
xsd.  This way both containers can surf off the same file....and reuse 
the xmlbean code. I did not see anything in the xds that was container 
specific.  If anything is container specific, the builder could ignore 
the parameter.

Thoughts?


Jeremy Boynes wrote:
> Jeff Genender wrote:
> 
>>
>> I also added a Tomcat Builder so we will no longer rely on the Jetty 
>> version.  The main reason for this is that Tomcat supports virtual 
>> hosts (declared by additional HostGBean objects in the plan).  The web 
>> applications can now include a geronimo-tomcat.xml file in the WEB-INF 
>> file which is very similar to the Jetty version.  The only difference 
>> is support for the <virtual-server> parameter.  This allows you to 
>> deploy your web application to a specific virtual host.
>>
> 
> IIRC Jetty has this function as well - can we merge the vhost changes 
> back into the jetty-builder?
> 
> -- 
> Jeremy

Re: New Tomcat Changes

[Jeremy Boynes <jb...@apache.org>]

Jeff Genender wrote:
> 
> I also added a Tomcat Builder so we will no longer rely on the Jetty 
> version.  The main reason for this is that Tomcat supports virtual hosts 
> (declared by additional HostGBean objects in the plan).  The web 
> applications can now include a geronimo-tomcat.xml file in the WEB-INF 
> file which is very similar to the Jetty version.  The only difference is 
> support for the <virtual-server> parameter.  This allows you to deploy 
> your web application to a specific virtual host.
> 

IIRC Jetty has this function as well - can we merge the vhost changes 
back into the jetty-builder?

--
Jeremy

New Tomcat Changes

[Jeff Genender <jg...@savoirtech.com>]

I have made some major changes to the Tomcat module that makes it much 
more viable in Geronimo.  I will briefly explain them in this email, but 
will update the Wiki with the detail.

The biggest changes are the support for the Engine, Host, Realm, and 
Connector objects.  I have created GBean wrappers around these Tomcat 
objects, and provided for dependencies between them which follows the 
Tomcat rules for these objects.

This means there is no need for a server.xml file.  The equivalent of 
this file is the j2ee-server-tomcat.xml plan.  Its layout is similar to 
the server.xml from a dependency perspective, file where, we have our 
container (service), and dependencies with the engine and host gbeans. 
The realm gbean can be applied at the engine and host level.  This 
allows Tomcat to declaritively use the Geronimo security model with JAAS 
or JACC.  There are 2 realms that must be used if you wish to use JAAS 
or JAAC.  This is the TomcatJAASRealm (for JAAS) or TomcatGeronimoRealm 
(for JACC).

I also added a Tomcat Builder so we will no longer rely on the Jetty 
version.  The main reason for this is that Tomcat supports virtual hosts 
(declared by additional HostGBean objects in the plan).  The web 
applications can now include a geronimo-tomcat.xml file in the WEB-INF 
file which is very similar to the Jetty version.  The only difference is 
support for the <virtual-server> parameter.  This allows you to deploy 
your web application to a specific virtual host.

TODO: The context object within the plan to predeclare a context 
placeholder(like in a server.xml).  I will be working on this to 
finalize the Tomcat integration.

Jeff