I see what is wrong, this is something that can easily be fixed in the bpm4struts cartridge
what you did is place the controller in a different package that the use-case, but the use-case kinda expects the controller to be in the same package since it does not fully qualify its name I'll commit the fix when I'm back home and have access to the AndroMDA repo btw, I would always put the controller with the use-case, it's a good practice .. it makes no sense splitting up packages based on decisions made on another level of abtraction, in other words: only use business/domain words as packages (all accept the company namespace prefix of course), nevertheless I will support your way of modeling (klant is koning :-)) since you won't be exposing 'Classes' or 'UseCases' to any component the split is useless (actually, it's bad practice which is 'supported' by many big companies, just look at the JDK code, or Eclipse proposing to name interfaces with a leading capital 'I' ..) -- Wouter Zoons - [EMAIL PROTECTED] http://www.andromda.org/ _________________________________________________________ Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=3522#3522 Posting to http://forum.andromda.org/ is preferred over posting to the mailing list! ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Andromda-user mailing list Andromda-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-user
