Well, let's decide on something. Personally, I think ejb:persistence is
exactly what it should be, since we talking about _EJBs_ here, nothing else.
The changes being made are going to be in templates that use tags like
, so let's not fool ourselves in to thinking that we can come up
with some
Making new tag handlers would be nice and fun, but maybe we should also make
still be able to support a comma seperated list?
Then the template author can decide what is most "fun" or whatever.
As for the official tag names, we should settle on something soon. I'm fine
with all suggestions so
gt; >
> > Added: core/resources/xdoclet/ejb/vendor
> > pramati-j2ee-server_3_0.dtd pramati-or-map.j
> > pramati-or-map_3_0.dtd pramati.j
> > Log:
> > committed Pramati app server support (thanks to Patrick Lig
>What do you think about @db:mapping instead of ejb:persistence? We can
>support JDO too for example. I really prefer this one.
Agreed.
>Agree. The only thing which is worth some thoughts is how to implement
>this fallback mechanism so that the template files are not messed up
>with lots of if/
rd" 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
Ara, thanks for the Pramati commits!
Any chances of that WL change going in too? I think that there should
actually be more changes that I made, but this change at least gets CMP 1.1
support working correctly. I found that the weblogic-cmp-11-finders.j
template seems totally bogus to me, as it
Well, what you say doesn't seem to be what I've experienced. I'll play with
it some more, but it could be screwed up. Has anyone actually used this?
-Pat
>From: "Ara Abrahamian" <[EMAIL PROTECTED]>
>To: "'Patrick Lightbody'" <
(GMT Standard Time)
>
>A wise old hermit known only as Patrick Lightbody <[EMAIL PROTECTED]>
>once said:
>
> > I am using destinationfile and specifying a file. It isn't a problem
> > with file locations, I don't think. It seems that basically any
> > elemen
