Re: [Xdoclet-user] Re: [Xdoclet-devel] Surprise!

Rickard wrote: > Aslask blah, sorry 'bout the typo.. :-( /R ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

[Xdoclet-user] Re: [Xdoclet-devel] Surprise!

Aslak, [EMAIL PROTECTED] wrote: > I just spent 2 hours getting the multiline tooltips to work. Absolutely fabulous! This is very promising. I can only hope that we will be able to keep the XML files updated. Other than that, this has great potential! /Rickard -- Rickard Öberg Author

[Xdoclet-user] Re: [Xdoclet-devel] Surprise!

Aslask [EMAIL PROTECTED] wrote: > I just spent 2 hours getting the multiline tooltips to work. Absolutely fabulous! This is very promising. I can only hope that we will be able to keep the XML files updated. Other than that, this has great potential! /Rickard -- Rickard Öberg Author

[Xdoclet-user] Dirty flag and ejbStore

deal, but I'm curious about this change. The last version of XDoclet I used had an if-statement on the dirty flag before calling super.ejbStore(), and I would prefer that. /Rickard -- Rickard Öberg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Com

Re: [Xdoclet-user] OffTopic: Local beans and Orion

ing about this privately. Thx. /Rickard -- Rickard Öberg ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] OffTopic: Local beans and Orion

Hani Suleiman wrote: > Locals don't work very well with 1.5.3, 1.5.4 will have full locals support, > it should be out...erm...soon! Alright, I'll just have to roll my thumbs for a while then :-( /Rickard -- Rickard Öberg

[Xdoclet-user] OffTopic: Local beans and Orion

Hey OffTopic: has anyone gotten Local EJB's to work with Orion? Doesn't seem possible... Does anyone know what servers currently support Local EJB's? Thanks, Rickard -- Rickard Öberg ___ Xdoclet-user mailing list [EMAIL P

[Xdoclet-user] Compile problem

Hey I can't get XDoclet to run now. I get an IncompatibleClassChange error all the time. Is it just me, or are there any new things that broke things? Does it work for everyone else? /Rickard -- Rickard Öberg Chief Architect, TheServerSide.com The Middleware Co

[Xdoclet-user] BMP and EJB2.0

ot be generated when the spec is set to 2.0. /Rickard -- Rickard Öberg ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] PK generation and create return value

Ara Abrahamian wrote: > Rickard, > It's done. I also changed samples, CustomerBean.create returns Object, > PersonBean sets ejb:pk generate="false", so no PersonPK is generated, > but CustomerPK is generated with all pk fields including pk fields of > parent PersonB

Re: [Xdoclet-user] PK generation and create return value

This is basically that, i.e. you can use Object as return value of creates. /Rickard -- Rickard Öberg Chief Architect, TheServerSide.com The Middleware Company ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] PK generation and create return value

rate pk class according to > pattern param or ejb:pk class/package/etc attributes, but > use return type as the pk class in ejb-jar.xml anyway. > > As before ejb:pk generate is true by default, but priority is to look at > ejbCreate return type and then entitypk/ejb:pk class/ej

[Xdoclet-user] (OFFTOPIC) Entity BMP, EJB2.0

o change as new EJB relationships or properties are introduced. Instead the visitors are updated to handle that, but they are supposed to be more "alive" (in terms of evolution) IMO, so that's ok. /Rickard -- Rickard Öberg Chief Architect, TheServerSide.com The Middleware Compa

Re: [Xdoclet-user] PK generation and create return value

bCreate methods must match the class specified in ejb-jar.xml. I am running Orion currently, and it complains that the ejb-jar.xml setting is "ForumPK" and the return type is "Object". /Rickard -- Rickard Öberg Chief Architect,

Re: [Xdoclet-user] PK generation and create return value

Rickard wrote: > Is there any way I can have XDoclet generate a PK class, but use Object > as return value of ejbCreate? I.e. I need the generated PK class, but I > also need to have Object as return value of ejbCreate, and thus need > "java.lang.Object" set as PK cl

[Xdoclet-user] PK generation and create return value

is in java.lang then don't generate PK, *unless* it is java.lang.Object (Just tried this) But then the generated class becomes java.lang.Object, which is obviously wrong. argh... how do I set one pk in the XML and another name as the generated name?? /Rickard -- Rickard Öbe

Re: [Xdoclet-user] Entity BMP, EJB2.0

it for stability only (feature tests have been done with XML already), and use that for production. In this way I get the rapid development style of using XML, and the scalability and transactional features of using JDBC. Makes sense? /Rickard -- Rickard Öberg Chief Architect, TheServerSide.

Re: [Xdoclet-user] Entity BMP, EJB2.0

user info from various backends, such as RDBMS or LDAP or XML or..? IMHO there are vital points missing in todays toolkit in order to allow wide reuse of components such as those you outline. These holes will be filled, but IMHO they're not right now. Good luck though ;-) /Ric

Re: [Xdoclet-user] Entity BMP, EJB2.0

on and perhaps this isn't the exact right list > but I look forward to more information as your work progresses. Watch TSS, and stay tuned :-) It's looking good, oh yeah... /Rickard, coding, in a hotel in Austin/Texas -- Rickard Öberg Chief Architect, TheServerSide.com The Midd

Re: [Xdoclet-user] Entity BMP, EJB2.0

return ERROR; else return SUCCESS; } -- So, the command just passes itself to the creation mechanism outlined above, where it is used to initialize the new entity. And so on and so forth :-) Was this answer what you were aski

Re: [Xdoclet-user] Entity BMP, EJB2.0

where the database stuff is done through delegation. Way way better. /Rickard -- Rickard Öberg Chief Architect, TheServerSide.com The Middleware Company ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] Entity BMP, EJB2.0

an very easily switch persistence mechanism by simply making a factory mechanism for the DAO handlers :-) So, for example, during dev I'd use a simple XML storage, or db4o, and then for production I'd switch to JDBC, but without having to change my code at all. Aaaanyway. Back to codi

[Xdoclet-user] Entity BMP, EJB2.0

s stuff not used for EJB2? I need it there too. /Rickard ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] advice on how to minimize client-side impact?

ws that it can conserve subsequent requests to various SSBs and > send the request in a single call? Or you mean I can write an action > that calls various SSBs? Your action can call various SSB's without any additional overhead, since all the calls to them are local anyway. /Ricka

Re: [Xdoclet-user] advice on how to minimize client-side impact?

saying this for some time now, and this pattern is indeed discussed on TheServerSide, right here: http://www.theserverside.com/home/thread.jsp?thread_id=9257 /Rickard -- Rickard Öberg ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] advice on how to minimize client-side impact?

ized manner. Plus, if your client is an applet there is a minimal download of about 10k for the WebWork client instead of having to download huge EJB-packages or XML/SOAP parsers. /Rickard -- Rickard Öberg ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Re: [Xdoclet-user] advice on how to minimize client-side impact?

less likely. The way to do that is to try and minimize the impact a particular decision has on your architecture and code, and to minimize the amount of code you need to do to solve a particular problem, since it will then be easier to change. /