Hi,
I guess the remote.j and local.j have mistakes:
<XDoclet:ifHasMethodTag tagName="ejb:interface-method"
paramName="view-type" paramNum="0" value="remote">
ifHasMethodTag doesn't have 'value' attribute. It just checks whether
the tag+param exists and doesn't check the equality of the value. It
should use a combination of ifHasMethodTag and ifMethodTagValueEquals.
Also I don't feel comfortable with the view-type semantic. I'm lost,
does the view-type have to be there always for each
@ejb:interface-method declaration? It's ugly for EJB 1.1 users
(including me). We should make it optional. Here is my old comments in
that regard:
<<
- Make @ejb:interface-method alone without type valid. It will look at
bean's view-type and expand to local if bean's view-type="local" and
remote if "remote". For a bean with view-type="both" (or maybe we should
change it to "local,remote"? I like comma-separated style, it's
consistent with other parts) expose the method to both local and remote
homes. This is the preferred use case (not hard-coding remote/local in
every method declaration when it's already specified for the whole
bean).
- If user declares something wrong (bean=local, method=remote) then
report an error.
- For local+remote, there won't be a need for a comma-seprated type
param like this: @ejb:interface-method type="local,remote" Or multiple
@ejb:interface-method tags as an alternative. If bean's
view-type="remote,local" and you want the method only exposed to local
interface then put a @ejb:interface-method type="local" there. If you
want the method for both remote and local just don't put any type param
there.
>>
Also I haven't got clear responses whether the following suggestion is
approved/discarded/implemented (regarding generate="true|false":
- If a types such as int, Integer, Object and so on -> obviously do not
generate
- If RootDoc.classNamed( packagename + fullClassName ) != null and the
returned ClassDoc hasTag xdoclet-generated then generate="true".
Obviously it will be functional if user added gen-src to the fileset,
otherwise it won't find the ClassDoc. Probably we should encourage user
to do so and follow this rule in samples too.
- If previous test failed then use generate param.
PS: What should we do with weblogic support? It's outdated. Should we
simply find/replace old @tags and make it use new @tags? I guess for
v1.0 we have to deliver it whatever it is. Also I locally have a
relatively complete orion support which I'll try to make a bit better
and commit. Some bug-fixes, doc updates, wl/orion updates and we're
ready for v1.0.
Please express your thoughts about the above items. And if they are ok,
they let me know if you have time for implementing any of them.
Ara.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/xdoclet-devel
