The reason I implemented it this way is because in many cases, the JSP attribute type in the base class was not String. However in JSP 1.2, the EL expressions are Strings, so the BeanInfo for the JSP tag class has to associate the attributes with String properties. I then made the setter method for the String property convert the value to the correct type and then call the base class setter method.
Hmm... I guess that kinda makes overriding things rather hard doesn't it! Is it likely that all of the attributes will eventually become strings on the base classes at some point in the future?
The only way you could reduce the number of classes would be to find a tag class whose attributes were all String properties. You could then remove the BeanInfo class associated with the EL tag class, remove all the properties in the subclass, and reference the base class setters directly. Frankly, I don't see it being worth it.
A consistent approach is probably better than to do some one way and some another. Your current approach is very consistent and was simple to figure out.
It's unfortunate that you're using a brain-damaged container, but if it's having problems with this relatively "low-level" aspect of bean management, I wouldn't be surprised if you spend more time trying to figure out hacks to the container than writing productive code.
Corporate standards are a wonderful thing... "Let's buy this expensive, lame container, even though a good, free one is available!"
Thanks for the info. -- Cheers, Derek
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
