Rather than using an additional beaninfo class for each ELFooTag class would it not be simpler for the ELFooTag classes to override the setFoo methods of the associated FooTag class they are extending?
i.e.
in FooTag we have an attribute foo with setFoo and getFoo methods
currently in ELFooTag we have an additional attribute fooExpr with setFooExpr and getFooExpr methods and an associated beaninfo class to map calls to setFoo into calls to setFooExpr
alternatively in ELFooTag we could include fooExpr as it currently exists but simply override setFoo so that it instead sets fooExpr and then rely on the current evaluateExpressions method to compute the current value and call super.setFoo() with the evaluated value.
I ask for two reasons: First, the alternative approach seems somewhat simpler (i.e. 50% fewer classes with the removal of the beaninfo's). Second, because I'm using a broken app server (not by choice) that doesn't process the beaninfo classes properly (if it processes them at all) and the alternative (overridden method) implementation does seem to work.
I've hacked in overriding setFoo methods and associated super.setFoo calls in evaluateExpressions in a couple of test cases and it seems to work in my broken app server at least.
Thanks for any info! -- Cheers, Derek
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
