OK, so any thoughts on starting to make all the templates look for:

Class-level:
@ejb:persistence table-name="foo" datasrouce="jdbc/FooDS"

method-level:
@ejb:persistence-field column="bar"

All the templates should try the app server specific tags first 
(@orion:persistence), but if those tags don't exist, I think they should 
fall back on these tags.

Likewise, some templates don't utilize tags that (maybe) they should. For 
instance, orion.j doesn't set the JNDI name found in @ejb:bean jndi-name, 
even though this is totally a "standard" attribute.

It would be _really_ beneficial to the xdoclet project if these kinds of 
things were agreed upon.

-Pat

>From: "Patrick Lightbody" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: RE: [Xdoclet-user] Proposal - ejb:persistence tags
>Date: Mon, 04 Mar 2002 01:13:00 -0800
>
>I'll take the rest of this discussion to xdoclet-devel, but just a quick
>answer to your questions:
>
>As I said, there should be support in the template files for the vendor
>specific tag (orion:persistence) but also a standard tag. Following the
>80/20 rule, 80% of xdoclet users will probably be just fine using
>ejb:persistence, and the remaining 20% would be taken care of by using the
>vendor's tag. The main point here is that the templates need to be
>standardized to support both.
>
>-Pat
>
>
>>From: "Ara Abrahamian" <[EMAIL PROTECTED]>
>>Reply-To: <[EMAIL PROTECTED]>
>>To: "'Patrick Lightbody'" <[EMAIL PROTECTED]>,
>><[EMAIL PROTECTED]>
>>Subject: RE: [Xdoclet-user] Proposal - ejb:persistence tags
>>Date: Mon, 4 Mar 2002 12:16:18 +0430
>>
>> > OK, so I've now played with deploying xdoclet on Orion, JBoss,
>>WebLogic,
>> > Pramati, and Borland App Server. I'm going to submit my Pramati stuff
>>to
>> > be
>> > added to CVS in just a minute (BAS will come next week), but I'd like
>>to
>> > run
>> > something by everyone:
>>
>>Cool. Seems like xdoclet is replacing Sun's Deployathon ;-)
>>
>> > * @weblogic:table-name OS_PROPERTYDATA
>> > * @jboss:table-name table-name="OS_PROPERTYDATA"
>> > * @orion:bean table="OS_PROPERTYDATA"
>> > * @ejb:persistence table-name="OS_PROPERTYDATA"
>>
>>Q: what if you can use more than one table in an app server? For example
>>BAS supports this I believe. And some persistence engine allow you to
>>have 2 bean out of one table but queried by one query, etc, etc.
>>
>> > * @jboss:column-name name="id"
>> > * @weblogic:dbms-column id
>> > * @ejb:persistence column="id"
>> > * @orion:persistence persistence-name="id"
>>
>>Q: what if you can map a field to n columns? WAS supports this I
>>believe, and TopLink and so on.
>>
>> > I've written the new Pramati support to look at @ejb:persistence for
>>the
>> > class-level values of 'table-name' and 'datasource'. For method-level
>> > tags,
>> > it looks for the attribute 'column'.
>>
>>Please subscribe to xdoclet-devel and let us discuss the semantics of
>>the tags there.
>>
>> > I'd like to propose that we decide on a standard, such as this, and
>>start
>> > modifying the templates to take advantage of both. This would allow
>>for
>> > backwards compatability. If this were approved, I'd like to suggest we
>>do
>> > the same for tags/attribute combos such as jndi-name. All the app
>>servers
>> > I've worked on have a jndi-name value, but the templates don't all
>>look
>> > for
>> > "ejb:bean jndi-name".
>>
>>Yup. We should fix it for sure and I think you're a qualified guy to go
>>after harmonizing and standardizing the common stuff.
>>
>>Cheers,
>>Ara.
>>
>>
>
>
>
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>_______________________________________________
>Xdoclet-user mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/xdoclet-user




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.;


_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel

Reply via email to