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:09:57 GMT


Jules Gosnell wrote:

> well then, you wouldn't use the <distributed/> tag in the app's
> WEB-INF/web.xml, would you ?

Why not?

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