Hi Christian, Thanks for your feedback
> > Hi, > today I tried BPM4Struts (latest M3 snapshot) for the first time. I want > to give you feedback about some things I've noticed: > > > 1) Using tagged values to link activity graph to use case / controller > > a) This didn't work, I did a little debugging and the cause seems to be > that > getModel().getRootPackage().getClasses() doesn't return any classes (at > leat with my model, I'am using Magicdraw 8.0SP1). > > This happens for example in StrutsActivityGraph.handleGetController() > > -> no controller classes are found. > > > Switching to setting the context with Magic Draw did the job (which is > what I tried first. But I had also some problems with it, probably some > misconfiguration) > [WZ> ] the piece of code you copied from the source is not related in any way with the fact you either use the MagicDraw feature or the tagged values, I think it is strange it fied this ... > > b) @andromda.struts.usecase.activity > It seems that the name of the diagram has to be referenced and not the > activity graph itself. If this is true then the documentation should be > more verbose IMO. > [WZ> ] really ? I would need to try this myself .. I added tests for this kind of stuff and never saw something wrong with the generated output > > > Furthermore I think that this whole context issue is a major barrier for > new users (I spent several hours trying tagged values, dealing with NPEs > and Magicdraw issues) and should be exposed in the documentation even > more than it is right now. Maybe BPM4Struts should validate the context > settings before doing anything else. > [WZ> ] can you create a JIRA issue for this ? that way I will not forget to highlight it when I update the documentation > A final note on this issue: Also one liners like StrutsActivityGraph > graph = controller.getUseCase().getActivityGraph(); > often make it hard to debug NPEs. > [WZ> ] that is true, recently I was in the process of rewriting those pieces of code, because the validation would nicely end with a message at the end (instead of a few pages of stacktrace) when you run androma on a model .. I will also eliminate these pieces of code and replace them with something more robust > > 2) web.xml > The file gets rewritten at every time. I think the file doesn't change > much from Andromda perspective, so wouldn't it be better to create it > only once? > > You would be able to customize it later on without changes being lost. > Or is there a different solution to customize web.xml > (beside changing the template of course) > [WZ> ] the reason it is overwritten is that suppose after a while you want to switch security on, you will need to have the necessary changes in web.xml, also, per new use-case you will have a new security-constraint and for every new service you call you will have a ejb-ref So the file _will_ change a lot when you have security enabled, what were you thinking of customizing ? something we could expose through the cartridge ? > > 3) controller class package > If the controller class is in a different package than the activity > graph, only the form classes referring to the controller methods are in > the right package, the controller itself is in the package of the > activity graph. > [WZ> ] create a jira issue for this .. I would need to make some time to test this kinda stuff Thanks for all this Christian, I will do my best to fix/improve these issues for the final release. -- Wouter ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
