Re: [VOTE] Release Apache MINA 2.0-M1
+1 > [ ]: +1, Release MINA 2.0-M1 > [ ]: 0, Abstain > [ ]: -1, Don't release MINA 2.0-M1
Re: [VOTE] Release Apache MINA 2.0-M1
[X]: +1, Release MINA 2.0-M1 /Niklas
MINA at JavaOne 2008 - idea wanted
Hi, I was invited as a speaker of JavaOne 2008 and will speak about Apache MINA there. Please feel free to contact me to give me some idea about what you want to hear about MINA if you have any plan to attend this year's JavaOne. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache MINA 2.0-M1
2008-02-11 (월), 20:35 -0700, Mike Heath 쓰시길: > [X]: +1, Release MINA 2.0-M1 Nice to see you fire the vote, which means another person will get to know how to deal with the whole release procedure, as described in our developer's guide. You could ask me or Julien if you have any questions. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: [Asyncweb][Client] Can we quiet down this logging in the client?
> The AHC seems to be logging profusely. Could we reduce that output? I > was > going to throw a log4j.properties file into the test/resources area but > seems like the project is using another logger. > > Alex > Hi Alex, the server is quite INFO verbose too, a lot of logging statement need to be moved to DEBUG, IMHO. Julien
Re: [VOTE] Release Apache MINA 2.0-M1
On Feb 11, 2008 10:35 PM, Mike Heath <[EMAIL PROTECTED]> wrote: > [ ]: +1, Release MINA 2.0-M1 > +1 Alex
Re: [VOTE] Release Apache MINA 2.0-M1
+1 On Feb 11, 2008 10:44 PM, José Henrique de Oliveira Varanda < [EMAIL PROTECTED]> wrote: > +1 > > 2008/2/12, Jeff Genender <[EMAIL PROTECTED]>: > > > > +1 > > > > Mike Heath wrote: > > > Hello Community, > > > > > > It looks like Maarten has resolved DIRMINA-513. I don't see any > reason > > > to hold up a 2.0-M1 release. > > > > > > There are a multitude of changes in MINA 2.0-M1, too many to enumerate > > > in a single email. A laundry list of changes going into this release > > > can be found here > > > > > > https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > > > > > This release should not be considered final nor entirely stable. It > is > > > a release so that developers using MINA know what to expect in 2.0 as > > > well as help us to find bugs and deficiencies in the API. > > > > > > [ ]: +1, Release MINA 2.0-M1 > > > [ ]: 0, Abstain > > > [ ]: -1, Don't release MINA 2.0-M1 > > > > > > -Mike > > > -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
Re: [VOTE] Release Apache MINA 2.0-M1
+1 2008/2/12, Jeff Genender <[EMAIL PROTECTED]>: > > +1 > > Mike Heath wrote: > > Hello Community, > > > > It looks like Maarten has resolved DIRMINA-513. I don't see any reason > > to hold up a 2.0-M1 release. > > > > There are a multitude of changes in MINA 2.0-M1, too many to enumerate > > in a single email. A laundry list of changes going into this release > > can be found here > > > https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > > > This release should not be considered final nor entirely stable. It is > > a release so that developers using MINA know what to expect in 2.0 as > > well as help us to find bugs and deficiencies in the API. > > > > [ ]: +1, Release MINA 2.0-M1 > > [ ]: 0, Abstain > > [ ]: -1, Don't release MINA 2.0-M1 > > > > -Mike >
Re: [VOTE] Release Apache MINA 2.0-M1
+1 Mike Heath wrote: Hello Community, It looks like Maarten has resolved DIRMINA-513. I don't see any reason to hold up a 2.0-M1 release. There are a multitude of changes in MINA 2.0-M1, too many to enumerate in a single email. A laundry list of changes going into this release can be found here https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel This release should not be considered final nor entirely stable. It is a release so that developers using MINA know what to expect in 2.0 as well as help us to find bugs and deficiencies in the API. [ ]: +1, Release MINA 2.0-M1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 2.0-M1 -Mike
[VOTE] Release Apache MINA 2.0-M1
Hello Community, It looks like Maarten has resolved DIRMINA-513. I don't see any reason to hold up a 2.0-M1 release. There are a multitude of changes in MINA 2.0-M1, too many to enumerate in a single email. A laundry list of changes going into this release can be found here https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel This release should not be considered final nor entirely stable. It is a release so that developers using MINA know what to expect in 2.0 as well as help us to find bugs and deficiencies in the API. [ ]: +1, Release MINA 2.0-M1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 2.0-M1 -Mike
[AsyncWeb] Ideas for client
I posted some use cases here: http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They still need some refinement to properly convey what I want but they're a decent start. I've also posted a hypothetical AsyncWeb Client API at http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to further promote discussion and foster more innovative ideas. I would love to here some feedback on this API. What do you like, dislike, not understand? Where do you see room for improvement? The API is really rough in places but for the most part it conveys the ideas I've had over the past week or so. Any suggestions for name changes to classes and/or methods are welcome. -Mike
Re: [AsyncWeb] Need an async client now
On Feb 11, 2008 8:20 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > On Feb 11, 2008, at 12:20 AM, Maarten Bosteels wrote: > > > On Feb 11, 2008 7:37 AM, Mike Heath <[EMAIL PROTECTED]> wrote: > > > >> The new logging features in SLF4J and removing IoSessionLogger were > >> what > >> was holding up an M1 release. Where do we stand on the logging front > >> right now? > > > > > > see my comments on http://issues.apache.org/jira/browse/DIRMINA-513 > > > > "IoSessionLogger has been removed, but I could not yet add MDC-aware > > Formatter implementations because the new SLF4J hasn't been > > released. " > > > > Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven. > > I will commit the formatter asap (hopefully tonight CET) and close > > this > > issue. > > Just curious. What are these logging features that are so important? > Hello Alan, see http://www.nabble.com/Re%3A--MINA--2.0-Milestone-1---p15092056s16868.html DIRMINA-513 wasn't that important IMO. But about two weeks ago it was the only unresolved issue for 2.0.0-M1, so we decided to fix it before cutting the first milestone. And it's fixed now. regards, Maarten
[jira] Resolved: (DIRMINA-513) get rid of IoSessionLogger
[ https://issues.apache.org/jira/browse/DIRMINA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Bosteels resolved DIRMINA-513. -- Resolution: Fixed Added org.apache.mina.util.Log4jXmlFormatter > get rid of IoSessionLogger > --- > > Key: DIRMINA-513 > URL: https://issues.apache.org/jira/browse/DIRMINA-513 > Project: MINA > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0-M1 >Reporter: Maarten Bosteels >Assignee: Maarten Bosteels >Priority: Minor > Fix For: 2.0.0-M1 > > > It seems like the next version of SLF4J is going to support MDC for > java.util.logging > The users who use java.util.logging as their logging framework will have > access to MDC > so that they can implement a formatter which prints out the MDC content. > This means we can get rid of IoSessionLogger completely and rely on > MdcInjectionFilter > However, probably SLF4J won't provide a MDC-aware Formatter implementation > for java.util.logging, so we might need to include it > in org.apache.mina.util package as an alternative solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Asyncweb][Client] Can we quiet down this logging in the client?
The AHC seems to be logging profusely. Could we reduce that output? I was going to throw a log4j.properties file into the test/resources area but seems like the project is using another logger. Alex
Re: [AsyncWeb] Need an async client now
On Feb 11, 2008, at 12:20 AM, Maarten Bosteels wrote: On Feb 11, 2008 7:37 AM, Mike Heath <[EMAIL PROTECTED]> wrote: The new logging features in SLF4J and removing IoSessionLogger were what was holding up an M1 release. Where do we stand on the logging front right now? see my comments on http://issues.apache.org/jira/browse/DIRMINA-513 "IoSessionLogger has been removed, but I could not yet add MDC-aware Formatter implementations because the new SLF4J hasn't been released. " Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven. I will commit the formatter asap (hopefully tonight CET) and close this issue. Just curious. What are these logging features that are so important? Regards, Alan
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567686#action_12567686 ] Johannes Ulfkjær Jensen commented on DIRMINA-489: - In addition to the mentioned benefits, this could also serve as the way to introduce gathering write to the framework by adding IoBuffer.isComposite(), IoBuffer.getComposites(), in the same style of having backing arrays. That being unless I missed something, which could happen as I do not know the framework that well. This same class could also be used to implement scatter read, but as far as I can see, that would mean every instance of IoAcceptor (or SessionConfig?) would need a specific IoBufferAllocator. > Composite IoBuffer > -- > > Key: DIRMINA-489 > URL: https://issues.apache.org/jira/browse/DIRMINA-489 > Project: MINA > Issue Type: New Feature > Components: Core >Reporter: David M. Lloyd > Fix For: 2.0.0-M2 > > > Provide a way to create a large IoBuffer from several smaller IoBuffers, > without copying the underlying data. > It would probably be acceptable to constrain the composite buffer in various > ways, for example by disallowing autoexpanding or otherwise changing the > capacity, the implementation could be greatly simplified. > The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncWeb] Need an async client now
On Feb 11, 2008 7:37 AM, Mike Heath <[EMAIL PROTECTED]> wrote: > The new logging features in SLF4J and removing IoSessionLogger were what > was holding up an M1 release. Where do we stand on the logging front > right now? see my comments on http://issues.apache.org/jira/browse/DIRMINA-513 "IoSessionLogger has been removed, but I could not yet add MDC-aware Formatter implementations because the new SLF4J hasn't been released. " Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven. I will commit the formatter asap (hopefully tonight CET) and close this issue. Maarten > > -Mike > > Maarten Bosteels wrote: > > On Feb 10, 2008 9:05 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > > >> On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote: > >> > >>> Hello, > >>> > >>> On Feb 10, 2008 5:28 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >>> > Is it ready? You're only at M1. What are the next milestones > planned > before you hit beta? > >>> > >>> The version numbering scheme is described at the bottom of > >>> http://mina.apache.org/downloads.html [1] > >>> > >>> IMO we should have created 2.0-M0 a few months ago. But for some > >>> reason we > >>> have been postponing it as long as there were open JIRA issues that > >>> could > >>> require an API change. > >>> > >>> According to [1] we are allowed to make API changes between M1 and M2 > >>> but of course it's nicer for the user if we can avoid it. > >>> > >>> I just had a look at JIRA at there were more open issues than I > >>> thought (6) > >>> but no show-stoppers AFAICS. > >>> > >>> Maybe we should have a vote about cutting 2.0-M0 ? > >> Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a > >> branch to stabilize your beta? Does it depend on the situation? > >> > > > > Good question. > > > > In my very humble opinion "cutting 2-0-M1" means : > > (a) creating a 2.0 branch > > and > > (b) creating a 2.0-M1 tag > > > > All further development for 2.0 would then happen on the 2.0 branch > instead > > of on the trunk. > > Isn't that the usual way to proceed ? > > > > Maarten > > > > > >> > >> Regards, > >> Alan > >> > >> > > > >
