peter royal wrote:
...
I don't like having this as a singleton with static methods. I need
to be able to have multiple instances in a single JVM, and this
breaks that. The new setup is a monolithic, which while great for new
users, makes it harder to tweak the behavior. The old setup was a
composition of multiple components, and I preferred that API style.
I see where you're coming from I agree. In my last email I was
considering ease of API adoption for new comers over existing users.
If the new IoService was merely a layer on top of the old API, I'd be
more in favor of that.
+1
* No more transport-type specific property getters and setters. Now
we use IoAddress properties and the user-defined attributes in
IoSession. For example:
I liked the transport-specific getters and setters, since it provided
a level of type-safety when setting the properties, and you knew what
you were setting (there was javadoc on the methods, no chance of mis-
typing the attribute name, etc).
Again +1 here. Man Peter I totally overlooked these points: thanks for
chiming in.
...
The changes look like they help simplify usage of MINA in simple
scenarios.. the examples are certainly much simpler, but for users
that might have a more complex integration, they seem to be somewhat
of a step backwards (my .02)
I'm starting to agree. I'm a bit worried about the singleton with
static methods for using MINA in containers now. This change makes life
easier for the new comer but becomes more restrictive for power users.
Alex
