The plugin will scan the entire classpath, but that's not to large of an
issue and pretty fast (considering). The issue is when it starts loading
classes into the perm space to determine if the class is in fact an
Action or not. This is the part where your perm space can become full
and then you start getting strange errors.
The best way to fix this and still employ scanning (which I much prefer)
is to set the struts.convention.package.locators constant to the name of
packages you want your actions to reside in. This is only a single
package and not the fully qualified package name. For example, I put all
my actions in packages named *actions* or sub-packages like this:
com.example.actions.MyCoolAction
In this case, I just set the struts.convention.package.locators value to
*actions* only. This will help increase speed and decrease strange
errors. However, this isn't always enoug. Next, you need to correctly
set the struts.convention.exclude.packages constant to the list of
packages that you wish to exclude from processing. In my case, there are
3rd party libraries with packages that contain *actions* and I just list
those out like this:
org.springframework.*,org.jcatapult.*
This tells the plugin to ignore any packages that start with the given
Strings (minus the * character).
Hope that helps.
-bp
dusty wrote:
Musachy,
First off, Hi.. My name is Dusty Pearce and I am long time webwork user.
How do I pronounce your name? In my head its something like
Moose-atch-ee....
With that out of the way, I feel like I am missing something simple, but if
you have spring-jdbc in your pom.xml (dependency of spring security) the
convention plugin throws NoClassDefError about not finding
com/ibm/wsspi/uow/UOWAction which is an inner class of
[org.springframework.transaction.jta.WebSphereUowTransactionManager.
So its scanning all packages for the "Action" keyword. I tried to set
struts.convention.action.packages and that did not fix it. I was not sure
what other options to try (struts.convention.action.disableGlobalScanning?).
I also thought that when I have the REST plugin with the convention plugin
exclusion, that it would look for Controller rather than Action.
Can you try and add spring-jdbc (2.0.8 and 2.5.4 did the same thing) to your
pom.xml and see if you get the same result. I feel like I should be able to
just figure out the right configuration....but any help would be
appreciated.
Musachy Barroso wrote:
Convention does needs the views to be in the same directory structure
as the namespace of the action. Yes, all the convention code is
committed, a change to struts-plugin.xml in REST would be needed:
Index: C:/src/struts2/plugins/rest/src/main/resources/struts-plugin.xml
===================================================================
--- C:/src/struts2/plugins/rest/src/main/resources/struts-plugin.xml
(revision
652924)
+++ C:/src/struts2/plugins/rest/src/main/resources/struts-plugin.xml
(working
copy)
@@ -24,7 +24,7 @@
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd";>
-
+
<struts>
<bean type="com.opensymphony.xwork2.ActionProxyFactory"
name="rest" class="org.apache.struts2.rest.RestActionProxyFactory" />
@@ -29,8 +29,6 @@
<bean type="com.opensymphony.xwork2.ActionProxyFactory"
name="rest" class="org.apache.struts2.rest.RestActionProxyFactory" />
<bean type="org.apache.struts2.dispatcher.mapper.ActionMapper"
name="rest" class="org.apache.struts2.rest.RestActionMapper" />
-
- <bean type="com.opensymphony.xwork2.config.PackageProvider"
name="rest"
class="org.apache.struts2.rest.ControllerClasspathPackageProvider"
/>
<bean class="org.apache.struts2.rest.ContentTypeHandlerManager" />
@@ -43,13 +41,16 @@
<constant name="struts.mapper.class" value="rest" />
<constant name="struts.mapper.idParameterName" value="id" />
<constant name="struts.action.extension" value="xhtml,,xml,json" />
-
+ <constant name="struts.convention.action.suffix" value="Controller"
/>
+ <constant name="struts.convention.action.mapAllMatches"
value="true"/>
+ <constant name="struts.convention.action.checkImplementsAction"
value="false"/>
+
<!-- Disable the scanning by the codebehind plugin to prevent
duplicates -->
<constant name="struts.configuration.classpath.disableActionScanning"
value="true" />
-
+
<constant name="struts.configuration.rest.disableControllerScanning"
value="false" />
<constant name="struts.configuration.classpath.defaultParentPackage"
value="rest-default" />
-
+
<package name="rest-default" extends="struts-default">
<result-types>
<result-type name="redirect"
class="org.apache.struts2.dispatcher.ServletRedirectResult">
@@ -108,7 +109,7 @@
input,back,cancel,browse,index,show,edit,editNew
</interceptor-ref>
</interceptor-stack>
-
+
</interceptors>
<default-interceptor-ref name="restDefaultStack"/>
musachy
On Thu, May 22, 2008 at 12:30 AM, dusty <[EMAIL PROTECTED]> wrote:
I have a largish app that I wrote with RESTful design. It doesn't use
the
REST plugin because I didn't like the codebehind results default. Having
all my views in a flat directory with action-result.ext on a large
project
doesn't work. Instead I organized my views action/results (i.e.
PatientController : WEB-INF/pages/patient/index.jsp or edit.jsp, etc).
Its
more like Rails and on larger projects its way easier to follow. I am
not
sure if you nest view directories under the parent contollers
packages....
So I ended up just wiring it up using XML configuration. Since then, I
have
been playing with the REST and Codebehind plugin. I got the Codebehind
plugin to organize the view files the way I wanted, but with Convention
and
smart-urls still out there, I was worried about tying an app to one of
them.
Somehow when working with the REST plugin its seems unfinished....
Struts2 definitely needs less options in the configuration and action
invocation space. The whole idea behind convention over configuration is
that the software should be opinionated. There should be "a way".
- We need customizable routes where you can embed parameters, to do
things
like nested resources (/users/[:user_id]/comments/[:id])
- <s:url .../> and <s:form action=... /> should generate RESTful or
whatever URLs based on the invocation scheme and routes
- As I mentioned before the default result organization should be
package-past-baseactionpackage/contoller/result.jsp|ftl
But most importantly we need one way! Convention looks great, I would
love
to see the REST/Convention setup. Did you commit your rest changes?
Musachy Barroso wrote:
I am trying to figure out what this means! :-) Sounds humorous.
yeah, just kidding :)
I added a couple of settings to convention so REST can plugin nicely.
I have the rest-showcase app working. Does anybody have a bigger REST
app to test against?
//is svn down?
musachy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
