[Please excuse if this appears twice, the copy I sent several hours ago seems to
have gotten lost and my webmail client does drop emails at times]
>> 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
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
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 litt
Quoting Brian Pontarelli <[EMAIL PROTECTED]>:
I guess I'm missing the overall use case. Do you just want to get rid
of all your XML configuration and put everything inside Java code and
annotations? Or are you trying to solve a specific problem that is
currently unsolvable? It seems like it is
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 packag
--- Eric D Nielsen <[EMAIL PROTECTED]> wrote:
> 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.
I wouldn't say it's used *primarily* for JavaDoc
needs; it was introduced specifically for
package-leve
I guess I'm missing the overall use case. Do you just want to get rid of
all your XML configuration and put everything inside Java code and
annotations? Or are you trying to solve a specific problem that is
currently unsolvable? It seems like it is more of the former because
right now, with a
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 sol
Okay, I added this feature into the code and it should be ready for the
0.20 release. Does it make sense to also add the same handling for
Namespace? Seems like this would reduce duplicate annotations inside
classes... However, I'm not a big fan of using the namespace if it can
be avoided and
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;
And in the actual @Interface definition, you just add the package target
like this:
@Target({Elemen
From: Brian Pontarelli <[EMAIL PROTECTED]>
Eric,
SmartURLs (and the zero-config/code-behind) provides a property
that seems like what you need. SmartURLs property is named:
smarturls.action.default.parent.package
which sets the default parent package for all actions that don't
provide
Eric,
SmartURLs (and the zero-config/code-behind) provides a property that
seems like what you need. SmartURLs property is named:
smarturls.action.default.parent.package
which sets the default parent package for all actions that don't provide
something else. I think the zero-config/cobe-b
I've been using Struts 2 for a few weeks now and am finding a few areas that
don't seem to posses the same clarity/utilty as most of the framework. I'm
interested in seeing if I can come up with a patch to address these areas.
The first thing that's been bothering me is the lack of a clean way to
13 matches
Mail list logo
