RE : [Springframework-developer] Summary of pending points

[JP P. <jp....@ti...>]

Hi Juergen,

You are everywhere these times :-). Clearly, the framework gained a much
having you with it. That has to be said. Thanks for all this work and
explanations.

When I updated the framework many hours ago, I guessed you were working
on multiples Html values.


>>>Ad 1) As you said, I think it's behaving in a clearer way now.
Unfortunately I don't have an idea on how to properly add new attribute
keys in child definitions yet, but I guess we can live with the current
restriction.

Absolutely.

 
>>> Ad 2) Do you have some stacktrace or the like for this particular
JBoss crash? If JBoss had a good classloader architecture, it shouldn't
matter if a web app initialized its own Log4J instance or not. This
works nicely with Tomcat 4.1 for instance, with multiple webapps that
each have their own Log4J instance, and even if Tomcat itself logs via
Log4J.

Just here is the problem. The last logging line tolled that the
application was undeployed. After that, JBoss was no more able to log
anything. But it's not the log4j initialization which was problematic,
just the listener. Now, I setup the configuration, but don't use the
listener and all works fine. 
 

>>> Ad 3) I haven't thought about that in depth, as I'm mainly using
Hibernate these days. But it seems to me that simply using a
MappingSqlQuery instance per request should solve the problem. It's not
really about creating many such instances I guess, as they are pretty
lightweight. Do you have a particular reason for wanting to reuse
MappingSqlQuery instances in this case?

You're right that using a new instance per request solves the problem. 

Nevertheless, it's not about a few particular requests, but almost all.
In addition to the class creation, it's also the prepared statement
re-creation and re-compilation. It's possible anyway that the gain is
not so high. But as the job is done for me, I prefer continue to reuse
as so it can only be faster and has no additional risk.
 

>>> Ad 4) On the occasion, I've just implemented a solution for this
(already committed). It doesn't convert multiple values to a CSV String
in the first place, like you suggested, but rather converts them
straightly to a String array. "getParametersStartingWith" performs the
check and returns Map instead of Properties now. So if you want to bind
multiple values for the same parameter to a bean, you have to make the
respective bean property of type "String[]". The array will contain a
single String if there is just a single value. If the property is not of
that type, you will get a "typeMismatch" error when binding a request
with multiple values for that parameter. That shouldn't matter though,
as multiple values will only occur in special circumstances. Note that
converting such a String array to other types would be a job for the
BeanWrapper then, it simply gets a String array as parameter value. Does
that match your requirements?

Perfect.
 

>>> Ad 5) Your new CRUD controller sounds interesting. I'm looking
forward to have a look at it!

As often, I don't know all the subtleties of the framework. It is
certainly possible to make more re-use from the framework. Even if the
controllers could contain clumsy parts, they can be a pretty good
starting point. So I will put them in the sandbox for letting interested
people have a first look. Even in their current status.

Regards,
Jean-Pierre