> I never really liked this idea. By this I'm assuming you are referring to the JavaBean listener interfaces (PropertyChangeListener and PropertyVetoChangeListener) as a possible solution.
> I think you should provide a concrete > setPostalCode (String code) method and if the data is valid you would > call setPostalCodeField (String code) or setPostalCode_(String code). The are two limitations that make this impossible currently: - JBoss doesn't generate code that extend the abstract entity beans for the creation of instances later. My understanding is that it introspect them and create a property set of key/value which then intercepts invocations for the contained entity beans. - The spec requires CMPs to be abstract objects and enable the container to provide an implementation of each bean. > Alternatively, there are types of validation that are really an aspect > (deployment environment specific). For example, a company specific > mail route field. The validation of this field would depend on the > deployment environment (which company it is deployed at). In this case > I see an interceptor, possibly a Bean Scripting Framework interceptor. I will study this further, it should add great dynamism onto the entire implementation. > What I am getting at is I think this proposed solution is a hack and I > personally would not accept the patch, but the user community has > convinced me to include things I consider hacks. Let's give it a try, critic it, improve it further. It might become a nice feature. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
