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