Hi,
I know SLF4J is a great logging framework for us, but I encounter with
many questions with configuring SLF4J to work with one's favorite
logging frameworks very often, via ML, IRC or personal e-mail.
IIRC, we already talked about providing a way to choose the logging
framework, but I thought
On 9/26/07, tiandike <[EMAIL PROTECTED]> wrote:
>
> thanks
Someone please fire the vote. I already am managing two votes. :D
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
+1 :o)
I cant wait to get back in to adding new features to asyncweb. It would
be great to see the move finally take place! (Finally maybe I'll get a
chance to do the async content streaming changes)
[X ]: +1, import
[ ]: 0, abstain
[ ]: -1, don't import
One thing I would add though: As we discussed (wow - it must be last
year now probably!), it would be nice if we could keep the name alive
(e.g. import as asyncweb?) somehow if / when this becomes a subproject /
module of Mina.
D
-Original Message-
From: Irving, Dave [mailto:[EMAIL PROTEC
Hi Trustin,
I don't like this idea.
It basically means that we are going to build are own logging-lib
facade, a job that SLF4J does very well.
And IMHO it won't simplify things, we'll have to explain people how
our mechanism for choosing a logging-librarry works.
Maybe a well-written FAQ entry a
It seems like there's no objection since the first posting. More than
a week have been passed, so I assume there are nobody concerned with
the proposed change. :D
Trustin
On 9/17/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> Hi community,
>
> I've just added IoService interfaces that fits into an
> [X]: +1, import
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
> [X]: +1, import
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Well, as soon as it's compatible with the naming scheme the project
selected (is the poll over btw ?), no objection.
Nio, not NIO...
On 9/27/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> It seems like there's no objection since the first posting. More than
> a week have been passed, so I assume th
+1 too
I like Dave idea, let's keep the name alive !
Julien
On Thu, 27 Sep 2007 08:47:45 +0100
"Irving, Dave" <[EMAIL PROTECTED]> wrote:
> One thing I would add though: As we discussed (wow - it must be last
> year now probably!), it would be nice if we could keep the name alive
> (e.g. import
On 9/27/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Well, as soon as it's compatible with the naming scheme the project
> selected (is the poll over btw ?), no objection.
Yes, I think it's over considering the overwhelming +1 for using
strict camel notation.
> Nio, not NIO...
Exactly. Th
On 9/27/07, Julien Vermillard <[EMAIL PROTECTED]> wrote:
> +1 too
>
> I like Dave idea, let's keep the name alive !
Then I think we need to keep aligned with the current HTTP client
implementation. Shall we rename the client? According to our naming
scheme, it's currently mina-protocol-http-clie
[X]: +1, import
--
Niklas Therning
www.spamdrain.net
+1 import, the code is looking nice, and it's a very common need.
Julien
On Thu, 27 Sep 2007 07:24:45 +0900
"Trustin Lee" <[EMAIL PROTECTED]> wrote:
> Hi again.
>
> There's an important contribution from Eero Nevalainen that will help
> users to implement sending a protocol-specific keep-alive m
Trustin Lee wrote:
...
> So.. I have no concrete idea on this naming issue.
> Any idea is appreciated!
I'd like, if possible, to stick with what we agreed on last year at the
start of the process (I.e. keeping the name):
http://www.nabble.com/Re%3A--pre-proposal--AsyncWeb-p5359826.html
http://w
+1 import. The code is actually a bit ugly to use, since I have to store
and retrieve the IoSession specific values as session attributes and the
sessionCreated is called elsewhere... In MINA 2.0 this function can be
properly implemented as an IoFilter, since 2.0 allows to have
ProtocolCodecFil
On 9/27/07, Irving, Dave <[EMAIL PROTECTED]> wrote:
> Trustin Lee wrote:
>
> ...
>
> > So.. I have no concrete idea on this naming issue.
> > Any idea is appreciated!
>
> I'd like, if possible, to stick with what we agreed on last year at the
> start of the process (I.e. keeping the name):
>
> http
On 9/20/07, Mike Heath <[EMAIL PROTECTED]> wrote:
> 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.
Yeah, there's some timing issue with the test. I added 100ms delay to
make it work 99% of time,
Trustin Lee wrote:
> I was just a bit hesitant because we got a client module.
> Then shall we go with mina-asyncweb? I think we should put
> codecs and related message classes under http-filter-codec-http
> though.
That sounds good to me!
> Trustin
Dave
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530680
]
Trustin Lee commented on DIRMINA-443:
-
Could you explain a little bit more in detail about this issue? I simply
[
https://issues.apache.org/jira/browse/DIRMINA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee updated DIRMINA-442:
Component/s: (was: Core)
Transport
Affects Version/s: (was
[
https://issues.apache.org/jira/browse/DIRMINA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee resolved DIRMINA-442.
-
Resolution: Fixed
Assignee: Trustin Lee
Please try again with the latest trunk build. I m
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530697
]
Trustin Lee commented on DIRMINA-443:
-
The patch can lead to unexpected termination of I/O threads even while th
[
https://issues.apache.org/jira/browse/DIRMINA-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee resolved DIRMINA-27.
Resolution: Fixed
Fix Version/s: 2.0.0-M1
Assignee: Trustin Lee
This issue has been
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530704
]
Jeff Genender commented on DIRMINA-443:
---
How would it lead to an abnormal termination? The Worker threads che
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530720
]
Trustin Lee commented on DIRMINA-443:
-
According to the applied patch:
for (; ;) {
[
https://issues.apache.org/jira/browse/DIRMINA-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530728
]
Trustin Lee commented on DIRMINA-418:
-
It seems like there's no way to send a urgent data in NIO, no matter the
[
https://issues.apache.org/jira/browse/DIRMINA-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530729
]
Trustin Lee commented on DIRMINA-435:
-
I am still getting Address already in use error. Could you try to run th
Hi folks,
I merged the only one method (i.e. write(Object message, SocketAddress
remoteAddress)) in BroadcastIoSession, so there's no more
BroadcastIoSession. I also explicitly documented it to be an optional
operation and therefore calling the method in non-connectionless
transports will throw a
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530732
]
Maarten Bosteels commented on DIRMINA-443:
--
Trustin, my apologies., it seems that I was too quick with appl
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530735
]
Trustin Lee commented on DIRMINA-443:
-
No need to apologize. It's trunk anyway! :D
Let's wait for Jeff's comme
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530736
]
Jeff Genender commented on DIRMINA-443:
---
Well...the close() is shutting everything down, so we really don't wa
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530738
]
Maarten Bosteels commented on DIRMINA-443:
--
I agree that it makes sense to have a close() method
> SocketC
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530741
]
Trustin Lee commented on DIRMINA-443:
-
"Well...the close() is shutting everything down, so we really don't want
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender updated DIRMINA-443:
--
Attachment: DIRMINA-443.take2.patch
Fixes the close() to use the timeout.
> SocketConnection
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530743
]
Jeff Genender commented on DIRMINA-443:
---
Ok...I see the code for the timeout and thus the differences...sorry
[
https://issues.apache.org/jira/browse/DIRMINA-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530745
]
Trustin Lee commented on DIRMINA-441:
-
Apart from DIRMINA-443, we have to just add more documentation instead of
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee resolved DIRMINA-443.
-
Resolution: Fixed
I checked in the patch. Please confirm and close.
> SocketConnection cannot
[
https://issues.apache.org/jira/browse/DIRMINA-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender closed DIRMINA-441.
-
Resolution: Fixed
Agreed...will close it out.
> SocketConnection cannot be manually closed (fo
[
https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Genender closed DIRMINA-443.
-
Wow...that was fast! ;-) Confirmed.
> SocketConnection cannot be manually closed (for v2.X)
>
Well... since the documentation for SLF4J is very clear and easy to
understand, I don't really see a reason to abandon it. Personally I
think the (original) choice for this logging facade was perfect
(especially since you can change the actual logger on the spot, without
any code changes).
Je
On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> Hi Trustin,
>
> I don't like this idea.
> It basically means that we are going to build are own logging-lib
> facade, a job that SLF4J does very well.
>
> And IMHO it won't simplify things, we'll have to explain people how
> our mechanism fo
+1 non-binding
Hi Trustin,
How about inquiring with Ceki to see if these concerns can be
addressed then see what other options exist? The idea of yet another
logging implementation is a bit nausiating: there are so many already
in existance. Adding yet another one to the mix especially to be
maintained by the m
On 9/27/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > Hi Trustin,
> >
> > I don't like this idea.
> > It basically means that we are going to build are own logging-lib
> > facade, a job that SLF4J does very well.
> >
> > And IMHO it won't s
On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> On 9/27/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> > On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > > Hi Trustin,
> > >
> > > I don't like this idea.
> > > It basically means that we are going to build are own logging-lib
> >
On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > On 9/27/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> > > On 9/27/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > > > Hi Trustin,
> > > >
> > > > I don't like this idea.
> > > >
Any logging framework will have pros and cons. SLF4J are solving a lot
of pb we had with log4j. It's not perfect, and users who are not
completely aware of the existence of a documentation may have pb. This
is pretty much a RTFM problem than a SLF4j pb.
I would much more favor an augmented FAQ to
[
https://issues.apache.org/jira/browse/DIRMINA-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee closed DIRMINA-318.
---
Resolution: Fixed
Assignee: Trustin Lee
Done. :)
> sessionIdle event is not fired for datagra
Would anyone mind if I submitted a preso on Mina for this event?
Jeff
--- Begin Message ---
Call for Papers Opens for ApacheCon Europe 2008
The Apache Software Foundation (ASF) invites submissions to its official
conference, ApacheCon Europe 2008. To be held 7 April through 11 April,
2008 at the
Go for it ;). Everyone is free to do so.
Alex
On 9/27/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
> Would anyone mind if I submitted a preso on Mina for this event?
>
> Jeff
>
> Call for Papers Opens for ApacheCon Europe 2008
>
> The Apache Software Foundation (ASF) invites submissions to its
All -
Does anyone know what the following exception means? Could it be due to
packet loss on the network? Or maybe our client is closing their
input/ouput streams? We are consistently seeing his in our logs, though
similar tests on a different network with a different client ran fine.
Thanks in
Emmanuel Lecharny wrote:
Any logging framework will have pros and cons. SLF4J are solving a lot
of pb we had with log4j. It's not perfect, and users who are not
completely aware of the existence of a documentation may have pb. This
is pretty much a RTFM problem than a SLF4j pb.
I would much more
Hello. I'm using MINA 1.1.2.
I want get packet with fixed size and put packet with fixed size.
example,
I received packet with 11byte header + 5byte data. (5 byte data is variable)
and I parsed header, data size is 5.
so how can I get 5 byte data?
and how can I put 5 byte data in ByteBuffer?
sor
I added a simple logging tutorial to
http://mina.apache.org/documentation.html
I hope this will help and at least we will have something to point people
towards.
On 9/27/07, Mike Heath <[EMAIL PROTECTED]> wrote:
>
> Emmanuel Lecharny wrote:
> > Any logging framework will have pros and cons. SLF4J
55 matches
Mail list logo
