You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@apache.org> on 2008/06/09 13:05:24 UTC
[2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Ok, ok, I have to admit that my proposal was not that good :)
So let's move to something more sane, which seems to gather more
approval : reviewing the packages we have in mina-core.
More to come...
Mark Webb wrote:
> +1
>
> On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu <ak...@apache.org> wrote:
>
>> I don't really have a specific view point on this topic. I would rather
>> have more efficient and easily maintained internals. I don't know if this
>> accomplishes that but I'm sure you guys can hash that out.
>>
>> Regards,
>> Alex
>>
>> On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny <el...@apache.org>
>> wrote:
>>
>>
>>> Mark Webb wrote:
>>>
>>>
>>>> I do not think this is a good idea.
>>>>
>>>>
>>>>
>>> Looking at the three answers, it seems so ;)
>>>
>>> 3. We may confuse things for alot of people who may already be using
>>>
>>>> 2.0. Telling users that they will have to fix their code because of a
>>>> re-organization looks bad on our part IMHO.
>>>>
>>>>
>>>>
>>> Regardless to the refactoring question, this is the kind of risk we have to
>>> consider, in any case. More than confusing the users who have based their
>>> code on the current 2.0 stack, I think it's much more important to build a
>>> coherent stack we will live with for a long time. Waiting for a 3.0 version
>>> and differing refactoring just because we have users of the current trunk is
>>> certainly not a good idea. Trunk is trunk, using it is a risk, and it's well
>>> know.
>>>
>>> Thanks !
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> cordialement, regards,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>> directory.apache.org
>>>
>>>
>>>
>>>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jun 25, 2008 at 9:54 AM, Julien Vermillard
<jv...@archean.fr> wrote:
> Ok, let's do that, anyway I finally deployed a new snapshot.
Thanks!
/niklas
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Wed, 25 Jun 2008 09:46:36 +0200
"Niklas Gustavsson" <ni...@protocol7.com> wrote:
> On Wed, Jun 25, 2008 at 9:30 AM, Julien Vermillard
> <jv...@archean.fr> wrote:
> > Ok will try to do it today,
>
> Thanks!
>
> > anyway we got a problem ftpserver &
> > asyncweb shouldn't depend on MINA snapshot but on MX releases for
> > avoid this kind of problems, when we release next milestone (I
> > suppose it can be done as soon we decided to stop changing
> > packages :D) we need to change the subproject dependencies. If
> > there is a big move needed by one of the subproject we will just
> > need to release a milestone.
>
> Agreed, for FtpServer we did depend on M1 for a while. However, we
> then needed some stuff developed in M2-SNAPSHOT (for blacklisting) so
> I had to depend on the snapshot version. As soon as M2 is available,
> we will try to stick with that. I think we should attempt to get it
> out fairly soon.
>
> /niklas
Ok, let's do that, anyway I finally deployed a new snapshot.
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jun 25, 2008 at 9:30 AM, Julien Vermillard
<jv...@archean.fr> wrote:
> Ok will try to do it today,
Thanks!
> anyway we got a problem ftpserver &
> asyncweb shouldn't depend on MINA snapshot but on MX releases for avoid
> this kind of problems, when we release next milestone (I suppose it can
> be done as soon we decided to stop changing packages :D) we need to
> change the subproject dependencies. If there is a big move needed by
> one of the subproject we will just need to release a milestone.
Agreed, for FtpServer we did depend on M1 for a while. However, we
then needed some stuff developed in M2-SNAPSHOT (for blacklisting) so
I had to depend on the snapshot version. As soon as M2 is available,
we will try to stick with that. I think we should attempt to get it
out fairly soon.
/niklas
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Fri, Jun 20, 2008 at 8:20 AM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>
>
>> IMHO, IoEvent and IoEventType belongs to an event package, under the
>> session package.
>>
>>
>>
> IMO two classes are not enough reason to create a package.
True. Not a big deal to have those guys in session.
> Also we need to
> be careful about move too many things around needlessly. Remember each
> change you make will impact users.
>
I checked on asyncWeb, the burden is very minimum. Of course, you will
have to go through imports to get it work again, but this is not such a
big work.
The main advantage is that it brings a lot of clarity on MINA code !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> On Wed, 25 Jun 2008 09:16:17 +0200
> "Niklas Gustavsson" <ni...@protocol7.com> wrote:
>
>
>> On Tue, Jun 24, 2008 at 2:18 PM, Julien Vermillard
>> <jv...@archean.fr> wrote:
>>
>>> Thanks Emmanuel for the big commit, everything is compiling fine
>>> here. Everybody will need to rename there import in mina 2.0 apps.
>>>
>> Could we publish a new snapshot to the Maven repo? As it stands,
>> FtpServer wont build unless you build MINA on your own.
>>
>> I'm currently behind a firewall and unable to do the deployment
>> myself :-/
>>
>> /niklas
>>
> Hi
> Ok will try to do it today, anyway we got a problem ftpserver &
> asyncweb shouldn't depend on MINA snapshot but on MX releases for avoid
> this kind of problems, when we release next milestone (I suppose it can
> be done as soon we decided to stop changing packages :D) we need to
> change the subproject dependencies. If there is a big move needed by
> one of the subproject we will just need to release a milestone.
>
> WDYT ?
>
yep we should not depend on SNAPSHOTs in ftpserver and asyncweb. If we
need a new release, then it's easy to cut a M2, M3 etc...
It's just a matter of changing the pom.xml.
We also could create a meta-pom.xml (a pom.xml which just build all the
sub-project and MINA) in order to be able to build all the projects
together. Something like MINA-with-dependencies like what we have on
Directory.
> Julien
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Wed, 25 Jun 2008 09:16:17 +0200
"Niklas Gustavsson" <ni...@protocol7.com> wrote:
> On Tue, Jun 24, 2008 at 2:18 PM, Julien Vermillard
> <jv...@archean.fr> wrote:
> > Thanks Emmanuel for the big commit, everything is compiling fine
> > here. Everybody will need to rename there import in mina 2.0 apps.
>
> Could we publish a new snapshot to the Maven repo? As it stands,
> FtpServer wont build unless you build MINA on your own.
>
> I'm currently behind a firewall and unable to do the deployment
> myself :-/
>
> /niklas
Hi
Ok will try to do it today, anyway we got a problem ftpserver &
asyncweb shouldn't depend on MINA snapshot but on MX releases for avoid
this kind of problems, when we release next milestone (I suppose it can
be done as soon we decided to stop changing packages :D) we need to
change the subproject dependencies. If there is a big move needed by
one of the subproject we will just need to release a milestone.
WDYT ?
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Jun 24, 2008 at 2:18 PM, Julien Vermillard
<jv...@archean.fr> wrote:
> Thanks Emmanuel for the big commit, everything is compiling fine here.
> Everybody will need to rename there import in mina 2.0 apps.
Could we publish a new snapshot to the Maven repo? As it stands,
FtpServer wont build unless you build MINA on your own.
I'm currently behind a firewall and unable to do the deployment myself :-/
/niklas
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 24 Jun 2008 14:23:48 +0200
Emmanuel Lecharny <el...@apache.org> wrote:
> Julien Vermillard wrote:
> > On Fri, 20 Jun 2008 16:19:11 +0200
> > Emmanuel Lecharny <el...@apache.org> wrote:
> >
> >
> >>>>> IMHO, IoEvent and IoEventType belongs to an event package, under
> >>>>> the session package.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> IMO two classes are not enough reason to create a package. Also
> >>>> we need to be careful about move too many things around
> >>>> needlessly. Remember each change you make will impact users.
> >>>>
> >>>> Alex
> >>>>
> >>>>
> >>> Hi,
> >>>
> >>> for session.event & session.config it's not enought for a package
> >>>
> >>>
> >> ok. Makes sense.
> >>
> >>> for write, it should go in session because it really tied to
> >>> session
> >>>
> >> session.write ?
> >>
> >>
> >>
> >>> Now I start to wonder why we got this "common" package perhaps all
> >>> that can go directly to o.a.mina root ?
> >>>
> >>>
> >> This will impact all the imports in ftpserver and asyncweb, but we
> >> can do it.
> >>
> >>
> >>> Julien
> >>>
> >>>
> >>>
> >>
> >
> > Thanks Emmanuel for the big commit, everything is compiling fine
> > here. Everybody will need to rename there import in mina 2.0 apps.
> >
> > Now I would like to discuss about the *.common.* package ? does we
> > need it ? I think no, it's increasing import length for no much
> > gain.
> Well, after having looked at the hierarchy, I think it would be
> better to keep this extra level, as you have filter, handler,
> transport and utils package on the same level than common.
>
> I would rather suggest we rename it to core, or keep common as a name.
>
> wdyt ?
>
+1 for renaming to core like the module
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> On Fri, 20 Jun 2008 16:19:11 +0200
> Emmanuel Lecharny <el...@apache.org> wrote:
>
>
>>>>> IMHO, IoEvent and IoEventType belongs to an event package, under
>>>>> the session package.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> IMO two classes are not enough reason to create a package. Also we
>>>> need to be careful about move too many things around needlessly.
>>>> Remember each change you make will impact users.
>>>>
>>>> Alex
>>>>
>>>>
>>> Hi,
>>>
>>> for session.event & session.config it's not enought for a package
>>>
>>>
>> ok. Makes sense.
>>
>>> for write, it should go in session because it really tied to session
>>>
>>>
>> session.write ?
>>
>>
>>
>>> Now I start to wonder why we got this "common" package perhaps all
>>> that can go directly to o.a.mina root ?
>>>
>>>
>> This will impact all the imports in ftpserver and asyncweb, but we
>> can do it.
>>
>>
>>> Julien
>>>
>>>
>>>
>>
>
> Thanks Emmanuel for the big commit, everything is compiling fine here.
> Everybody will need to rename there import in mina 2.0 apps.
>
> Now I would like to discuss about the *.common.* package ? does we need
> it ? I think no, it's increasing import length for no much gain.
>
Well, after having looked at the hierarchy, I think it would be better
to keep this extra level, as you have filter, handler, transport and
utils package on the same level than common.
I would rather suggest we rename it to core, or keep common as a name.
wdyt ?
> Julien
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Fri, 20 Jun 2008 16:19:11 +0200
Emmanuel Lecharny <el...@apache.org> wrote:
>
> >>> IMHO, IoEvent and IoEventType belongs to an event package, under
> >>> the session package.
> >>>
> >>>
> >>>
> >> IMO two classes are not enough reason to create a package. Also we
> >> need to be careful about move too many things around needlessly.
> >> Remember each change you make will impact users.
> >>
> >> Alex
> >>
> >
> > Hi,
> >
> > for session.event & session.config it's not enought for a package
> >
> ok. Makes sense.
> > for write, it should go in session because it really tied to session
> >
> session.write ?
>
>
> > Now I start to wonder why we got this "common" package perhaps all
> > that can go directly to o.a.mina root ?
> >
> This will impact all the imports in ftpserver and asyncweb, but we
> can do it.
>
> > Julien
> >
> >
>
>
Thanks Emmanuel for the big commit, everything is compiling fine here.
Everybody will need to rename there import in mina 2.0 apps.
Now I would like to discuss about the *.common.* package ? does we need
it ? I think no, it's increasing import length for no much gain.
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
>>> IMHO, IoEvent and IoEventType belongs to an event package, under the
>>> session package.
>>>
>>>
>>>
>> IMO two classes are not enough reason to create a package. Also we
>> need to be careful about move too many things around needlessly.
>> Remember each change you make will impact users.
>>
>> Alex
>>
>
> Hi,
>
> for session.event & session.config it's not enought for a package
>
ok. Makes sense.
> for write, it should go in session because it really tied to session
>
session.write ?
> Now I start to wonder why we got this "common" package perhaps all that
> can go directly to o.a.mina root ?
>
This will impact all the imports in ftpserver and asyncweb, but we can
do it.
> Julien
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Fri, 20 Jun 2008 09:55:10 -0400
"Alex Karasulu" <ak...@apache.org> wrote:
> On Fri, Jun 20, 2008 at 8:20 AM, Emmanuel Lecharny
> <el...@apache.org> wrote:
>
> >
> >>
> > IMHO, IoEvent and IoEventType belongs to an event package, under the
> > session package.
> >
> >
> IMO two classes are not enough reason to create a package. Also we
> need to be careful about move too many things around needlessly.
> Remember each change you make will impact users.
>
> Alex
Hi,
for session.event & session.config it's not enought for a package
for write, it should go in session because it really tied to session
+1
for all the others
Now I start to wonder why we got this "common" package perhaps all that
can go directly to o.a.mina root ?
Julien
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Jun 20, 2008 at 8:20 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
>
>>
> IMHO, IoEvent and IoEventType belongs to an event package, under the
> session package.
>
>
IMO two classes are not enough reason to create a package. Also we need to
be careful about move too many things around needlessly. Remember each
change you make will impact users.
Alex
Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring]
What about splitting mina-core ?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi Julien,
I followed your proposal, and moved the classes into the proposed
packages, fixed a few visibility issues (protected methods and such).
More inline...
Julien Vermillard wrote:
> First thought about class in o.a.m.common :
>
> I tried to give a category for each class (buffer,service,future,etc..)
>
> IoBufferHexDumper.java buffer
> SimpleBufferAllocator.java buffer
> BufferDataException.java buffer
> IoBuffer.java buffer
> IoBufferWrapper.java buffer
> AbstractIoBuffer.java buffer
> IoBufferAllocator.java buffer
> CachedBufferAllocator.java buffer
>
Just perfect. The IoBufferHexDumper could simply be removed and a static
method can be define in utils instead.
> DefaultFileRegion.java file
> FileRegion.java file
>
+1
> IoFilter.java filterchain
> IoFilterLifeCycleException.java filterchain
> IoFilterChainBuilder.java filterchain
> IoFilterChain.java filterchain
> IoFilterEvent.java filterchain
> IoEvent.java filterchain
> IoFilterAdapter.java filterchain
> IoEventType.java filterchain
> UnknownMessageTypeException.java filterchain/demux
>
IMHO, IoEvent and IoEventType belongs to an event package, under the
session package.
UnknownMessageTypeException belongs to the session package, too.
> IoFuture.java future
> WriteFuture.java future
> DefaultCloseFuture.java future
> IoFutureListener.java future
> CloseFuture.java future
> CompositeIoFuture.java future
> ConnectFuture.java future
> DefaultWriteFuture.java future
> DefaultIoFuture.java future
> DefaultReadFuture.java future
> DefaultConnectFuture.java future
> ReadFuture.java future
>
Perfect.
> AbstractPollingIoConnector.java polling
> AbstractPollingIoAcceptor.java polling
> AbstractPollingIoProcessor.java polling
> AbstractPollingConnectionlessIoAcceptor.java polling
>
+1
> WriteToClosedSessionException.java service
> TransportMetadata.java service
> SimpleIoProcessorPool.java service
> NothingWrittenException.java service
> IoHandlerAdapter.java service
> IoHandler.java service
> IoProcessor.java service
> IoServiceListenerSupport.java service
> IoServiceListener.java service
> IoService.java service
> AbstractIoAcceptor.java service
> DefaultIoFilterChain.java service
> DefaultTransportMetadata.java service
> DefaultWriteRequest.java service
> AbstractIoConnector.java service
> AbstractIoService.java service
> DefaultIoFilterChainBuilder.java service
> ExpiringSessionRecycler.java service
> IoAcceptor.java service
> IoConnector.java service
>
DefaultIoFilterChain and DefaultIoFilterChainBuilder should be in filterchain, I think.
ExpiringSessionRecycler should be in session
DefaultWriteRequest should be in another package, with WriteRequest, WriteRequestQueue, WriteRequestWrapper, WriteTimeOutException and WriteToClosedSessionException.
> IdleStatus.java session
> WriteException.java session
> AttributeKey.java session
> AbstractIoSession.java session
> WriteRequestWrapper.java session
> WriteTimeoutException.java session
> DummySession.java session
> TrafficMask.java session
> WriteRequestQueue.java session
> WriteRequest.java session
> IoSessionDataStructureFactory.java session
> IoSessionInitializationException.java session
> IoSessionInitializer.java session
> DefaultIoSessionDataStructureFactory.java session
> IoSessionAttributeMap.java session
> IdleStatusChecker.java session
> IoSessionRecycler.java session
> IoSession.java session
>
For the two following files, I would create a sub package (config) :
AbstractIoSessionConfig.java session/config
IoSessionConfig.java session/config
I think that a 'write' package could be usefull too :
DefaultWriteRequest.java write
WriteException.java write
WriteRequest.java write
WriteRequestQueue.java write
WriteRequestWrapper.java write
WriteTimeOutException.java write
> DefaultExceptionMonitor.java ?
> RuntimeIoException.java ?
> IoUtil.java ?
> ExceptionMonitor.java ?
>
> Anyway this package is now bloated ;)
>
So we are close to something better. Should I commit the package
modifications ? Here is the new hierarchy :
./org/apache/mina/common/RuntimeIoException.java
./org/apache/mina/common/IoUtil.java
./org/apache/mina/common/ExceptionMonitor.java
./org/apache/mina/common/DefaultExceptionMonitor.java
./org/apache/mina/common/buffer/AbstractIoBuffer.java
./org/apache/mina/common/buffer/BufferDataException.java
./org/apache/mina/common/buffer/IoBuffer.java
./org/apache/mina/common/buffer/SimpleBufferAllocator.java
./org/apache/mina/common/buffer/CachedBufferAllocator.java
./org/apache/mina/common/buffer/IoBufferAllocator.java
./org/apache/mina/common/buffer/IoBufferWrapper.java
./org/apache/mina/common/buffer/IoBufferHexDumper.java
./org/apache/mina/common/file/DefaultFileRegion.java
./org/apache/mina/common/file/FileRegion.java
./org/apache/mina/common/filterchain/DefaultIoFilterChainBuilder.java
./org/apache/mina/common/filterchain/IoFilterEvent.java
./org/apache/mina/common/filterchain/IoFilterLifeCycleException.java
./org/apache/mina/common/filterchain/IoFilterAdapter.java
./org/apache/mina/common/filterchain/DefaultIoFilterChain.java
./org/apache/mina/common/filterchain/IoFilterChain.java
./org/apache/mina/common/filterchain/IoFilterChainBuilder.java
./org/apache/mina/common/filterchain/IoFilter.java
./org/apache/mina/common/future/ReadFuture.java
./org/apache/mina/common/future/DefaultWriteFuture.java
./org/apache/mina/common/future/DefaultCloseFuture.java
./org/apache/mina/common/future/DefaultReadFuture.java
./org/apache/mina/common/future/CompositeIoFuture.java
./org/apache/mina/common/future/DefaultConnectFuture.java
./org/apache/mina/common/future/ConnectFuture.java
./org/apache/mina/common/future/IoFutureListener.java
./org/apache/mina/common/future/WriteFuture.java
./org/apache/mina/common/future/CloseFuture.java
./org/apache/mina/common/future/DefaultIoFuture.java
./org/apache/mina/common/future/IoFuture.java
./org/apache/mina/common/polling/AbstractPollingIoProcessor.java
./org/apache/mina/common/polling/AbstractPollingIoAcceptor.java
./org/apache/mina/common/polling/AbstractPollingIoConnector.java
./org/apache/mina/common/polling/AbstractPollingConnectionlessIoAcceptor.java
./org/apache/mina/common/service/IoProcessor.java
./org/apache/mina/common/service/AbstractIoService.java
./org/apache/mina/common/service/IoAcceptor.java
./org/apache/mina/common/service/IoConnector.java
./org/apache/mina/common/service/IoHandlerAdapter.java
./org/apache/mina/common/service/SimpleIoProcessorPool.java
./org/apache/mina/common/service/IoService.java
./org/apache/mina/common/service/IoHandler.java
./org/apache/mina/common/service/IoServiceListenerSupport.java
./org/apache/mina/common/service/AbstractIoConnector.java
./org/apache/mina/common/service/IoServiceListener.java
./org/apache/mina/common/service/DefaultTransportMetadata.java
./org/apache/mina/common/service/AbstractIoAcceptor.java
./org/apache/mina/common/service/TransportMetadata.java
./org/apache/mina/common/session/TrafficMask.java
./org/apache/mina/common/session/IoSessionRecycler.java
./org/apache/mina/common/session/DummySession.java
./org/apache/mina/common/session/IdleStatus.java
./org/apache/mina/common/session/IoSessionInitializationException.java
./org/apache/mina/common/session/IoSessionAttributeMap.java
./org/apache/mina/common/session/DefaultIoSessionDataStructureFactory.java
./org/apache/mina/common/session/AbstractIoSession.java
./org/apache/mina/common/session/ExpiringSessionRecycler.java
./org/apache/mina/common/session/IoSessionInitializer.java
./org/apache/mina/common/session/AttributeKey.java
./org/apache/mina/common/session/IdleStatusChecker.java
./org/apache/mina/common/session/IoSession.java
./org/apache/mina/common/session/UnknownMessageTypeException.java
./org/apache/mina/common/session/IoSessionDataStructureFactory.java
./org/apache/mina/common/session/config/IoSessionConfig.java
./org/apache/mina/common/session/config/AbstractIoSessionConfig.java
./org/apache/mina/common/session/event/IoEvent.java
./org/apache/mina/common/session/event/IoEventType.java
./org/apache/mina/common/write/WriteRequest.java
./org/apache/mina/common/write/WriteToClosedSessionException.java
./org/apache/mina/common/write/WriteRequestQueue.java
./org/apache/mina/common/write/DefaultWriteRequest.java
./org/apache/mina/common/write/WriteException.java
./org/apache/mina/common/write/NothingWrittenException.java
./org/apache/mina/common/write/WriteTimeoutException.java
./org/apache/mina/common/write/WriteRequestWrapper.java
./org/apache/mina/common/RuntimeIoException.java
./org/apache/mina/common/IoUtil.java
./org/apache/mina/common/ExceptionMonitor.java
./org/apache/mina/common/DefaultExceptionMonitor.java
Any different POV ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [2.0 refactoring] Reviewing core packages was : [2.0
refactoring] What about splitting mina-core ?
Posted by Julien Vermillard <jv...@archean.fr>.
First thought about class in o.a.m.common :
I tried to give a category for each class (buffer,service,future,etc..)
IoBufferHexDumper.java buffer
SimpleBufferAllocator.java buffer
BufferDataException.java buffer
IoBuffer.java buffer
IoBufferWrapper.java buffer
AbstractIoBuffer.java buffer
IoBufferAllocator.java buffer
CachedBufferAllocator.java buffer
DefaultFileRegion.java file
FileRegion.java file
IoFilter.java filterchain
IoFilterLifeCycleException.java filterchain
IoFilterChainBuilder.java filterchain
IoFilterChain.java filterchain
IoFilterEvent.java filterchain
IoEvent.java filterchain
IoFilterAdapter.java filterchain
IoEventType.java filterchain
UnknownMessageTypeException.java filterchain/demux
IoFuture.java future
WriteFuture.java future
DefaultCloseFuture.java future
IoFutureListener.java future
CloseFuture.java future
CompositeIoFuture.java future
ConnectFuture.java future
DefaultWriteFuture.java future
DefaultIoFuture.java future
DefaultReadFuture.java future
DefaultConnectFuture.java future
ReadFuture.java future
AbstractPollingIoConnector.java polling
AbstractPollingIoAcceptor.java polling
AbstractPollingIoProcessor.java polling
AbstractPollingConnectionlessIoAcceptor.java polling
WriteToClosedSessionException.java service
TransportMetadata.java service
SimpleIoProcessorPool.java service
NothingWrittenException.java service
IoHandlerAdapter.java service
IoHandler.java service
IoProcessor.java service
IoServiceListenerSupport.java service
IoServiceListener.java service
IoService.java service
AbstractIoAcceptor.java service
DefaultIoFilterChain.java service
DefaultTransportMetadata.java service
DefaultWriteRequest.java service
AbstractIoConnector.java service
AbstractIoService.java service
DefaultIoFilterChainBuilder.java service
ExpiringSessionRecycler.java service
IoAcceptor.java service
IoConnector.java service
AbstractIoSessionConfig.java session
IdleStatus.java session
WriteException.java session
AttributeKey.java session
AbstractIoSession.java session
WriteRequestWrapper.java session
WriteTimeoutException.java session
DummySession.java session
TrafficMask.java session
WriteRequestQueue.java session
WriteRequest.java session
IoSessionDataStructureFactory.java session
IoSessionInitializationException.java session
IoSessionInitializer.java session
DefaultIoSessionDataStructureFactory.java session
IoSessionAttributeMap.java session
IoSessionConfig.java session
IdleStatusChecker.java session
IoSessionRecycler.java session
IoSession.java session
DefaultExceptionMonitor.java ?
RuntimeIoException.java ?
IoUtil.java ?
ExceptionMonitor.java ?
Anyway this package is now bloated ;)
BTW I'm out of office for 1 week.
Julien
On Mon, 09 Jun 2008 13:05:24 +0200
Emmanuel Lecharny <el...@apache.org> wrote:
> Ok, ok, I have to admit that my proposal was not that good :)
>
> So let's move to something more sane, which seems to gather more
> approval : reviewing the packages we have in mina-core.
>
> More to come...
>
>
> Mark Webb wrote:
> > +1
> >
> > On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu
> > <ak...@apache.org> wrote:
> >> I don't really have a specific view point on this topic. I would
> >> rather have more efficient and easily maintained internals. I
> >> don't know if this accomplishes that but I'm sure you guys can
> >> hash that out.
> >>
> >> Regards,
> >> Alex
> >>
> >> On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny
> >> <el...@apache.org> wrote:
> >>
> >>
> >>> Mark Webb wrote:
> >>>
> >>>
> >>>> I do not think this is a good idea.
> >>>>
> >>>>
> >>>>
> >>> Looking at the three answers, it seems so ;)
> >>>
> >>> 3. We may confuse things for alot of people who may already be
> >>> using
> >>>> 2.0. Telling users that they will have to fix their code
> >>>> because of a re-organization looks bad on our part IMHO.
> >>>>
> >>>>
> >>>>
> >>> Regardless to the refactoring question, this is the kind of risk
> >>> we have to consider, in any case. More than confusing the users
> >>> who have based their code on the current 2.0 stack, I think it's
> >>> much more important to build a coherent stack we will live with
> >>> for a long time. Waiting for a 3.0 version and differing
> >>> refactoring just because we have users of the current trunk is
> >>> certainly not a good idea. Trunk is trunk, using it is a risk,
> >>> and it's well know.
> >>>
> >>> Thanks !
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> --
> >>> cordialement, regards,
> >>> Emmanuel Lécharny
> >>> www.iktek.com
> >>> directory.apache.org
> >>>
> >>>
> >>>
> >>>
> >
> >
>
>