Hi there,
I have a EJB2.0 CMP application that runs fine under ResinEE, using XDoclet to
generate the resin.ejb descriptor. Now I'm trying to get it to work under Orion
2.0.2 and I'm having difficulties setting up the relationships between my Beans,
as the documentation is scarce. I've been browsing the web, reading all the
documentation, mail and forum messages that I've been able to find but I've
found no clear answer. I've also looked at the template source to find out the
attributes that are being used, etc, but as the Orion-specific ejb descriptor is
also not very well documented on its own, it's becoming a nightmare :).
Is there any place where I can find more information about how to configure the
different kind of relationships appropriately for Orion? Any samples I'm not
aware of? Is anybody actually using XDoclet to develop Orion applications?
I'm using XDoclet1.2b3(at least that's what the download link said, even though
the jar files all read whatever12b4.jar)
Thank you very much,
D.
PD: Final goal is to have an EJB2.0 CMP application that is able to run
"untouched" under various containers, as a proof of concept. And if there's
interest enough, I've also been given permission to release it as open source
so, hopefully, it could also help others when using XDoclet and EJB.
--
This message was sent using Sake Mail, a web-based email tool from
Endymion Corporation. http://www.endymion.com/products/sake
I would vote for the "shitload of methods" approach, though I'm not sure it
would really be that many - I guess it depends on how many "weights" of
ValueObjects the developer defines. Something like:
getFooValue();
getFooLightValue();
Is this (upgrading facades to use valueobjects) something that you were thinking
about doing at some point, or are you looking for a volunteer?
Thanks,
David
Mensaje citado por Konstantin Priblouda <[EMAIL PROTECTED]>:
>
> --- David Ward <[EMAIL PROTECTED]> wrote:
> > The xdoclet dataObjects are not new; in fact, they
> > are the old way that has been
> > replaced with valueObjects. However, to the best of
> > my knowledge, noone has
> > updated the xdoclet facade stuff to use
> > valueObjects. Maybe because of
> > backward-compatability? Not sure... Maybe there
> > should be an attribute that
> > allows one to specify dataObjects or valueObjects
> > for the generated facade(s).
> >
> > Personally, I would LOVE to be able to use xdoclet
> > valueObjects in my
> > xdocletFacades!!!! It would make things so much
> > easier and complete.
>
> It was not updated, it was designed ( by me ) to be
> used with data objects.
>
> Value objects constitute a problem - there could be
> more than one. So facade generation has to decide
> which one to use.
>
> So there is a big question - how do you like this
> problem to be solved?
>
> - one facade per value object ( do not like this idea,
> ejb suffers from too many classes )
> - shitload of methods in single facade determining
> what value object to use
> - generate functors ( maybe as inner classes of the
> facade ) to strip specific value objects off
> collection and pass them for every invocation
> (would work nice for collections, because result is
> untyped, but what shall be done with single object
>
> finders? )
>
>
> I never developed support for value objects, because
> they major advantage was CMR support, but personally I
>
> find that CMR is really confusing - that's why I
> moved to use hibernate instead of Entity beans...
> ( IMHO it has a lot of advantages over Entity beans...
> )
> regards,
>
> =====
> ----[ Konstantin Pribluda ( ko5tik ) ]----------------
> Zu Verst�rkung meines Teams suche ich ab Sofort einen
> Softwareentwickler[In] f�r die Festanstellung.
> Arbeitsort: Mainz
> Skills: Programieren, Kentnisse in OpenSource-Bereich
> ----[ http://www.pribluda.de ]------------------------
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>
---------------------
David Ward
[EMAIL PROTECTED]
http://www.dotech.com
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
