> > Hi Diogo, Hi Ive
> > (I started a new thread as this is no longer about building) > > >> btw, if you've been using the rest of EJB specific plugin fell free to > >> shot your comments > > > I've just ran XDoclet2 on a project I created about 3 years ago, > containing > 300 EJB's (of which about 150 CMP Beans using CMR intensively) and I ran > into a few compatibility issues: Some plugins are not build yet. You might be having problems using cmp using cmr... Compating to xd-1 (ejb core plugins...) entitybmp entitycmp entityfacade dataobject are not ported yet.. > > > 1) We used to define the persistent fields as follows > * @ejb.persistent-field > * @ejb.persistence column-name="TREE_COD" > or even using the "ejb.persistence" tag only. > > The new system only supports "ejb.persistent-field" at method level. This > looks correct to me, but it breaks backwards compatibility -> I don't know > what should be done about this (maybe add an explication to the > compatibility page?) Same tags were split into two to take advantage of tag validation ejb.persistent and @ejb.persistent-field ejb.value-object and ejb.value-object-field and so on.. I don't recall atm if ejb.persistence is supported, but I do think that they're related to that unported plugins yet. > > > 2) The "ejb.data-object" used to have (at least) the following parameters: > "container", "setdata", "generate" Not all tags have been updated as xd-1 evolved in parallel in xd-2. I mean by this: The tags were imported in a time that those fields could not maybe available yet. Whenever I find tags supported in xd-1 not declared and supported in xd-2, I make my effort to include those... Lots of navigations through xd-1 src code... However, as dataobject plugins isn't done yet, I haven't done a analysis there. > > I don't remember the details, but they where needed although we where only > using value objects. I currently just removed them and all seems to be > fine. > > > 3) The "ejb.finder" tag used to support a "max-elements" attribute (which > was IMHO only used by container specific plug-ins). ahhhhhh... I'll catch there then :| > > Would it be possible to add this again? If not, I'll have to duplicate all > finders with a WebLogic specific version (I can do it myself if you > prefer) It's ok by me, I would prefer to add it there only if it's used at more one container specific plugin. > > > 4) The "ejb.value-object" tag can no longer be used at method level -> > replaced by "ejb.value-object-field". > > Again, this looks correct, but it breaks backwards compatibility. Indeed, a compatibility page for ejb is also needed. > > > 5) The new "ejb.value-object-field" doesn't support the manage & type > attributes. > > manage: it's possible that I implemented this 'manage' myself a very long > time ago (shame on me for not remembering), but it was useful: when set on > a > value-object-field representing a CMR field, it allowed to skip updating > the > related beans when calling setXXXValue() > > type: I don't remember why this was needed, but in our code this used to > be > set to "Collection". > > I currently just removed both fields. It could be an addon to ValueObjectPlugin... > > > 6) We sometimes use the value "both" for the "view-type" attribute of > "ejb.create-method", while it now only supports "local" & "remote" As I recall, if you don't set anything it will be all bean supported vews. It can be changed to support "both". > > The value "both" should be added & implemented as I don't have an > alternative. Can you do so (the EJB plug-in has a few failing tests, so I > don't dare to change myself) I could check for it this weekend, no promise. I have lot's of uncommitted code, you get the point :D > > > Regards, > Ive Hellemans > HI Quality Software > ----------------------------------- Diogo Bacelar Quintela EF - Tecnologias de Informação, Lda. Av. António Serpa, 26 - 4º Dto. 1050-027 Lisboa, Portugal
smime.p7s
Description: S/MIME cryptographic signature
