Am Freitag, 23. Mai 2008 05:51:39 schrieb Musachy Barroso:
> Yes I had a similar problem, and is not jdbc specific, it's just
> convention scanning too much, I can't really remember what my problem
> was, but convention was scanning the whole classpath. Anyway,
> that's why I added "struts.convention.action.disableGlobalScanning",
> so only the named packages in "struts.convention.action.packages" will
> be scanned. You can replace "Action" by "Controller" overwriting
> "struts.convention.action.suffix".
I opened WW-2576 some time ago.
After looking at the source I came to the conclusion that the convention
plugin is designed to exclude a whole bunch of packages from classpath
scanning. For my feeling that is not the best way to go because you can never
be sure what is on your classpath. Worst case the application stops working
because the admin adds some jars to the classpath of the appserver, the ear
is extended with some lib or whatever. In an enterprise environment this
behaviour is IMHO a no-no.
Anyway, I do understand that there are usecases where this approach is needed.
To solve this, I thought about an option like "scanningRoot" that defaults
to "**" (or "^(.*)$") In my case, I would set it to something
like "com.project.**" or "^com\.myproject\.(.*)$"
What do you think? Keeping the number of configuration options as small as
possible is s.th. not too bad... maybe it makes sense to consolidate some of
them?! I just feel like there are too much options to do the same kind of
stuff.
Last but not least: I would start implementing this in
PackageBasedActionConfigBuilder.buildUrlSet() - is this the right place to do
so?
Piero
> I will document all these constants
> in the plugin page one of these days :)
BTW, I added the flatLayout parameter to the table on plugin page.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
