FYI, just added a spring/car module to trunk and hooked it up with
CXF. We can try doing the same with Pluto/new console now.
Jarek
On 9/19/07, Jarek Gawor [EMAIL PROTECTED] wrote:
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote:
Maybe for now we should remove the filtering from web
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote:
Maybe for now we should remove the filtering from web deployers and
let each application configure the Spring filtering if necessary.
Agreed and the idea about using a configuration for spring could be
promising too.
Ok. I removed the
On Sep 14, 2007, at 7:58 PM, Kevan Miller wrote:
Heh. Well, I had hopes for Paul's proposal... Sounds like it's
still better than where we are now...
I was also thinking that it's a step forward, but now it's not clear
to me whether moving the spring filter to cxf-deployer would break
Paul,
In the new admin console, do the web applications (that provide
portlets) need to share Spring version/configuration with the Pluto
config module? What if each web application had its own Spring jars?
Would that work?
Moving the Spring filters to cxf-deployer is better from the
modularity
On Sep 17, 2007, at 12:48 PM, Jarek Gawor wrote:
Paul,
In the new admin console, do the web applications (that provide
portlets) need to share Spring version/configuration with the Pluto
config module? What if each web application had its own Spring jars?
Would that work?
Actually the
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote:
Moving the Spring filters to cxf-deployer is better from the
modularity point of view (and I'm all for it) but the end results will
be the same in this case. I think Kevan's idea might be the best
solution here.
The end results here
On Sep 17, 2007, at 4:15 PM, Jarek Gawor wrote:
Moving the filter from web deployer to cxf deployer will have no
effect on your app. The application will always end up with the same
filter in either setup. It will only work ok, if the filter is in
cxf-deployer *and* if you use Tomcat or
Jarek, This commit is causing some problems for the new admin
console plugin because it needs to inherit the spring classes from
its parent component (pluto-support). This situation is the inverse
of the original problem we were hoping to solve where a web-app does
*not* want to inherit
Ugh... I had a feeling that this filtering will cause problems for
someone. Anyway, in general I think moving the hidden-classes filter
to the CXF deployer is a better solution (to keep it all together and
assuming it has the same effect as when specified in the web container
deployer). But, in
On Sep 14, 2007, at 2:56 PM, Jarek Gawor wrote:
Ugh... I had a feeling that this filtering will cause problems for
someone. Anyway, in general I think moving the hidden-classes filter
to the CXF deployer is a better solution (to keep it all together and
assuming it has the same effect as when
10 matches
Mail list logo
