Struts 2.1.2 does not set the default interceptor based on ParentPackage. I
found a bug (WW-1553) listed as fixed describing the same problem. I could
not find the fix applied to the source of codebehind plugin.
ClasspathPackageProvider.java is missing -
pkgConfig.setDefaultInterceptorRef(paren
>* Built-in command line tool like Grails
Just found this reading Matt's blog and thought they might be connected somehow:
http://www.nabble.com/RE%3A-Getting-ready-for-Struts-2.1.1-td17446803s2369.html#a17461105
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
And;
if( plugins.length > 0 ) {
addPluginAndDependencies(orderedList, plugins[0]);
}
should be;
for(Plugin thisPlugin : plugins) {
addPluginAndDependencies(orderedList, thisPlugin);
}
(Jeeze, it's one of those days :)).
Al.
Al Sutton wrote:
Quick correction;
for(
Quick correction;
for( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, plugin);
}
should be;
for( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, thisPlugin);
}
Al Sutton wrote:
With UnknownHandl
With UnknownHandler each plugin can define an unknown handler which is
suitable for it and the code scans the list of plugins in reverse order
(i.e. last one first to ensure that plugins can be listed in order of
growing dependency needs) and uses the first one it finds.
As for the dependency
I think plugin dependencies are a no-go. We don't want to reinvent yet
another plugin mechanism with dependency resolution and all. If there
is something I like about S2 plugins it is how easy they are so
write/use, lets not complicate it much. I think the UnknowHandler
problem calls for an easy so
I thought about a dependency list of JCatapult workflows and it can
become complex if a plugin doesn't know the entire set of other plugins
that might need to be invoked before it. In some cases what would happen
is that 90% of the plugins wouldn't list any dependencies but there
might be some
It's in as WW-2665, there are two attchments, they're both the same and
either one will do the job, it's just I hit the wrong radio button first
time round (D'oh).
Al.
James Holmes wrote:
Sounds good to me. If there's a use for it and it's simply a configurable
option, why not.
On Tue, Jun 3
Sounds good to me. If there's a use for it and it's simply a configurable
option, why not.
On Tue, Jun 3, 2008 at 4:29 AM, Al Sutton <[EMAIL PROTECTED]> wrote:
> I'm working on some code which returns a result stream which shouldn't be
> cached. I've modded the StreamResult class to add an "allow
I think it is good.
musachy
On Tue, Jun 3, 2008 at 4:29 AM, Al Sutton <[EMAIL PROTECTED]> wrote:
> I'm working on some code which returns a result stream which shouldn't be
> cached. I've modded the StreamResult class to add an "allowCaching"
> attribute which sets the Pragma and Content-Control
I haven't been paying too much attention to the progress of the
Portlet 2.0 spec lately, but I guess somewhere around 2.5 would be a
good time to get the portlet 2.0 plugin in place. As for the current
portlet plugin, the only "major" missing feature is Ajax, but I'm not
sure it's worth the effort
I'm working on some code which returns a result stream which shouldn't
be cached. I've modded the StreamResult class to add an "allowCaching"
attribute which sets the Pragma and Content-Control headers on the result.
I have simple question; Is this worth opening up a JIRA issue with the
patch,
12 matches
Mail list logo
