You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@apache.org> on 2006/01/09 18:48:09 UTC
Re: CCing wadi-dev for Geronimo commit r366236
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.
>
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
Re: CCing wadi-dev for Geronimo commit r366236
Posted by Jeff Genender <jg...@apache.org>.
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>
Re: CCing wadi-dev for Geronimo commit r366236
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/
Re: CCing wadi-dev for Geronimo commit r366236
Posted by Jeff Genender <jg...@apache.org>.
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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
>
Re: CCing wadi-dev for Geronimo commit r366236
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/
Re: CCing wadi-dev for Geronimo commit r366236
Posted by Jeff Genender <jg...@apache.org>.
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>
Re: CCing wadi-dev for Geronimo commit r366236
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
>
>
well then, you wouldn't use the <distributed/> tag in the app's
WEB-INF/web.xml, would you ?
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.
**********************************/