Hong Zhang wrote:
> 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.
I know
> 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 know
> 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?
yes this would be the plan, come up with a short list of the most common
used xml elements and provide annotations for them.
> Like this resource-adapter-mid element mentioned in the original
> email, it probably won't end up in this set?
right, we should start a list of these and keep at hands when we have
some time to spend on this...
thanks, Jerome
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>