Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread Joe Bohn



David Jencks wrote:

I certainly agree at least one web container should always be  working 
:-).  I think jetty6 is working with new specs we just  have to 
rearrange things a little bit, I think Joe is working on that.


Well, I did get things building again in the sandbox (BTW, thanks for 
fixing those versions that I missed David).  You can now build the 
javaee5 sandbox successfully again.


Jetty6 is mostly functional in the sandbox with some strange 
console/security problems (you don't need to sign-on to the console and 
you can't really "sign-off" as well as some spurious problems/stack 
traces on various console activities).  I'm not sure if we should move 
it into trunk now if we want to ensure that we still have one container 
working while we do heart surgery on the other (ie. Tomcat).  I also 
just agreed to help Paul with some of the web-module-builder which will 
probably mean that I move some of the work from the sandbox into trunk 
but I was hoping I could do that without moving all of Jetty6 given the 
goal to have a working container.


Joe


Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread Paul McMahan

On 11/30/06, David Jencks <[EMAIL PROTECTED]> wrote:


On Nov 30, 2006, at 8:00 AM, Paul McMahan wrote:
> -  I asked [EMAIL PROTECTED] about publishing their 6.0.2 beta jars in a
> maven repo but got no response yet.  Since some of their 6.0.1 alpha
> jars were published in the snapshot repo I suspect they should be
> willing to publish the beta jars.  Are there any concerns with
> publishing those jars in my personal repo at people.apache.org as an
> interim solution?  I don't like that but can't think of a better
> approach.

There are a couple places where we have put the jars right in the
module as a file system repository.  See the dojo app for one.  I
think that might be a less troublesome solution: I'd consult jason
dillon for his opinion.


I'm familiar with the dojo app but my concern with taking that
approach is that unlike dojo the tomcat jars are needed in several
different modules/configs/assemblies.  But when it comes to maven
Jason is always yanking rabbits out of a hat so he can probably
recommend a solution.


> -  I'm proposing that we introduce a new jee5 spec config and point
> rmi-naming at it instead of the j2ee 1.4 spec config.  I'm hopeful
> that the jetty assemblies will continue to work after making that
> change but cannot guarantee.  If that causes you concerns then I'm
> open to an alternate approach.

Thinking about this more I think we should perhaps rename the specs
configs "specs" without the j2ee-1.4 stuff in the name and start
putting the new specs into it.  I'm also starting to think that
keeping jetty5 around in 2.0 will just slow us down even if it isn't
causing any problems.


OK I like that solution better too.


It would be great if we could avoid having rmi-naming depend on the
specs module :-/


agreed.

Best wishes,
Paul


Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread David Jencks


On Nov 30, 2006, at 9:39 AM, anita kulshreshtha wrote:



--- David Jencks <[EMAIL PROTECTED]> wrote:

Thinking about this more I think we should perhaps rename the specs
configs "specs" without the j2ee-1.4 stuff in the name and start
putting the new specs into it.  I'm also starting to think that
keeping jetty5 around in 2.0 will just slow us down even if it isn't


   Just a fleeting idea.. Could we possibly use the specs-configs
approach for the new things (JEE 1.5) and use the old way of doing
things for 1.4 stuff. I know it needs more thought We should have
at least one web container working all the time.


I certainly agree at least one web container should always be  
working :-).  I think jetty6 is working with new specs we just  
have to rearrange things a little bit, I think Joe is working on that.


I don't understand how we could have a hybrid approach in one  
branch.  If we left the 1.4 spec jars in the rmi-naming config and  
also gave it a parent config of the combined set of new jee5 specs  
and unconverted j2ee 1.4 specs I think the copies from the parent  
config would always be used.


I suspect I'm not understanding what you are proposing :-)

thanks
david jencks



Thanks
Anita



__ 
__

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index




Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread Paul McMahan

On 11/30/06, Jeff Genender <[EMAIL PROTECTED]> wrote:



Paul McMahan wrote:
> -  I notice that the servlet 2.5 spec was copied into specs/trunk from
> tomcat/tc6.0.x/trunk.  Any concerns with taking the same approach for
> the JSP 2.1 and EL specs?

Were they copied or typed in?  I thought Bill Dudney typed them in or
may have used the TC specs but made some changes.  I hate to copy them
in, but for the sake of consistency, perhaps you can/should do that.


Oh yeah I had forgotten about the work Bill did on GERONIMO-1686.
That work was committed to specs/branches/jee5_exp.  But the servlet
2.5 stuff in specs/trunk/geronimo-servlet_2.5_spec was copied from
tc6:

bash-3.1$ svn log src/main/java/javax/servlet/
[snip]

r417823 | gregw | 2006-06-28 13:28:46 -0400 (Wed, 28 Jun 2006) | 1 line

refactored from tc layout to g layout

r417806 | gregw | 2006-06-28 12:10:56 -0400 (Wed, 28 Jun 2006) | 1 line

interim commit before restructure to allow history to be retained

r397540 | remm | 2006-04-27 09:33:39 -0400 (Thu, 27 Apr 2006) | 1 line

- Remove JSP related resources.
[snip]

Following the comments in GERONIMO-1686 it looks like the tc6 copy was
preferred because of javadoc.  Since there are no JSP 2.1 or EL specs
already in specs/branches/jee5_exp I was just planning to also copy
them from tc6.  That's assuming that we actually *need* a copy in
geronimo/specs.  See below.


There was talk of Grand Central Project here at Apache, which would
provide for a one-stop-shop for specs to prevent from copying.  Anybody
hear of any movement on that?

http://wiki.apache.org/incubator/GrandCentralProposal

This seems like the best idea for Apache's projects.


I agree this is a good idea and would help avoid redundant efforts.

In the short term I'm wondering why we need a copy of specs in
geronimo/specs/trunk if they're already available in a maven repo?
I've been operating under the assumption there's some good reason for
maintaining a separate copy in Geronimo, probably copyright related.
But if that's not the case it would be easier to use what I found at:
http://repo1.maven.org/maven2/javax/servlet/servlet-api/2.5/
http://repo1.maven.org/maven2/javax/servlet/jsp/jsp-api/2.1/

I don't know who published those artifacts or if all the correct legal
bits are in place.  Anyone care to enlighten me as to whether or not
Geronimo really needs its own copy of the specs, and if not then how
to determine if artifacts such as the above are ok from a
legal/copyright perspective?  This is where the Grand Central Project
would be a big help...

Best wishes,
Paul


Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread anita kulshreshtha

--- David Jencks <[EMAIL PROTECTED]> wrote:
> Thinking about this more I think we should perhaps rename the specs  
> configs "specs" without the j2ee-1.4 stuff in the name and start  
> putting the new specs into it.  I'm also starting to think that  
> keeping jetty5 around in 2.0 will just slow us down even if it isn't
> 
   Just a fleeting idea.. Could we possibly use the specs-configs
approach for the new things (JEE 1.5) and use the old way of doing
things for 1.4 stuff. I know it needs more thought We should have
at least one web container working all the time.

Thanks
Anita


 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index


Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread David Jencks


On Nov 30, 2006, at 8:00 AM, Paul McMahan wrote:


I created a wiki page that outlines the game plan for integrating
tomcat v6 into Geronimo 2.0 :
http://cwiki.apache.org/confluence/display/GMOxDEV/Tomcat+v6+game+plan

For those of you whose work in Geronimo 2.0 depends in some way on
Tomcat v6 I hope this information will give you a chance to provide
feedback, adjust your plans if necessary, and even grab a hammer and
pitch in if you like ;-)

Also there are some specific items in the plan that I wanted to
collect feedback on from the dev community at large :

-  I notice that the servlet 2.5 spec was copied into specs/trunk from
tomcat/tc6.0.x/trunk.  Any concerns with taking the same approach for
the JSP 2.1 and EL specs?

-  I asked [EMAIL PROTECTED] about publishing their 6.0.2 beta jars in a
maven repo but got no response yet.  Since some of their 6.0.1 alpha
jars were published in the snapshot repo I suspect they should be
willing to publish the beta jars.  Are there any concerns with
publishing those jars in my personal repo at people.apache.org as an
interim solution?  I don't like that but can't think of a better
approach.


There are a couple places where we have put the jars right in the  
module as a file system repository.  See the dojo app for one.  I  
think that might be a less troublesome solution: I'd consult jason  
dillon for his opinion.


-  There will be a period of time where the tomcat v5 runtime has been
replaced with tomcat v6 but the builders have not been updated for
servlet 2.5 yet.  This seemed like a reasonable approach to support a
12/23 geronimo 2.0 milestone build.  I'm hoping this should work
because AFAIK tomcat v6 is backwards compatible. But there may be a
period of time where webapp deployment is broken or behaves strangely.

-  I'm proposing that we introduce a new jee5 spec config and point
rmi-naming at it instead of the j2ee 1.4 spec config.  I'm hopeful
that the jetty assemblies will continue to work after making that
change but cannot guarantee.  If that causes you concerns then I'm
open to an alternate approach.


Thinking about this more I think we should perhaps rename the specs  
configs "specs" without the j2ee-1.4 stuff in the name and start  
putting the new specs into it.  I'm also starting to think that  
keeping jetty5 around in 2.0 will just slow us down even if it isn't  
causing any problems.


It would be great if we could avoid having rmi-naming depend on the  
specs module :-/


thanks
david jencks




Best wishes,
Paul




Re: tomcat v6 integration game plan (longish)

2006-11-30 Thread Jeff Genender


Paul McMahan wrote:
> -  I notice that the servlet 2.5 spec was copied into specs/trunk from
> tomcat/tc6.0.x/trunk.  Any concerns with taking the same approach for
> the JSP 2.1 and EL specs?

Were they copied or typed in?  I thought Bill Dudney typed them in or
may have used the TC specs but made some changes.  I hate to copy them
in, but for the sake of consistency, perhaps you can/should do that.

There was talk of Grand Central Project here at Apache, which would
provide for a one-stop-shop for specs to prevent from copying.  Anybody
hear of any movement on that?

http://wiki.apache.org/incubator/GrandCentralProposal

This seems like the best idea for Apache's projects.


> 
> -  I asked [EMAIL PROTECTED] about publishing their 6.0.2 beta jars in a
> maven repo but got no response yet.  Since some of their 6.0.1 alpha
> jars were published in the snapshot repo I suspect they should be
> willing to publish the beta jars.  Are there any concerns with
> publishing those jars in my personal repo at people.apache.org as an
> interim solution?  I don't like that but can't think of a better
> approach.
> 

This has been done numerous times before ;-)  You could also publish a
"G" version of them as a temporary measure..that also has been done before.

> -  I'm proposing that we introduce a new jee5 spec config and point
> rmi-naming at it instead of the j2ee 1.4 spec config.  I'm hopeful
> that the jetty assemblies will continue to work after making that
> change but cannot guarantee.  If that causes you concerns then I'm
> open to an alternate approach.
> 

I agree with your approach.

Jeff


> 
> Best wishes,
> Paul