geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: CCing wadi-dev for Geronimo commit r366236
Date Thu, 12 Jan 2006 17:50:12 GMT

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 ?


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


-- 
"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.
 **********************************/


Mime
View raw message