Re: Exploring actionPackage-based configuration issues

[Brian Pontarelli <br...@pontarelli.com>]

> I'm happy with a hybrid mix of XML and annotations; however something 
> feels very
> wrong about using the package-info.java file for holding the XWork 
> package level
> annotations, so I'm trying to think of alternatives.
I can understand the difficultly in using a new language concept that 
has little mindshare but I think that this is the standard location for 
that kind of configuration according to the Java language. Besides, this 
is the only clean way to ensure a single location of package level 
annotations and documentation.

> I think the root problem is that I'm not 100% comfortable with model 
> of the
> XWork Package.  As I see it so far, its a container for configuration
> information and for some reason that bothers me.  I feel that there is an
> application developer-exposed class waiting to be discovered.  This is 
> probably
> more of a struts 2.1++ issue, but I think the notion of an XWork 
> package is
> missing something.  (It might also be advisable over several releases to
> consider renaming the XWork package concept so its not as confusable 
> with the
> java package, but that's an orthogonal issue.)
I definitely agree on the whole naming issue. It is difficult to talk to 
new developers about XWork packages without confusion. Are you 
suggesting that the XWork package needs more configuration control or 
that the concepts need to be separated or something else entirely? You 
sorta lost me here.

> This feeling of unease is slightly exacerbated by some of the 
> difficulties I
> have debugging package issues -- ie when playing with zero configuration
> annotations and xml, there's does seem to be any good way to check 
> what package
> an action has been assigned to confirm that defaults or annotations 
> are working.
> config-browser exposes the namespace of an action, but not its 
> package, for
> instance.  This leads to the feeling that the XWork package is a 
> second-class
> citizen in the framework, but I know its not.
This is an interesting dilemma because the way XWork is configured 
implies reuse at the Action level and that Actions should not be coupled 
to the interceptor chain (to some degree). However, this is usually not 
the case. Most Actions I write are highly dependent on the interceptor 
chain and nearly never dependent on the namespace and often never reused 
(that's what I usually place in the service tier). However, most times 
it is a 95%/5% situation where I use the same interceptor chain for 95% 
of the application and a different chain for 5% (or less). Therefore, 
global defaults usually work best for me. This might not the norm, but 
my experience to date with 5 or so applications. Therefore, setting good 
global or XWork package defaults makes sense to me.

Not sure what I'm getting at but it seems that the current configuration 
model makes good sense and works for all the cases I've had.

> While I can see wanting some configuration control over the package -- 
> changing
> namespaces; or the root of web content, in the case of SmartURLs; 
> changing
> naming strategies -- feel like proper "configuration" tweak points 
> (and thus
> more XML friendly).  Ie these are things that I'd expect good default
> coventions for, but things that in best practices are overridden in 
> XML. Things that you want to be able to change on multiple-deployments 
> without
> re-compiling.
Hmmmmm... I personally don't like the idea of changing namespaces or 
naming strategies at all. If you consider SEO, this is usually a bad 
idea unless you are really good about retaining existing URLs and doing 
proper 301 redirects. Otherwise, you'll upset the search gods and your 
ranking will drop considerably, not to mention the 3 months you'll have 
to wait to get re-ranked. Also, since I'm not huge on Action reuse, I'm 
perfectly fine setting namespaces using Java packages or annotations. 
And in my opinion, naming strategies should be fixed from the start and 
never changed.

> While the other aspects -- interceptors, names and types (but maybe not
> destination) of global results, which actions belong to this package, 
> etc are
> "configuration" but not really end-user configuration.  Its the wiring 
> that's
> not expected to be changed.  This is places where good conventions 
> overridden
> by source code annotations makes the more sense.  And at which point 
> having the
> ability to programaticly configure an application starts to feel possibly
> valuable.
I'm sorta on the other side of the fence here. I don't really change 
interceptor chains too much and often when I do, changing the whole 
application is fine by me. Or if I need to change a single package, 
that's okay in XML or the properties file as well. Global results and 
package results are also usually a one time configuration for me and not 
something that Actions really need to know about. So, I usually find 
that I set these up in the struts.properties and struts.xml files and 
never touch them. So, having these defined in annotations is really not 
something I use much, if at all.

I guess in the end, I'm fine with the way it all works now. I rarely hit 
a configuration problem that I just feel bad implementing using the 
current tools and often I tweak at the beginning and then never touch it 
again. But again, this is my cases and I'm sure folks do it other ways. 
I guess I'm just wondering what really seems to be your ideal 
configuration/coding solution, what configuration should Actions be 
aware of and what are you looking to control?

-bp