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 levelI 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.annotations, so I'm trying to think of alternatives.
I think the root problem is that I'm not 100% comfortable with model of theI 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.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 anapplication 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 ismissing something. (It might also be advisable over several releases toconsider renaming the XWork package concept so its not as confusable with thejava package, but that's an orthogonal issue.)
This feeling of unease is slightly exacerbated by some of the difficulties IThis 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.have debugging package issues -- ie when playing with zero configurationannotations 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-classcitizen in the framework, but I know its not.
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 thusHmmmmm... 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.more XML friendly). Ie these are things that I'd expect good defaultcoventions for, but things that in best practices are overridden in XML. Things that you want to be able to change on multiple-deployments withoutre-compiling.
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.While the other aspects -- interceptors, names and types (but maybe notdestination) 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 theability to programaticly configure an application starts to feel possibly valuable.
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
smime.p7s
Description: S/MIME Cryptographic Signature