Hi, Sahoo
Thanks for informing me. It's good to know that unknown annotations are
ignored.
But I'm not sure that unknown annotations can be ignored at compile time. If
there is any compiler option to ignore unknown annotations, it would be
better.
Anyway I worried too much :-)
Now I agree that vendor-specific annotations is good choice for
configurations and advanced features.
- Wonseok
On 8/11/06, Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_sun.com> wrote:
>
> 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> 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]
> > > *Sent:* Wednesday, August 09, 2006 11:37 PM
> > > *To:* 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>> 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>
> > > Homepage: 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
>
>
>