[ ]: All capital
[X]: Only the initial letter should be capital
I don't like special cases and / or picking the SHIFT key longer than
for one letter ;)
Regards
Michael
The code of IoHandler:
public void messageReceived(IoSession session, Object in) throws Exception
{
ChannelMessage response = (ChannelMessage) in;
Factory.getChannelManager().getChannel(response.getChannelId())
.performCallback(response);
}
On 9/17/07, Trustin Lee [EMAIL PROTECTED] wrote:
On 9/17/07, Maarten Bosteels [EMAIL PROTECTED] wrote:
Hi Trustin,
On 9/17/07, Trustin Lee [EMAIL PROTECTED] wrote:
Hi Maaretn,
On 9/17/07, Maarten Bosteels [EMAIL PROTECTED] wrote:
I fixed a possible
Rob Butler wrote:
No one likes IoBuffer eh.. Honestly it seems like the best name to me.
Surely, if you're renaming, it would make sense for this choice to be
IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the
gods, or one of the other more valid uses ?
I'm all
[ ]: All capital
[X]: Only the initial letter should be capital
I think using all capitals reduces readability. Consider the methods
exportHTMLSource() and exportHtmlSource(). It's a lot easier and quicker
for the brain to make out the last word in the second method name. Or
maybe it's just
[X]: All capital
[ ]: Only the initial letter should be capital
It's English, and that's how english is written. It's how existing
classes within the Java API are written, and it's how the vast majority
of names were written before framework developers became lazy when
implementing
I agree.
But this is something were nobody will think the same indeed.
Rodrigo
On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote:
[X]: All capital
[ ]: Only the initial letter should be capital
It's English, and that's how english is written. It's how existing
classes within the Java
Michael Kearns wrote:
[X]: All capital
[ ]: Only the initial letter should be capital
It's English, and that's how english is written. It's how existing
classes within the Java API are written, and it's how the vast
majority of names were written before framework developers became lazy
when
Niklas Therning wrote:
Michael Kearns wrote:
[X]: All capital
[ ]: Only the initial letter should be capital
It's English, and that's how english is written. It's how existing
classes within the Java API are written, and it's how the vast
majority of names were written before
About SUN (Sun ? :) inconstistant naming, just remember that as they
are porviding APIs (Apis ? :), it's impossinle for them to rename a
wrong class/metod as soon as it has made its way to the public.
Remember the Hashtable class ...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Well... we already made sure most people prefer IoBuffer to IOBuffer.
This thread is about what word should come before 'Buffer'.
Trustin
On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote:
Rob Butler wrote:
No one likes IoBuffer eh.. Honestly it seems like the best name to me.
Surely,
s/but if this turn out/but if this doesn't turn out/
On 9/19/07, Rodrigo Madera [EMAIL PROTECTED] wrote:
I don't mean to be a show stopper but if this turn out into an official
poll this will go on and on forever.
The faster the code is updated the better.
Also an immediate release
I don't mean to be a show stopper but if this turn out into an official poll
this will go on and on forever.
The faster the code is updated the better.
Also an immediate release afterwards would be a great idea.
Yours,
Rodrigo
On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote:
Yes,
I will fire the vote soon. I just can't right now because I'm pretty
busy preparing for a trip. Please don't stop brain-storming until
then! :D
Trustin
On 9/19/07, Rodrigo Madera [EMAIL PROTECTED] wrote:
I don't mean to be a show stopper but if this turn out into an official poll
this will
Hi Jason
The JIRA is https://issues.apache.org/jira/browse/DIRMINA-353
The last comment is waiting Apache members to fill the IP clearance
form directly into the incubator web site and import the source
code...
On 9/13/07, Mark [EMAIL PROTECTED] wrote:
ASyncWeb has not been migrated in yet.
Do I have to change my current source code using ByteBuffer?
On 9/19/07, Trustin Lee [EMAIL PROTECTED] wrote:
I will fire the vote soon. I just can't right now because I'm pretty
busy preparing for a trip. Please don't stop brain-storming until
then! :D
Trustin
On 9/19/07, Rodrigo
Can this be done with MINA now? I would like to put together a framework
that will have one Acceptor and register multiple IoHandlerApapters each
processing different types of data.
--
..Cheers
Mark
If you are using the trunk, check out the protocol-http-server and
filter-codec-http subprojects.
--
..Cheers
Mark
On 9/19/07, Deepak J [EMAIL PROTECTED] wrote:
Hi,
I am trying to run a MINA HTTP server using the encoder/decoder provided
in
+1 IoBuffer
Based on that I agree IoBuffer does make the most sense. I saw this
shortly before my last post and it didn't have enough time to sink in,
but it has grown on me and would fit with the naming scheme much better
than DataBuffer. And if some feel that IoBuffer isn't descriptive
Hi,
I just committed it, it's compiling, a bit working, but it's not really
for production usage (or any usage actually :D).Trustin is going to
refactor AbstractIoProcessor
The APR goal is to be portable on Unix and non Unix OSes, so there is
no Unix Domain socket :(
Perhaps a great idea whould
sounds great!
I will keep my eye on this project for future updates and will revisit this
soon.
--
..Cheers
Mark
On 9/19/07, Julien Vermillard [EMAIL PROTECTED] wrote:
Hi,
I just committed it, it's compiling, a bit working, but it's not really
for production usage (or any usage actually
No, your code will automatically notice this by reading Google and change
itself accordingly =o)
Just kidding. Yes, you will need to update it.
Regards,
Rodrigo
On 9/19/07, mat [EMAIL PROTECTED] wrote:
Do I have to change my current source code using ByteBuffer?
On 9/19/07, Trustin Lee
mat wrote:
Do I have to change my current source code using ByteBuffer?
This name change will only affect MINA 2.0 (MINA trunk in subversion).
So you would have to change your code if you move to MINA 2.0. The MINA
1.x APIs won't change.
-Mike
SocketConnection cannot be manually closed (for v1.1.2)
---
Key: DIRMINA-441
URL: https://issues.apache.org/jira/browse/DIRMINA-441
Project: MINA
Issue Type: Bug
Components: Core
I noticed the following today:
Failed tests:
testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.DatagramTrafficControlTest)
Does anyone know when that may get fixed?
Thanks,
Jeff
It would also be nice if we had some way of sharing thread pools and
selectors between Acceptors and Connectors. It would take quite a bit
of refactoring but it may be nice feature to have for those of us
building proxies that have multiple acceptors and multiple connectors
working in
[
https://issues.apache.org/jira/browse/DIRMINA-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender updated DIRMINA-441:
--
Attachment: DIRMINA-441-jgenender.patch
SocketConnection cannot be manually closed (for
[
https://issues.apache.org/jira/browse/DIRMINA-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender updated DIRMINA-441:
--
Attachment: DIRMINA-441-jgenender.patch
This patch is better and its thread safe.
Hello. I'm using MINA 1.1.2.
I use TextLineCodecFactory like this.
cfg.getFilterChain().addLast( codec, new ProtocolCodecFilter( new
TextLineCodecFactory( Charset.forName( EUC-KR ) ) ) );
and messageReceived() in SessionHandler is like this.
public void messageReceived(IoSession session,
I saw this too but I ran the tests again and they passed. It looks like
testSuspendResumeReadWrite isn't deterministic and need to be looked at.
Jeff Genender wrote:
I noticed the following today:
Failed tests:
30 matches
Mail list logo
