Hi all,
I've been sort of following some of the discussions of the proposed
changes and I like what I'm hearing. In fact, I'd love it if someone
could say how soon I could expect to see a release of all the good ideas
;-)
Anyway, I'm coming back to a project that I had originally working with
Add sendfile support to transport-apr
-
Key: DIRMINA-601
URL: https://issues.apache.org/jira/browse/DIRMINA-601
Project: MINA
Issue Type: Improvement
Components: Core, Transport
Affects
[
https://issues.apache.org/jira/browse/DIRMINA-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Cadien updated DIRMINA-601:
-
Attachment: sendfile-patches.zip
I've attached the new classes/interfaces and diffs to exising
Hi,
In my client implementation, I set manual threading model, and insert
executorFilter() in my socketConnector config. On certain condition, in my
handler, I will block in 'ArrayBlockingQueue'. during this situation, I
don't see IoProcessor creating a new handler thread to process a new message
[
https://issues.apache.org/jira/browse/DIRMINA-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Cadien updated DIRMINA-601:
-
Attachment: (was: sendfile-patches.zip)
Add sendfile support to transport-apr
[
https://issues.apache.org/jira/browse/DIRMINA-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Cadien updated DIRMINA-601:
-
Attachment: sendfile-patches.zip
Forgot one patch
Add sendfile support to transport-apr
I think we should release the AHC client that's current in the 1.0
branch.
Thoughts?
Regards,
Alan
Go for it and kick off the vote - let's get that RAT Maven plugin into the
project for easy legal review. If you can get us that on the vote thread
this would be most excellent.
Thanks,
Alex
On Thu, Jun 5, 2008 at 5:14 PM, Jeff Genender [EMAIL PROTECTED] wrote:
+1
Alan D. Cabrera wrote:
I
[
https://issues.apache.org/jira/browse/DIRMINA-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602805#action_12602805
]
Geoff Cadien commented on DIRMINA-584:
--
Just for completeness here is a small patch
Maarten Bosteels wrote:
On Wed, Jun 4, 2008 at 3:45 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Steve Ulrich wrote:
Julien Vermillard wrote
On Wed, 04 Jun 2008 10:37:57 +0200
Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Julien Vermillard wrote:
I
Socket.destroy should be called when AprSession is destroyed
Key: DIRMINA-602
URL: https://issues.apache.org/jira/browse/DIRMINA-602
Project: MINA
Issue Type: Bug
On Thu, Jun 5, 2008 at 5:59 PM, Emmanuel Lecharny [EMAIL PROTECTED]
wrote:
Maarten Bosteels wrote:
On Wed, Jun 4, 2008 at 3:45 PM, Emmanuel Lecharny [EMAIL PROTECTED]
wrote:
Steve Ulrich wrote:
Julien Vermillard wrote
On Wed, 04 Jun 2008 10:37:57 +0200
Emmanuel Lecharny [EMAIL
i guys,
while browsing MINA's code, I see @Override used everywhere. I know it
can be helpful when overriding an existing method, but do you think we
need to keep them ?
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Emmanuel Lecharny wrote:
i guys,
while browsing MINA's code, I see @Override used everywhere. I know it
can be helpful when overriding an existing method, but do you think we
need to keep them ?
wdyt ?
Yes. They're very helpful when refactoring.
-Mike
I would keep them because they really help when there are changes in
super classes during a compile.
Jeff
Emmanuel Lecharny wrote:
i guys,
while browsing MINA's code, I see @Override used everywhere. I know it
can be helpful when overriding an existing method, but do you think we
need to
Hey Mike, Jeff,
Not denying these claims but just curious. Can you guys educate me as to
how it works, or helps in these cases. I never bothered to investigate this
@Override tag.
Thanks,
Alex
On Thu, Jun 5, 2008 at 6:28 PM, Jeff Genender [EMAIL PROTECTED] wrote:
I would keep them because
Jeff Genender wrote:
I would keep them because they really help when there are changes in
super classes during a compile.
Ok, pretty clear reasons why we should keep them.
Thanks Mike and Jeff !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Alex Karasulu wrote:
Hey Mike, Jeff,
Not denying these claims but just curious. Can you guys educate me as to
how it works, or helps in these cases. I never bothered to investigate this
@Override tag.
Basically (and I'm not a user of this tag), it's helpfull when you want
to override a
Yep...thats basically correct.
Its a protection for if you change a base method. Normally w/o the
annotation, you would orphan any subclasses by changing a super class
signature. With the @Override, the compiler throws an error and says
you are overriding a function that doesn't exist. Its
Hi guys,
I may be wrong, or tired, but while looking at the DefaultIoFuture class
(trunk), I discovered that the public IoFuture awaitUninterruptibly()
method is using a lock to protect a boolean flag (ready), which will
never change, because the only place where this flag is modified is also
On Thu, Jun 5, 2008 at 10:45 PM, Alex Karasulu [EMAIL PROTECTED] wrote:
Go for it and kick off the vote - let's get that RAT Maven plugin into the
project for easy legal review. If you can get us that on the vote thread
this would be most excellent.
The build needs some work - I was going to
[
https://issues.apache.org/jira/browse/ASYNCWEB-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated ASYNCWEB-15:
Attachment: ASYNCWEB-svn-props.patch
Patch for the 1.0 branch
[
https://issues.apache.org/jira/browse/ASYNCWEB-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu reassigned ASYNCWEB-15:
-
Assignee: Alex Karasulu
Fix the svn:eol-style property
--
23 matches
Mail list logo
