geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: CCing wadi-dev for Geronimo commit r366236
Date Thu, 12 Jan 2006 18:03:15 GMT
Comments below...

Jules Gosnell wrote:
> 
> to give the question its correct context:
> 
> Jeff said:
> 
> You need to support both per container and per app.  Thats the way the
> Tomcat clustering works today and it allows for the most flexible
> ability to choose what level.  There are certain web applications that
> you don't want clustered, like the console.
> 
>> then I said :
>>
>>  
>>
>>> well then, you wouldn't use the <distributed/> tag in the app's
>>> WEB-INF/web.xml, would you ?
>>>   
>>
>>  
>>
> than Jeff said :
> 
>> Why not?
>>  
>>
> now I say :
> 
> Jeff, putting <distributable/> in your app's WEB-INF/web.xml signals to
> the container that it wishes to be clustered.
> 
> An app which does not wish to be clustered would not include this tag
> and the container would make no attempt to cluster it.
> 
> So, if the console did not wish to be clustered it would not include
> this tag....
> 
> The decision about clustering is made on a per-app basis in a standard
> descriptor as laid out in the spec.
> 
> How that clustering is achieved is left to the container and may usually
> be configured in a proprietary descriptor or plan.
> 
> Is that clearer ?

And Jules said on 1/6/06:

>Guys,
>
>Jan and Greg are staying with me for a few days, starting monday.
>
>We will go through the integration together and keep the list up to
>date with any issues that we find.


Then Jules came back and said on 1/12:

>Guys,
>
>Jan and I have just refactored the Geronimo Jetty and Tomcat
>integrations to take the same approach to the installation of a 3rd
>party session manager, to ease the integration of WADI. This is now
>checked in on Geronimo's trunk.

Sorry Jules, this is not how we do things at Apache.

I said, as did others we want to work with a configuration.  You
discounted these comments.  You didn't talk about the exact approach,
nor did you include the others on the architected approach.  You ended
up delivering something that was far from what I would have ever agreed to.

Lets open up discussion on the G lists since this affect G architecture.

> 
> 
> Jules
> 
>>  
>>
>>> Jules
>>>
>>>   
>>>>
>>>>
>>>>     
>>>>> in a per-container situation, as I ultimately envisage the Geronimo
>>>>> integration, apps will simply need to declare a <distributable/>
tag,
>>>>> unless they want to override the container's choice (see per-app in
>>>>> next
>>>>> para). No infra jars or wadi dd should be required in the app - all
>>>>> should be provided/defaulted by the container...
>>>>>
>>>>> The above should not preclude the possibility of the per-app approach,
>>>>> where the app can take total control of how it is clustered - our
>>>>> current approach to the Geronimo integration, by shipping the whole
>>>>> infra and dd itself (possibly reusing existing container infra like
>>>>> jars
>>>>> whose presence is guaranteed in the container).
>>>>>
>>>>> These are two different approaches and I would have concerns about
>>>>> muddling them up.
>>>>>
>>>>> There is one further possibility, already touched on, that rather than
>>>>> these two approaches being exclusive the per-app stuff might
>>>>> somehow be
>>>>> overlaid ontop of the per-container stuff.... My jury is still out on
>>>>> whether this could be done simply enough to make it worthwhile...
>>>>>
>>>>> With regards to Axion - its just there to illustrate a point - when we
>>>>> have more time, we can test WADI with other DBs that Geronimo might
>>>>> easily be hooked to.
>>>>>  
>>>>>       
>>>> Regardless, its wrong and I -1d it from a Geronimo perspective.  We
>>>> should not be testing with HEAD and hardcoding application based
>>>> dependencies at the container level.  I suspect the others would agree.
>>>> According to the emails, Jan has gotten past this...so this should be a
>>>> dead issue.
>>>>
>>>>
>>>>
>>>>     
>>>>> With regards to other ClassLoader issues - these are always going
>>>>> to be
>>>>> an issue with the per-app approach - I think... Hopefully, we will
>>>>> move
>>>>> to a per-container approach soon (See Gianny's work) and resolve
>>>>> all of
>>>>> these issues.
>>>>>  
>>>>>       
>>>> Not necessarily.  The entire plan with specific configuration
>>>> should get past this issue.  David Jencks has some good ideas for WADI
>>>> in its own configuration and I think he is spot on.
>>>>
>>>>
>>>>
>>>>     
>>>>> Jules
>>>>>
>>>>>
>>>>> Jeff Genender wrote:
>>>>>
>>>>>  
>>>>>       
>>>>>> Greg Wilkins wrote:
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> Jeff Genender wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> This would be a big issue.  This would tie the connector
to the
>>>>>>>> container.
>>>>>>>>
>>>>>>>> There is a better solution.  Please move the Spring jar out
of the
>>>>>>>> container and place it in the WEB-INF/lib. Same for Axion.
>>>>>>>>
>>>>>>>> Then in your plan...please add the following to your plan:
>>>>>>>>
>>>>>>>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>>>>>>>>
>>>>>>>>
>>>>>>>> This should force the web app to use the local Spring which
has
>>>>>>>> access
>>>>>>>> to the Axion lib in the web app.
>>>>>>>>                       
>>>>>>> I really think we need to take a step back and look at the whole
>>>>>>> deployment
>>>>>>> and configuration issue.
>>>>>>>
>>>>>>> A webapp should be able to be distributed simply by saying
>>>>>>> <distributable/> in its web.xml.   It should not have to
include
>>>>>>> spring jars or any other jars for
>>>>>>> that matter in it's WEB-INF.   Any per web-app configuration
for
>>>>>>> wadi
>>>>>>> should be
>>>>>>> able to be achieved without any jars - either in a wadi-web.xml
file
>>>>>>> or perhaps
>>>>>>> just as context init-params in the web.xml?
>>>>>>>
>>>>>>>                
>>>>>> I agree somewhat with you...but not completely.  The <distributable>
>>>>>> tag
>>>>>> is only one small component.  We should be able to swap out with
any
>>>>>> clustering engine, so I think it goes beyond this.  I do agree,
>>>>>> however,
>>>>>> that there should be no need for WADI jars in the WEB-INF/lib.  The
>>>>>> configuration really should come from a WADI configuration car
>>>>>> that is
>>>>>> imported into the plan.  This along with a distributable tag can
>>>>>> make it
>>>>>> happen.  But I would like to see the imported car in the
>>>>>> geronimo-web.xml or plan file to be the clustering engine of choice.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> Having said that, adding spring to the hidden classes is a good
>>>>>>> idea.  Actually
>>>>>>> ALL the classes used by Wadi should be hidden, as the servlet
>>>>>>> specification says
>>>>>>> that container implementation classes should not be visible to
a web
>>>>>>> application.
>>>>>>> It is a bit of a hack to allow them to be seen and manipulated
by
>>>>>>> individual
>>>>>>> web applications.
>>>>>>>
>>>>>>>                
>>>>>> This is a bigger issue that you think and affects far more than just
>>>>>> WADI.  Yesterday I just helped a friend deploy a simple
>>>>>> Spring/Hibernate
>>>>>> application to Geronimo and it failed.  The only way to have it
>>>>>> happen
>>>>>> was provide the hidden-classes filter for Spring and Antlr.  The
>>>>>> problem
>>>>>> here was that we injected the Spring libs at the container level
and
>>>>>> via
>>>>>> the J2EE specs, it was using that for certain calls and the
>>>>>> WEB-INF/lib
>>>>>> for others, thus offering ClassNotFoundExceptions (sound familiar?).
>>>>>> This goes back to the old commons logging problem that is so common,
>>>>>> even with other app servers and containers.  I don't think this is
>>>>>> avoidable due to the class loading engine and the very large
>>>>>> amount of
>>>>>> components that Geronimo uses.  We will be filtering out a lot in
the
>>>>>> future.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> I think the idea of having the full clustering solution within
>>>>>>> WEB-INF was a good
>>>>>>> idea to get Wadi running on multiple containers.... but for real
>>>>>>> deployments it
>>>>>>> is not sufficient and we need to look at container support for
Wadi.
>>>>>>>
>>>>>>>                
>>>>>> I agree with you 100% on this point.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> cheers
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>  
>>>>>       
>>>   
> 
> 

Mime
View raw message