I (as Java EE developer/architect) would also prefer annotations.
Otherwise we should think about something like XDoclet support, which is
not a lean solution.
JBoss guys are also working with annotations (it should be not a sample
for a best practice, but only a sample :-)).
XML should only override annotations,
thanks,
adam
Sanjeeb Kumar Sahoo schrieb:
> 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
>