Trustin Lee wrote:
[x]: +1, import
Trustin Lee wrote:
[x]: +1, import
[x]: +1, import
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
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
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 any
[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 there
+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 as
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. The
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-client.
[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 message
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
+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
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):
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
[
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
[
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
[
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
[
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
[
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
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
[
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
[
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
[
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: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-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
[
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).
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 for
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
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.
It basically means that we
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
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
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?
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 are
46 matches
Mail list logo
