Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #30266
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2014-11-01 07:50 -0700 |
| References | <16dee62b-b502-470b-b99b-456dced35684@googlegroups.com> <m31nr7$n17$1@dont-email.me> |
| Message-ID | <7fdc7502-8074-44d9-ac2b-d201ab924eb8@googlegroups.com> (permalink) |
| Subject | Re: annotation metadata proposal |
| From | boxzou@gmail.com |
I am developing a framework taking many plugins. Each plugin will have Jersey ReST end points and batch components. Right now each plugin has to be a WAR file to specify the component packages so Jersey knows where to look up the ReST end points. The plugin also must list all the packages that contain batch components. Jersey end points and batch components are all annotated with annotations. There are also other classes with annotations, like configurations for each plugin (and its validation), custom configuration loaders, exception codes etc. Since the framework does not know where to look for the annotated classes (a complete classpath scanning is too expensive), we use properties files to list the packages that contain the annotated classes. Right now each annotation mandates its own file. We are considering consolidating into one single file. Even so maintaining those files can be error-prone because such properties files contain derived information. Ideally the compile/IDE should be able to put such info in a file and build them as build artifacts. That's the rational/thinking behind this proposal. > I think: "*Why* do you need to find all the @Sport-annotated classes > at runtime?" > > I can see why it's useful to find all something-or-other classes (or > packages, or other things) at runtime: That's how things like Swing > look-and-feel implementions get found, not to mention crypto plugins, > fonts, and a good deal of other stuff that lives "in the environment." > My question isn't why you want to find something, but why you want to > use annotations as the search keys (or filters). For one thing, it > seems rather limiting: You could only search for annotatable things, > so fonts and DLL's and other such artifacts would be forever invisible. > > In a follow-up, you refer to "hundreds if not thousands of classes," > which makes me wonder whether class-at-a-time annotation is a scalable > way to organize things. Isn't there a higher-level taxonomy of some > kind you could take advantage of? How many thousands of sports are > there, anyhow? > > What is the problem you face? Can you describe it concretely > without breaching too many confidences? > > -- > esosman
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
annotation metadata proposal boxzou@gmail.com - 2014-10-30 21:06 -0700
Re: annotation metadata proposal Joerg Meier <joergmmeier@arcor.de> - 2014-10-31 07:46 +0100
Re: annotation metadata proposal Arne Vajhøj <arne@vajhoej.dk> - 2014-10-31 20:53 -0400
Re: annotation metadata proposal boxzou@gmail.com - 2014-10-31 20:26 -0700
Re: annotation metadata proposal Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-01 00:33 -0400
Re: annotation metadata proposal boxzou@gmail.com - 2014-11-01 07:50 -0700
Re: annotation metadata proposal Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-01 20:42 +0000
Re: annotation metadata proposal boxzou@gmail.com - 2014-11-01 15:56 -0700
Re: annotation metadata proposal Robert Klemme <shortcutter@googlemail.com> - 2014-11-02 00:08 +0100
Re: annotation metadata proposal boxzou@gmail.com - 2014-11-01 19:38 -0700
Re: annotation metadata proposal boxzou@gmail.com - 2014-11-04 21:46 -0800
Re: annotation metadata proposal boxzou@gmail.com - 2014-11-04 21:50 -0800
Re: annotation metadata proposal Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-02 00:31 +0000
csiph-web