|
Home > Archive > Apache Directory Project > January 2006 > [mina] Introducing the New API for 0.9.1.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[mina] Introducing the New API for 0.9.1.
|
|
| Trustin Lee 2006-01-22, 5:45 pm |
| Hi all,
I refactored MINA API very heavily this weekend, and now it's time to show
the result to you. Please feel free to browse my branch here:
http://svn.apache.org/viewcvs.cgi/d...ustin/mina-spi/
and here's the working examples:
http://svn.apache.org/viewcvs.cgi/d.../mina/examples/
Here's the list of notable changes:
* SocketAddress is replaced with IoAddress (org.apache.common)
* All bind/unbind/connect operation is performed via
org.apache.commin.IoService. There's no need to instantiate an acceptor
implementation by yourself. You never access
org.apache.mina.transport.*packages anymore.
* 'registry' package is removed. Instead, IoService does the similar job.
* No more transport-type specific property getters and setters. Now we use
IoAddress properties and the user-defined attributes in IoSession. For
example:
ex1) IoService.bind(
"nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",
new MyHandler() );
ex2) session.setAttribute( "receiveBufferSize", new Integer( 2048 ) ); //
org.apache.mina.common.RuntimeIOException will be thrown if this operation
fails.
* Blacklist filter uses regular expressions to detect blacklisted sessions.
* Spring integration classes changed a lot due to these changes.
* Per-acceptor/connector IoFilterChainBuilder is removed. Instead we could
implement IoService to support more attributes. For example, we could do
like this:
IoService.connect( "nio:socket:
192.168.0.1:8080?reconnect=true&reconnectRetry=3&reconnectDelay=10", new
MyIoHandler() );
Please feel free to criticize these changes. We're very open to your
feedback. More feedback, better API! 
Thanks in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Trustin Lee 2006-01-22, 5:45 pm |
| 2006/1/22, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>
> * SocketAddress is replaced with IoAddress (org.apache.common )
org.apache.common -> org.apache.mina.common
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| peter royal 2006-01-22, 5:45 pm |
| | |
| Alex Karasulu 2006-01-22, 5:45 pm |
| 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
>
>
> 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
| |
| Ersin Er 2006-01-22, 5:45 pm |
| SGksCgpPbiAxLzIyLzA2LCBUcnVzdGluIExlZSA8
dHJ1c3RpbkBnbWFpbC5jb20+IHdyb3RlOgo+
IEhpIGFsbCwKPgo+IEkgcmVmYWN0b3JlZCBNSU5B
IEFQSSB2ZXJ5IGhlYXZpbHkgdGhpcyB3ZWVr
ZW5kLCBhbmQgbm93IGl0J3MgdGltZSB0byBzaG93
Cj4gdGhlIHJlc3VsdCB0byB5b3UuICBQbGVh
c2UgZmVlbCBmcmVlIHRvIGJyb3dzZSBteSBicmFu
Y2ggaGVyZToKPiAqIE5vIG1vcmUgdHJhbnNw
b3J0LXR5cGUgc3BlY2lmaWMgcHJvcGVydHkgZ2V0
dGVycyBhbmQgc2V0dGVycy4gIE5vdyB3ZSB1
c2UKPiBJb0FkZHJlc3MgcHJvcGVydGllcyBhbmQg
dGhlIHVzZXItZGVmaW5lZCBhdHRyaWJ1dGVz
IGluIElvU2Vzc2lvbi4gIEZvcgo+IGV4YW1wbGU6
Cj4KPiBleDEpIElvU2VydmljZS5iaW5kKAo+
ICJuaW86c29ja2V0Oio6ODA4MD9yZXVzZUFkZHJl
c3M9dHJ1ZSZ0aHJlYWRNb2RlbD1ub3JtYWwm
dGhyZWFkUG9vbFNpemU9MjAmcmVjZWl2ZUJ1ZmZl
clNpemU9NDA5NiIsCj4gbmV3IE15SGFuZGxl
cigpICk7Cj4gZXgyKSBzZXNzaW9uLnNldEF0dHJp
YnV0ZSggInJlY2VpdmVCdWZmZXJTaXplIiwg
bmV3IEludGVnZXIoIDIwNDggKSApOyAgLy8KPiBv
cmcuYXBhY2hlLm1pbmEuY29tbW9uLlJ1bnRp
bWVJT0V4Y2VwdGlvbiB3aWxsIGJlIHRocm93biBp
Zgo+IHRoaXMgb3BlcmF0aW9uIGZhaWxzLgoK
SSByZWFsbHkgZmF2b3IgdHlwZXNhZmUgb3BlcmF0
aW9ucyB0byBzdHJpbmcgYmFzZWQgb25lcy4g
SG93ZXZlciBhcyBJCnNlZSB0aGUgbmV3IEFQSSB1
c2VzIG1vcmUgc3RyaW5nIGJhc2VkIGNvbmZp
Z3VyYXRpb24uCgo+IFBsZWFzZSBmZWVsIGZyZWUg
dG8gY3JpdGljaXplIHRoZXNlIGNoYW5nZXMu
ICBXZSdyZSB2ZXJ5IG9wZW4gdG8geW91cgo+IGZl
ZWRiYWNrLiAgTW9yZSBmZWVkYmFjaywgYmV0
dGVyIEFQSSEgOikKCi0tCkVyc2luCg==
| |
| Alex Karasulu 2006-01-22, 5:45 pm |
| Trustin Lee wrote:
> Hi all,
>
> I refactored MINA API very heavily this weekend, and now it's time to
> show the result to you. Please feel free to browse my branch here:
>
> http://svn.apache.org/viewcvs.cgi/d...ustin/mina-spi/
>
> and here's the working examples:
>
> http://svn.apache.org/viewcvs.cgi/d.../mina/examples/
>
> Here's the list of notable changes:
>
> * SocketAddress is replaced with IoAddress (org.apache.common )
I see you probably meant o.a.mina.common.
>
> * All bind/unbind/connect operation is performed via
> org.apache.commin.IoService. There's no need to instantiate an
> acceptor implementation by yourself. You never access
> org.apache.mina.transport.* packages anymore.
Nice I like this.
>
> * 'registry' package is removed. Instead, IoService does the similar job.
>
Hmmm I liked the registry concept. It made it clear that you could
register multiple services with MINA. But if there is now a better
mechanism then I'm all for it. Looks like this bind description string
does the job below referring to ex1.
> * No more transport-type specific property getters and setters. Now
> we use IoAddress properties and the user-defined attributes in
> IoSession. For example:
>
> ex1) IoService.bind(
> "nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",
> new MyHandler() );
This is cool. Nice step in MINA evolution. It's like a connector string.
> ex2) session.setAttribute( "receiveBufferSize", new Integer( 2048 )
> ); // org.apache.mina.common.RuntimeIOException will be thrown if
> this operation fails.
>
Hmmm why not throw an IllegalArgumentEx ... just curious why this is a
RtIOEx above. Could you elaborate?
> * Blacklist filter uses regular expressions to detect blacklisted
> sessions.
That's a nice feature and it makes sense.
> * Spring integration classes changed a lot due to these changes.
>
What do you think the impact will be to all the protocol providers?
> * Per-acceptor/connector IoFilterChainBuilder is removed. Instead we
> could implement IoService to support more attributes. For example, we
> could do like this:
>
> IoService.connect( "nio:socket:
> 192.168.0.1:8080?reconnect=true&reconnectRetry=3&reconnectDelay=10
> <http://192.168.0.1:8080?reconnect=t...connectDelay=10>",
> new MyIoHandler() );
>
Sorry I did not understand how this example explains the above. Can you
elaborate on it?
> Please feel free to criticize these changes. We're very open to your
> feedback. More feedback, better API!
Sounds like these changes further reduce the number of lines needed to
bind a MINA service. Before we had the following for the echo example:
Service service = *new* Service( *"echo"*, TransportType.SOCKET, PORT );
registry.bind( service, *new* EchoProtocolHandler() );
And now we have just this one line:
IoService.bind( *"nio:socket:*:"* + PORT, *new* EchoProtocolHandler(), *new* DefaultIoFilterChainBuilder() );
I'm seeing the improvement. I also think managing the filter chain has been simplified: it's
much cleaner now:
Before we had this for adding a logger to the chain:
*private* *static* *void* addLogger( ServiceRegistry registry ) *throws* Exception
{
IoAcceptor acceptor = registry.getAcceptor( TransportType.SOCKET );
acceptor.getFilterChain().addLast( *"logger"*, *new* LoggingFilter() );
System.out.println( *"Logging ON"* );
}
Now we have this:
*private* *static* *void* addLogger( DefaultIoFilterChainBuilder chain ) *throws* Exception
{
chain.addLast( *"logger"*, *new* LoggingFilter() );
System.out.println( *"Logging ON"* );
}
It's more concise and clearer without exposing internal details. A big fat +1 for this.
Overall I think this is a nice jump for the API. I hope it simplifies the internals as well.
Excuse me but I have to ask this do we now have this following issue sorted out?
http://issues.apache.org/jira/browse/DIRMINA-166
Really great job T! MINA keeps getting better.
Alex
P.S. I really recommend those evaluating this change look at the examples since they
really show the impact of these changes best. They clarified some points in this
email.
| |
| Trustin Lee 2006-01-22, 8:46 pm |
| Hi Peter,
2006/1/23, peter royal <proyal-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org>:
>
> On Jan 22, 2006, at 9:56 AM, Trustin Lee wrote:
>
> What was wrong with using a SocketAddress?
Of course, we could create this address scheme
(<providerType>:<transportType>:<address> ) by extending SocketAddress, but
there was no point to do so because it only causes downcasting. As you
know, you can't do anything with SocketAddress. You have to downcast it to
something such as InetSocketAddress or VmPipeAddress.
> * All bind/unbind/connect operation is performed via
>
> 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.
>
> If the new IoService was merely a layer on top of the old API, I'd be
> more in favor of that.
Actually, IoService does what you think except that it's a singleton. It is
like a ServiceRegistry. It creates acceptors and connectors for you and
encapsulated them. Except that the number of acceptor/connector thread is
one, everything is identical with the previous API. Yes, this can be a
problem, but we can make it non-singleton, of course. If we change so,
there's no effective difference between the old and the new from the
viewpoint of the object composition. It is just done by the IoService, not
by you.
> * No more transport-type specific property getters and setters.
>
> 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).
Right. Now they are gone. This approach has a trade-off you mentioned.
The advantage of user-defined attributes is that you don't need to downcast
and that it provides more flexibility. For example, let's assume that you
need to switch to new AIO transport type implementation. All you need to do
is change the providerType to 'aio' from 'nio' in IoAddress. With the old
API, you'll have to add more 'if ( session instanceof ... ) { ...
setReceiveBufferSize(...); }' sentences as you change the provider. But
with string key, it works only if the providers used the same keys.
Of course, this problem could be resolved if the authors of AIO provider and
NIO provider agreed on creating a common interface, but I think it's too
ideal.
Also, there are now 'magic' attribute name that affect the
> operation of a session that can no longer be used as attribute names
> in user code.
Yes, right. If so, we could put a prefix such as 'provider.', but I'm not
sure we need to do this in a unstable branch. Otherwise we could provide
separate attribute getters and setters, but I don't know it's advantage to
users.
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)
Please explain your complex integration scenario. We'll make sure it works
with the new API.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Trustin Lee 2006-01-22, 8:46 pm |
| 2006/1/23, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>
> Right. Now they are gone. This approach has a trade-off you mentioned.
> The advantage of user-defined attributes is that you don't need to downcast
> and that it provides more flexibility. For example, let's assume that you
> need to switch to new AIO transport type implementation. All you need todo
> is change the providerType to 'aio' from 'nio' in IoAddress. With the old
> API, you'll have to add more 'if ( session instanceof ... ) { ...
> setReceiveBufferSize(...); }' sentences as you change the provider. But
> with string key, it works only if the providers used the same keys.
>
> Of course, this problem could be resolved if the authors of AIO provider
> and NIO provider agreed on creating a common interface, but I think it's too
> ideal.
>
I forgot to mention that we could provide a standardized set of attributes
as a documentation.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Trustin Lee 2006-01-22, 8:47 pm |
| 2006/1/23, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> I really favor typesafe operations to string based ones. However as I
> see the new API uses more string based configuration.
We could change IoService throw an exception if any unknown attributes are
specified to make sure the safety. For the property values, it checks the
value is correct in runtime, so it should be fine if you run the application
at least once in most cases or run the test case.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Trustin Lee 2006-01-22, 8:47 pm |
| 2006/1/23, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>:
>
> Hmmm why not throw an IllegalArgumentEx ... just curious why this is a
> RtIOEx above. Could you elaborate?
For example, Socket.getReceiveBufferSize() can throw a SocketException. We
cannot throw an IllegalArgumentException because we didn't specify any
arguments. That's why I created a RuntimeIOException. Now we have
RuntimeIOException, so we also don't need to throw an
IllegalArgumentException from setAttribute() when a SocketException is
thrown. Of course, the RuntimeExceptions are just passed through to the
caller, not being wrapped by RuntimeIOException.
> * Spring integration classes changed a lot due to these changes.
>
> What do you think the impact will be to all the protocol providers?
No impact at all.
> * Per-acceptor/connector IoFilterChainBuilder is removed. Instead we
> http://192.168.0.1:8080?reconnect=t...connectDelay=10
>
> Sorry I did not understand how this example explains the above. Can you
> elaborate on it?
Most filters that are added to the session manager level are very generic
ones such as thread pool filter, logging filter, and etc. So we can provide
them as a parameter of the address.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Noel J. Bergman 2006-01-23, 2:45 am |
| Peter,
> 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
I haven't looked at the code, but having seen the dialog so far, you
certainly make a strong case for vetoing the changes until your concerns
are resolved.
Perhaps a set of convenience classes for MINA would address ease of use
without sacrificing more advanced use.
--- Noel
| |
| Trustin Lee 2006-01-23, 2:45 am |
| 2006/1/23, Noel J. Bergman <noel-3FWFAxrxNblBDgjK7y7TUQ@public.gmane.org>:
>
> Peter,
>
>
> I haven't looked at the code, but having seen the dialog so far, you
> certainly make a strong case for vetoing the changes until your concerns
> are resolved.
>
> Perhaps a set of convenience classes for MINA would address ease of use
> without sacrificing more advanced use.
Sure. We do our best to fulfill the needs of various users as usual. This
API is not a final version but a draft. The final shape we will get with
MINA 1.0.0 will satisfy as many users as possible.
Thank you,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Irving, Dave 2006-01-23, 5:45 pm |
| Trustin wrote:=20
>Hi all,
>I refactored MINA API very heavily this weekend, and now it's time to
show=20
> the result to you. Please feel free to browse my branch here:
> http://svn.apache.org/viewcvs.cgi/d...ustin/mina-spi/
>and here's the working examples:
>
http://svn.apache.org/viewcvs.cgi/d...in/mina-spi/exa
mples/src/main/java/org/apache/mina/examples/
> Here's the list of notable changes:
> * SocketAddress is replaced with IoAddress (org.apache.common )
I think some common form of address was needed - and this looks ok to
me.
> * All bind/unbind/connect operation is performed via
org.apache.commin.IoService.=20=20
> There's no need to instantiate an acceptor implementation by
yourself. You never=20
> access org.apache.mina.transport.* packages anymore.=20
I love the ability to use the Service provider stuff to allow dynamic
registering of service providers - this looks pretty cool to me.=20
I also hadn't seen the "getManagedSessions#(IoAddress)" before. This is
going to be very very useful!!
I suppose one can argue over singleton / non singleton - but then I
guess this is a little like how "ServiceRegistry" used to work. Of
course, like you say, there is no reason it -- has -- to be a singleton,
and it could always be changed to be non-singleton if this would help
people.
> * 'registry' package is removed. Instead, IoService does the similar
job.
> * No more transport-type specific property getters and setters. Now
we use IoAddress properties=20
> and the user-defined attributes in IoSession. For example:=20
> ex1) IoService.bind(
"nio:socket:*:8080?reuseAddress=3Dtrue&threadModel=3Dnormal&
> threadPoolSize=3D20&receiveBufferSize=3D4096", new MyHandler() );
>ex2) session.setAttribute( "receiveBufferSize", new Integer( 2048 ) );
> // org.apache.mina.common.RuntimeIOException will be thrown if this
operation fails.
Im not too sure whether I like this change so much. I think it is great
that we can configure transport properties using an easy mechanism (i.e,
string property names etc), however Im not sure that this should be the
-- only -- way to do it.
I quite like the "POJO" approach as it allows a lot of flexibility when
setting parameters (as well as offering type-safety).
However, for ease of use, I think the ability to supply such settings as
a parameter string (or what about a set of properties?) is also good.
What if you kept everything as POJOs (allowing users to go the type safe
route if they choose), and then having a "mapper" which takes the format
string (/properties map) and binds them on to invocations to the POJOs?
The advantage of that is that you can also introduce new properties
"automatically" (i.e, you don't have to write new code to do string >
method call mapping each time you add a new property).
Just random ideas :o)
> * Blacklist filter uses regular expressions to detect blacklisted
sessions.
> * Spring integration classes changed a lot due to these changes.=20
> * Per-acceptor/connector IoFilterChainBuilder is removed. Instead we
could implement IoService=20
> to support more attributes. For example, we could do like this:
> IoService.connect( "nio:socket:
192.168.0.1:8080?reconnect=3Dtrue&reconnectRetry=3D3
> &reconnectDelay=3D10
<http://192.168.0.1:8080?reconnect=3...reconnectDelay=
=3D
10> "
> , new MyIoHandler() );
> Please feel free to criticize these changes. We're very open to your
feedback. More feedback, better API! =20
> Thanks in advance,
> Trustin
Hope I didn't ramble too much :o)
Dave
This e-mail and any attachment is for authorised use by the intended recipi=
ent(s) only. It may contain proprietary material, confidential information =
and/or be subject to legal privilege. It should not be copied, disclosed to=
, retained or used by, any other party. If you are not an intended recipien=
t then please promptly delete this e-mail and any attachment and all copies=
and inform the sender. Thank you.
| |
| peter royal 2006-01-23, 5:45 pm |
| | |
| Maarten Bosteels 2006-01-24, 7:45 am |
| Trustin Lee wrote:
> * SocketAddress is replaced with IoAddress (org.apache.common )
>
> * All bind/unbind/connect operation is performed via
> org.apache.commin.IoService. There's no need to instantiate an
> acceptor implementation by yourself. You never access
> org.apache.mina.transport.* packages anymore.
>
> * 'registry' package is removed. Instead, IoService does the similar job.
I really dislike singletons. At least when they have state.
When I create a new SimpleServiceRegistry instance, I know exactly which
classes have access to it.
And unrelated code is not able to mock around with my services.
> * No more transport-type specific property getters and setters. Now
> we use IoAddress properties and the user-defined attributes in
> IoSession. For example:
>
> ex1) IoService.bind(
> "nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",
> new MyHandler() );
>
I really prefer the type-safety of setters, and the associated javadoc.
If a lot of people like the URL-style configuration, maybe we could have
both ?
Like Pete already mentioned: I think we should separate the 'magic'
IoSession attributes from the user-defined attributes.
Just my opinion of course.
Maarten
| |
| Alex Cruise 2006-01-24, 5:47 pm |
| Maarten Bosteels wrote:
> I really dislike singletons. At least when they have state.
> When I create a new SimpleServiceRegistry instance, I know exactly
> which classes have access to it.
> And unrelated code is not able to mock around with my services.
Seconded!
> I really prefer the type-safety of setters, and the associated javadoc.
Seconded!
-0xe1a
| |
| Trustin Lee 2006-01-24, 5:47 pm |
| Hi guys,
Thanks for all your feedback!
I'll resolve all your concerns and start a new thread with the improved
API. Please wait for several days for now.
Cheers,
Trustin
2006/1/25, Alex Cruise <alex-a0FWtchhtz9DPfheJLI6IQ@public.gmane.org>:
>
> Maarten Bosteels wrote:
>
>
> Seconded!
>
>
> Seconded!
>
> -0xe1a
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Jose Alberto Fernandez 2006-01-25, 7:57 am |
| > From: Alex Cruise [mailto:alex-a0FWtchhtz9DPfheJLI6IQ@public.gmane.org]
>=20
> Maarten Bosteels wrote:
>=20
>=20
> Seconded!
>=20
Same here.=20
I think we need to define better how is it that we want MINA to be
configured and used. When people use the Spring approach, they
definitely want to be in control of the objects they create and of the
scope of those objects in the system. Singletons are a no-no on that
regard. It should be up to the Spring configuration to decide whether an
object should be a singleton or not.
On the same vein, when we compose a system out of different components,
we also want to maintain unknown interactions of the components to a
minimum.
I did not fully like SimpleServiceRegistry in particular because it had
endless amounts of methods depending on the kind of service one wanted,
but at least when one called unbindAll() I knew the scope of what was
been unbound. I would like IOService to work the same way in that
regard. The only thing I would be willing to have statically is some
registry of all the IOServices currently available, to be able to do
global management. Something like:
/**
* Creates if necessary and returns the IOService instance of that
name
*/
public static IOservice getInstance(String name);
/**
* List all the current active IOService instances
*/
public static IOService[] listInstances();
But maybe this mathods should be on some Factory class.
javadoc.[vbcol=seagreen]
>=20
> Seconded!
Here I am a little ambivalent. I am all for type safety. But I like the
simplicity of addressing using a URI and being able to pass parameters
at the same time. On the other hand, the objects returned by the methods
should be manageable using set/getters, which means for each type of URI
one should define a proper interface that define all its properties. The
URL parameters can be simply introspected on the setters.
I see no reason why we cannot have something very similar to the URL
model, where you first get a subclass of IOConnector (for example) with
any parameters in the URL already set, and then one does
IOConnector.connect(IOHandler), or something like that. Users can in
between downcast to an specific interface and change properties
programmatically if they want to, but it is not necessary.
Jose Alberto
| |
| Trustin Lee 2006-01-27, 8:47 pm |
| 2006/1/25, Jose Alberto Fernandez <jalberto-FQMVDHFwfny6lNtOUNzE6A@public.gmane.org>:
>
> I think we need to define better how is it that we want MINA to be
> configured and used. When people use the Spring approach, they
> definitely want to be in control of the objects they create and of the
> scope of those objects in the system. Singletons are a no-no on that
> regard. It should be up to the Spring configuration to decide whether an
> object should be a singleton or not.
We already discussed on singleton issues and we'll provide a non-singleton
way.
On the same vein, when we compose a system out of different components,
> we also want to maintain unknown interactions of the components to a
> minimum.
What is the 'unknown interaction' here? I don't think we cause any unknown
interaction. Besides adding a thread pool by default, what IoService does
is almost the same with the code that configures your acceptors and
connectors manually.
I did not fully like SimpleServiceRegistry in particular because it had
> endless amounts of methods depending on the kind of service one wanted,
> but at least when one called unbindAll() I knew the scope of what was
> been unbound. I would like IOService to work the same way in that
> regard. The only thing I would be willing to have statically is some
> registry of all the IOServices currently available, to be able to do
> global management. Something like:
>
/**
> * Creates if necessary and returns the IOService instance of that
> name
> */
> public static IOservice getInstance(String name);
>
> /**
> * List all the current active IOService instances
> */
> public static IOService[] listInstances();
It would be nice if we have this kind of feature, but do we really need
these registry methods? Is the 'name' an ID of IoService instance?
Here I am a little ambivalent. I am all for type safety. But I like the
> simplicity of addressing using a URI and being able to pass parameters
> at the same time. On the other hand, the objects returned by the methods
> should be manageable using set/getters, which means for each type of URI
> one should define a proper interface that define all its properties. The
> URL parameters can be simply introspected on the setters.
I didn't get what you're saying. Could you give me an example?
I see no reason why we cannot have something very similar to the URL
> model, where you first get a subclass of IOConnector (for example) with
> any parameters in the URL already set, and then one does
> IOConnector.connect(IOHandler), or something like that. Users can in
> between downcast to an specific interface and change properties
> programmatically if they want to, but it is not necessary.
Could you give me some example code here, too?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
| |
| Jose Alberto Fernandez 2006-01-27, 8:47 pm |
|
________________________________
From: Trustin Lee [mailto:trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
2006/1/25, Jose Alberto Fernandez <jalberto-FQMVDHFwfny6lNtOUNzE6A@public.gmane.org>:
I think we need to define better how is it that we want MINA to
be
configured and used. When people use the Spring approach, they
definitely want to be in control of the objects they create and
of the
scope of those objects in the system. Singletons are a no-no on
that
regard. It should be up to the Spring configuration to decide
whether an
object should be a singleton or not.
We already discussed on singleton issues and we'll provide a
non-singleton way.
On the same vein, when we compose a system out of different
components,
we also want to maintain unknown interactions of the components
to a
minimum.
What is the 'unknown interaction' here? I don't think we cause any
unknown interaction. Besides adding a thread pool by default, what
IoService does is almost the same with the code that configures your
acceptors and connectors manually.
For example:
Component A does: IOService.connect(.....); (Maybe more than once)
Component B independently does: IOService.connect(....); (maybe more
than once)
Now component A decides to go away and shut itself down:
IOService.unbindAll();
Ups, Component B just lost all its connections and does not know about
it.
These are unknown interactions due to the usage of a singleton.
I did not fully like SimpleServiceRegistry in particular because
it had
endless amounts of methods depending on the kind of service one
wanted,
but at least when one called unbindAll() I knew the scope of
what was
been unbound. I would like IOService to work the same way in
that
regard. The only thing I would be willing to have statically is
some
registry of all the IOServices currently available, to be able
to do
global management. Something like:
/**
* Creates if necessary and returns the IOService instance of
that
name
*/
public static IOservice getInstance(String name);
/**
* List all the current active IOService instances
*/
public static IOService[] listInstances();
It would be nice if we have this kind of feature, but do we really need
these registry methods? Is the 'name' an ID of IoService instance?
As I said, maybe they belong on some factory. The reason for having
something like this is management. You have a system build by several
components that can independently be using MINA. But you still want a
way to tell everyone to shutdown when you want the system to go down. As
the server will stay alive until all the IOServices finish, you need a
way to tell them to shut down gracefully.
These are just loose ideas, not an API. Maybe what is needed is a
notification mechanism. Something like:
public static IOService getInstance(UnbindListener listener);
public static void shutdownIOServices();
public interface UnbindListener {
void unbind(IOConnector);
void unbind(IOAcceptor);
}
In this model, when you obtain an IOService you provide a listener where
the component will receive notifications of connections being terminated
and hence has a chance to update its state accordingly. Each component
can do as it see fits, and will only be notified about things created by
his own IOService instance.
Here I am a little ambivalent. I am all for type safety. But I
like the
simplicity of addressing using a URI and being able to pass
parameters
at the same time. On the other hand, the objects returned by the
methods
should be manageable using set/getters, which means for each
type of URI
one should define a proper interface that define all its
properties. The
URL parameters can be simply introspected on the setters.
I didn't get what you're saying. Could you give me an example?
I do not have your code in front of me so this is just from what I
understood from reading the messages on this thread.
So you have different types of URLs:
String url =
"nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=2
0&receiveBufferSize=4096",
You get from your IOService instance a URL-like object, x (or y),
already introspected to set the parameters passed in the URL.
IOAcceptor x = ioService.getAcceptor(url);
IOConnector y = ioService.getConnector(url);
After that, you could set more properties programmatically by
downcasting to the correct type (interface) specific to the URL you
requested.
((IOSocketAcceptor) x).setXYZ(....);
Now you can call on the object to actually perform the connection or
binding, passing the handlers and filters.
x.bind(filterBuilder, handler);
y.connect(filterBuilder, handler);
Jose Alberto
| |
| Trustin Lee 2006-01-27, 8:47 pm |
| Now I see your point. Thanks!
Trustin
2006/1/26, Jose Alberto Fernandez <jalberto@cellectivity.com>:
>
>
>
>
> ------------------------------
>
> *From:* Trustin Lee [mailto:trustin@gmail.com]
>
> 2006/1/25, Jose Alberto Fernandez <jalberto@cellectivity.com>:
>
> I think we need to define better how is it that we want MINA to be
> configured and used. When people use the Spring approach, they
> definitely want to be in control of the objects they create and of the
> scope of those objects in the system. Singletons are a no-no on that
> regard. It should be up to the Spring configuration to decide whether an
> object should be a singleton or not.
>
>
> We already discussed on singleton issues and we'll provide a non-singleton
> way.
>
>
>
> On the same vein, when we compose a system out of different components,
> we also want to maintain unknown interactions of the components to a
> minimum.
>
>
> What is the 'unknown interaction' here? I don't think we cause any
> unknown interaction. Besides adding a thread pool by default, what
> IoService does is almost the same with the code that configures your
> acceptors and connectors manually.
>
>
>
> For example:
>
> Component A does: IOService.connect(¡¦..); (Maybe more than once)
>
>
>
> Component B independently does: IOService.connect(¡¦.); (maybe more than
> once)
>
>
>
> Now component A decides to go away and shut itself down:
> IOService.unbindAll();
>
> Ups, Component B just lost all its connections and does not know about it.
>
>
>
> These are unknown interactions due to the usage of a singleton.
>
>
>
>
>
> I did not fully like SimpleServiceRegistry in particular because it had
> endless amounts of methods depending on the kind of service one wanted,
> but at least when one called unbindAll() I knew the scope of what was
> been unbound. I would like IOService to work the same way in that
> regard. The only thing I would be willing to have statically is some
> registry of all the IOServices currently available, to be able to do
> global management. Something like:
>
> /**
> * Creates if necessary and returns the IOService instance of that
> name
> */
> public static IOservice getInstance(String name);
>
> /**
> * List all the current active IOService instances
> */
> public static IOService[] listInstances();
>
>
> It would be nice if we have this kind of feature, but do we really need
> these registry methods? Is the 'name' an ID of IoService instance?
>
>
>
> As I said, maybe they belong on some factory. The reason for having
> something like this is management. You have a system build by several
> components that can independently be using MINA. But you still want a way to
> tell everyone to shutdown when you want the system to go down. As the server
> will stay alive until all the IOServices finish, you need a way to tell them
> to shut down gracefully.
>
>
>
> These are just loose ideas, not an API. Maybe what is needed is a
> notification mechanism. Something like:
>
>
>
> public static IOService getInstance(UnbindListener listener);
>
>
>
> public static void shutdownIOServices();
>
>
>
> public interface UnbindListener {
>
>
>
> void unbind(IOConnector);
>
> void unbind(IOAcceptor);
>
> }
>
>
>
> In this model, when you obtain an IOService you provide a listener where
> the component will receive notifications of connections being terminated and
> hence has a chance to update its state accordingly. Each component can do as
> it see fits, and will only be notified about things created by his own
> IOService instance.
>
>
>
>
>
>
>
> Here I am a little ambivalent. I am all for type safety. But I like the
> simplicity of addressing using a URI and being able to pass parameters
> at the same time. On the other hand, the objects returned by the methods
> should be manageable using set/getters, which means for each type of URI
> one should define a proper interface that define all its properties. The
> URL parameters can be simply introspected on the setters.
>
>
> I didn't get what you're saying. Could you give me an example?
>
>
>
> I do not have your code in front of me so this is just from what I
> understood from reading the messages on this thread.
>
>
>
> So you have different types of URLs:
>
>
>
> String url = "
> nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=20&receiveBufferSize=4096",
>
>
>
> You get from your IOService instance a URL-like object, x (or y), already
> introspected to set the parameters passed in the URL.
>
>
>
> IOAcceptor x = ioService.getAcceptor(url);
>
>
>
> IOConnector y = ioService.getConnector(url);
>
>
>
> After that, you could set more properties programmatically by downcasting
> to the correct type (interface) specific to the URL you requested.
>
>
>
> ((IOSocketAcceptor) x).setXYZ(¡¦.);
>
>
>
> Now you can call on the object to actually perform the connection or
> binding, passing the handlers and filters.
>
>
>
> x.bind(filterBuilder, handler);
>
>
>
> y.connect(filterBuilder, handler);
>
>
>
> Jose Alberto
>
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
|
|
|
|
|