Hi Wonseok,
In the absence of an annotation class, the annotation reflection methods
(like Class.getAnnotations()) does not throw NoClassDefFoundError. It is
against the JSR-175 spec. Because of bug in JDK 5,
TypeNotPresentException was being thrown, but it has been in JDK 5 UR6
and JDK 6 builds. See
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6322301 for more
information.
There is another related bug to that issue which has to do with
development time and it is still being fixed:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6322301
So I think vendor specific annotations are OK as far as we limit them to
express things that are close to the code, not for runtime configuration.
Thanks,
Sahoo
Wonseok Kim wrote:
> Vendor-specific XML (other than orm.xml) is good place for advaned
> configurations.
> But I have worry about vendor-specific annotations(See following
> paragraphs from my earlier posting to dev).
>
> ----------
> If we have GlassFish specific annotations, I think we should consider
> the portability.
>
> It's very convenient than XML but then the class which use GlassFish
> specific anntotations depends on GlassFish specific API classes. So
> the application won't run (NoClassDefFoundError?) in other application
> servers unless GlassFish API classes go along with it . The specific
> annotations are meaningless in other appservers, but we should carry
> the API jar files with the application unless we modify code.
> But XML has no problem because it's silently ignored and we just need
> to make another vendor-specific XML.
>
> So I think using vendor-specific annotations is not good way than XML...
> ----------
>
> On 8/11/06, *Adam Bien* <abien_at_adam-bien.com
> <mailto:abien_at_adam-bien.com>> wrote:
>
>
> Peter,
>
> > Hi all,
> >
> > This feature is one of many features that go beyond the spec that
> > should be considered for future inclusion in the product. We
> welcome
> > community involvement in all phases of the feature development
> cycle.
> How can this happen. Can we just commit the code? :-)
> >
> > This may be a good time to start the general discussion of
> configuring
> > and supporting things beyond the spec. Anyone have any thoughts on
> > how they would like to see advanced configuration (config beyond the
> > spec) handled?
> Custom annotations: org.glassfish etc. and XML could do the job. I'd
> prefer annotations, because then the dependency to Glassfish is more
> obvious. In case someone would like to migrate,
> the affected areas are more easily to identifiy. DD configuration
> should
> be of course also possible.
>
> I will post my next ideas from time to time here :-).
>
> >
> > Thanks,
> > Peter
> >
> >
> > -----Original Message-----
> > *From:* Wonseok Kim [mailto:guruwons_at_gmail.com
> <mailto:guruwons_at_gmail.com>]
> > *Sent:* Wednesday, August 09, 2006 11:37 PM
> > *To:* persistence_at_glassfish.dev.java.net
> <mailto:persistence_at_glassfish.dev.java.net>
> > *Subject:* Re: Idea for optimistic concurrency extension
> >
> > Hi, Adam
> >
> > As I know TopLink Essentials has limited optimistic locking
> > feature - only version locking policy.
> > But TopLink itself has several other optimistic locking
> features -
> > field-based locking policy(all fields, changed fields or
> selected
> > fields).
> > See
> >
> http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/descfg025.htm
> >
> > I wonder that these extended features can be ported to TopLink
> > Essentials.
> > If Oracle is reluctant to do this due to its policy, other
> > developers may be able to do this by its own implementation.
> >
> > I don't know what is Oracle or Sun's policy about those kinds of
> > extended features.
> > Will the extended features of TopLink be migrated gradually to
> > TopLink Essentials? Or should GlassFish itself implement its
> own
> > implementation for those features? Or GlassFish won't do
> anything
> > about this, so users should implement those for themselves?
> >
> > -Wonseok
> >
> > On 8/9/06, *Adam Bien* < abien_at_adam-bien.com
> <mailto:abien_at_adam-bien.com>
> > <mailto:abien_at_adam-bien.com <mailto:abien_at_adam-bien.com>>>
> wrote:
> >
> > I discussed the following idea already with craig at the
> JAOO
> > 2005.
> >
> > Problem:
> >
> > If you detach a persistent entity send it to client, then
> > back, the
> > "before image" is lost.
> > In this case you need a version number or timestamp. You
> can
> > have a
> > problem, in case you are working with a legacy database - it
> > is often
> > hard or not allowed to change the schema.
> >
> > Now the following idea: why not send the before image
> together
> > with the
> > entity?
> > As a improvement also only the where statement could be sent
> > over the
> > wire. This should be sufficient to detect the collisions,
> >
> > I'm not sure, whether this list is the right place to
> discuss
> > the things
> > - but I think such a feature would be unique...
> >
> > greetings,
> >
> > adam
> >
> > --
> > Dipl. Inf. adam bien
> >
> > BEA Technical Director
> > Sun Certified Java Programmer
> > Sun Certified Enterprise Java Architect
> > Sun Enterprise Java Trainer
> >
> > Mobile: 0049(0)170 280 3144
> > eMail: abien_at_adam-bien.com
> <mailto:abien_at_adam-bien.com> <mailto: abien_at_adam-bien.com
> <mailto:abien_at_adam-bien.com>>
> > Homepage: www.adam-bien.com <http://www.adam-bien.com>
> <http://www.adam-bien.com>
> > Weblog: http://www.adam-bien.com/roller/page/abien
> > <http://www.adam-bien.com/roller/page/abien>
> > ----------
> > Book author:
> >
> > Enterprise Architekturen
> > entwickler.press 2006
> > ISBN: 393504299X
> >
> > and Enterprise Java Frameworks,
> > J2EE Patterns, J2EE HotSpots and Struts.
> >
> >
> >
> >
> > --
> > Wonseok Kim
> > Senior Developer, TmaxSoft
> >
>
>
>
>
> --
> Wonseok Kim
> Senior Developer, TmaxSoft