-----Original Message----- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: 12 March 2003 10:27 To: Cactus Developers List Subject: Re: cvs commit: jakarta-cactus/integration/ant build.xml
Hi Vincent,
yeah, I've noticed the failing tests :-)
I've also started trying to understand the code and refactoring some weird-looking stuff, but I'm starting to get the feeling that the approach chosen in the WebMerge class isn't quite up to the job. Have some rough ideas for a cleaner, more flexible design that also allows me to implement the nested <redirector> elements, so I might be committing some drastic changes in the next couple of days.
Cool! Just as long as it easily merges web.xml files without introducing a new dependency on another external jar... :-)
Right, only DOM L2. Don't we all love the API? ;-)
Note that ideally we also need to support the following use case:
Cactus provided web.xml -----------------------
<servlet> <servlet-name>ServletRedirector</servlet-name> <servlet-class>o.a.c.server.ServletTestRedirector</servlet-class> </servlet>
User provided web.xml ---------------------
<servlet> <servlet-name>ServletRedirector</servlet-name> <init-param> <param-name>param1</param-name> <param-value>value1 used for testing</param-value> </init-param> </servlet>
and the merged result would be:
<servlet> <servlet-name>ServletRedirector</servlet-name> <servlet-class>o.a.c.server.ServletTestRedirector</servlet-class> <init-param> <param-name>param1</param-name> <param-value>value1 used for testing</param-value> </init-param> </servlet>
For such input, the current code would insert the servlet twice, AFAICT.
The first goal would be to make the WebMerge class "smarter" about web.xml. Currently it just has the names of the elements to merge and whether each element can exist multiple times -- in a somewhat weird matrix. That approach is simple, but the code is hard to understand and only supports simple use cases, IMHO.
One scenario I was thinking about is adding refs to the descriptor that should only be there in "test mode". For example, I've done an application that gave the web-app a local-view of all the beans for testing, but allowed only remote access to the facades in production. So I'd add tons of <ejb-local-ref>s to the test descriptor. OTOH, using XDoclet is probably better in that scenario.
A good test case is the web.xml in the integration Ant which needs to be split into 2: - the cactus provided web.xml - a "user" web.xml provided by the servlet sample project
Okay
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
