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 Mon, 09 Jan 2006 18:15:50 GMT


Jules Gosnell wrote:
> 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...

Not completely, but this is good then...it looks like we are in agreement.

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

Sounds like we are in agreement again.  Again...as I stated, its a dead
issue as Jan is tending to it and has confirmed its fine to remove.  No
need to spend a single cycle more on this point.

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

Well...lets get this discussion on GDev too as I think you will find we
can come to the solution that will work best. Aaron and DJ both have
commented on these issues and it would be great to keep their input flowing.

Sounds like we are making some good progress here.

Jeff


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

Mime
View raw message