It's not unprecedented to put annotations on package-info.java.
Obviously the JDK supports it, and Hibernate allows you to use JPA
annotations at the package level. For instance, I've done that to
define at a more global level a default ID generator for my
persistent classes.
While package-info may still be relatively obscure in the Java dev
world, I think to those that do know about it, this would be a fairly
intuitive place for annotations.
On Sep 27, 2007, at 11:41 AM, Eric D Nielsen wrote:
Quoting Brian Pontarelli <[EMAIL PROTECTED]>:
You actually can annotate packages. There is a special java file
called package-info.java that you place in a package and annotate
like this:
@ParentPackage("foo")
package com.example.actions;
Ahh, that's what I was referencing as a possible solution at the
very bottom of
my email. Though, I'm not sure how beneficial it'll be. Seeing how
package-info.java is used primarily for JavaDoc needs, I'm not sure
how clean
it is to start mixing in the configuration aspects. Yes the file
already exists
so we wouldn't be introducing a new file just to hang the
annotations on.
I've been wondering if a solution more like: (I'm not tied to any
of the names,
optional/additional overrides should in brackets)
---------------------------------
package com.example.packages;
[EMAIL PROTECTED]("somename")]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
public class FooPackage [implements XWorkPackage] {
public Result login = new Result("login","redirect")...
// or maybe more like
@Result(...)
public String login="login";
@Interceptor(order=["top"|"bottom"|?] // refering to before/after the
pre-configured stack?
public String someMethod(ActionInvocation invocation) throws
Exception {
}// assumes that the interceptor doesn't need an init/destroy
}
----------------------------------
package com.example.actions.foo;
public class BarAction [implements Action]
...
-----------------------------------
package com.example.actions;
public class BazAction [implements Action]
....
-----------------------------------
Actions in actions.foo would have their ParentPackage set to the
FooPackage by
default, (and could always override with their own explciit
ParentPackage. I'm
not sure how to deal with properly un-aliasing camelCapped Packages
from nested
subpackages, etc. The @DefaultPackage annotation is used to set an
application
wide default and to specify the parent package of actions at the
root of the
actions package hierarchy.
Furthermore we could get parent-package auto-detection for nested
packages
following a convetion like com.example.packages.foo.QuxPackage
looks for
com.example.packages.FooPackage to set as its parent package before
failing to
the configured default.
Now one advantage I can think of for this type of system, is that
it might make
it easier for run-time reconfiguration of packages/actions.
Imagine for
instance that your building a application that builds some form of
'store
fronts'. When a client signs up, they app creates a new package
for them and
copies some stock actions into their section of the site, etc. I
can tell I'm
reaching.... Just not sure how far :)
Annother feature that might make sense in the more programatic/
annotation based
appraoch:
a series of naming strategy methods (like hibernate's) for
changing the
capitalization/hyphenation rules for mapping urls to actions within
that
package, or mapping results to content directory(^Hies)
However, I'm still not sold, on my own idea... It seems that there
are three
approaches for per XWork package configuration
a) existing struts.xml
b) adding annotations to package-info.java
c) something like what I'm suggesting (promoting XWork packages to
an explicit
class)
As I see it, Struts 2 will need at (a) and at least one of (b)&
(c). To my
thinking, if there is at least one more useful programatic/
instrospection based
thing to hook on the explicit class approach, its probably a
winner. But I
haven't dug deep enough into a real application to know if there's
another
thing that I'd like the package to take care of for me yet.
Eric
---------------------------------------------------------------------
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]
