Hi, Jerome
Aside from the vendor specific part, my other comments on defining
runtime annotations:
1. We will probably never be able to replace all the runtime xml
elements with annotations.
2. For the most commonly used runtime xml element "jndi-name", we
already have a way to define it outside of the runtime xml files: using
"mapped-name" element in standard deployment descriptor or mappedName
annotation attribute.
I agree it's a pain having to define runtime xml for just one for two
elements, but is it possible for us to come up with a small set of most
commonly used runtime xml elements? Like this resource-adapter-mid
element mentioned in the original email, it probably won't end up in
this set?
Thanks,
- Hong
Jerome Dochez wrote:
> Hi Kim
>
> This problem can be reduced by making the appserver specific
> annotations available as a small jar file. Applications that wish to
> remain portable just need to bundle this jar file (in the .ear lib
> directory for instance) and these annotations will just be ignored by
> other application server. I think both models have values but I have
> to agree that having to define xml files just for 1 or 2 elements is a
> bit of a pain...
>
> Jerome
>
>
> Wonseok Kim wrote:
>
>> 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...
>> - Wonseok
>>
>> On 8/11/06, *Sudhir Prabhu* <Sudhir.Prabhu_at_sun.com
>> <mailto:Sudhir.Prabhu_at_sun.com>> wrote:
>>
>> In my opinion we should plan for that in 9.1 or 9.2. Or else just
>> for
>> one or two elements I am forced to have a sun-ejb-jar.xml. :(
>>
>> Sudhir
>>
>>
>> Binod wrote:
>> > Do we have SJSAS-specific annotations planned for 9.1 or 9.2?
>> >
>> >> There is no such annotation for resource-adapter-mid in MDB,
>> AFAIK.
>> >> Portable Annotation types usually map to elements in standard
>> >> descriptors like ejb-jar.xml. I haven't seen any SJSAS-specific
>> >> annotations that map to elements in sun-*.xml.
>> >>
>> >> Cheng
>> >>
>> >>
>> >>
>> >>
>> >> Sudhir Prabhu wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I am trying to develop an EJB30 style MDB. I am able to most
>> >>> activation-config elements as annotations. How do I specify the
>> >>> resource-adapter-mid element as annotation?
>> >>>
>> >>> The reason I want to specify this element is because I want
>> to use
>> >>> the Generic JMS RA instead of the default jmsra. At present
>> just for
>> >>> this one element I am forced to use sun-ejb-jar.xml.
>> >>>
>> >>> Thanks
>> >>> Sudhir
>> >>>
>> >>>
>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>> >>> For additional commands, e-mail:
>> dev-help_at_glassfish.dev.java.net
>> <mailto:dev-help_at_glassfish.dev.java.net>
>> >>>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>> >> For additional commands, e-mail:
>> dev-help_at_glassfish.dev.java.net
>> <mailto:dev-help_at_glassfish.dev.java.net>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>> > For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>> <mailto:dev-help_at_glassfish.dev.java.net>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>> <mailto:dev-help_at_glassfish.dev.java.net>
>>
>>
>>
>>
>>
>> --
>> Wonseok Kim
>> Senior Developer, TmaxSoft
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>