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 Mon, 09 Jan 2006 17:58:16 GMT
Jeff Genender wrote:

>Jules Gosnell wrote:
>  
>
>>Guys,
>>
>>are we not going back around the per-app/per-container argument here ?
>>    
>>
>
>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.
>
>  
>
I thought I had made clear that this was the intention...

>>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.
>  
>
I'm not saying it's wrong or right - just that long term, it's irrelevant.

If you want me to make a judgement call, I would have to say that in a 
per-app situation, which is what we have here (per-container is NYI), it 
is none of the container's business what the app is doing. If the app 
specifies a requirement for a specific db implementation and chooses not 
to share its connection pool with anyone, then that is the app's 
choice... - so I disagree with you :-), but can't be bothered to chew up 
further cycles defending the point - do whatever you feel is best.

>>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.
>  
>
I look forward to a final solution to all container/app classloading 
issues :-)

Jules

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