> Later, if you can provide me by email your big beans "test case" I could > test some of this "slow-movers".
I'll see what I can do. >> PS: Another improvement might be to cache the RelationManager in the >> EjbUtils > As I recall, the relationManager construction receives a metadata Collection > as parameter. If you simply cache it, how could you guarantee it's working > on the same metadata... And every plugin instantiates EjbUtils... surely you > don't want to cache it "statically".. I was thinking on removing the metadata attribute, and using the one stored in the EjbUtil.config attribute instead -> seeing that uses the cached version we are sure it's allways the same. Should somone ever want to use it for a different set of metadata, they can construct a second EjbUtil with a separate EjbConfig. > PS: you've pointed out some important unfound bootlenecks. That's the > problem of being the on the bleeding edge (I suppose that because of the > lack of server DD's, not much people is already using this on medium to big > projects) Indeed - this is a legacy project that needs to be upgraded to WebLogic 9 and we didn't have much choice seeing XDoclet 1 doesn't support that. > You have to try to make the efforts to separate your changes in smaller > patches. It would be great if you could commit some of the changes, because next patch will be on the same files again (which is the mess I was talking about). I'll submit a patch for: * caching the RelationManager as discussed above * modifying the constructors as described earlier in this thread. as soon as other patches are (in one form or the other) applied in CVS. More tomorrow, time to go out :-) Ive _______________________________________________ xdoclet-plugins-interest mailing list xdoclet-plugins-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-plugins-interest
