Re: [OT] Signature. Was : Re: AW: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.
Emmanuel Lecharny wrote: I guess that when you are to comply to this kind of law as a big company, the signature is added automatically by the mail server ? Of course - and it's tiny compared to the block that the regulators force us to put on the bottom of emails from work (I work at an investment bank). I'm pretty tired of muppets whining at me that its against netiquette. The effect is that I basically can't contribute in any way. I can't see this sort of thing going away. We'll have to accept it if the net is to be a tool for adults to use. Shouldn't be too hard to make it so that mailers can fold it like they do with headers. James
Re: [OT] Signature. Was : Re: AW: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.
I'm pretty tired of muppets whining at me that its against netiquette. The effect is that I basically can't contribute in any way. Beside the side effect - whining muppets -, it's a burden for us, moderators, as a lot of such mails with such 'heavy' signatures are considered as likely spams, and we have to validate dozens of them every day... I can't see this sort of thing going away. We'll have to accept it if the net is to be a tool for adults to use. Shouldn't be too hard to make it so that mailers can fold it like they do with headers. Damn yes ! And make the lawyers stop freaking out at the same time... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [ASYNCWEB] What's the plan regarding it's leaving the sandbox?
Do you have any idea on when we can release MINA proper 2.0 M1. I ask this because I would like to see at least some beta release of asyncweb which depends on it? Furthermore we probably need to move it out of the sandbox now that the IP has been cleared but it needs some work. I will start cleaning it up to get it ready for some kind of beta release. Also are we bound to maintain the MINA API between milestone releases? Any comment? Anyone besides Trustin know what's going on? If releases without freezing the API are not possible then we might have an issue with this model. Alex
[Asyncweb] Motives behind filter-codec-http and asyncweb
Hi, MINA 2.0 is pushing the inclusion of specific protocol codecs into the core: I am specifically referring to the filter-codec-http module. Who decided on this policy and why? Trustin, according to SVN logs you commit this and it seems as though some of it was extracted from or overlaps the asycweb functionality. What is the intention for asyncweb as a subproject if it's functionality is being moved over to MINA core? Thanks, Alex
Re: [ASYNCWEB] What's the plan regarding it's leaving the sandbox?
I personally don't know what is going on but I really like AsyncWeb and would love to see it come out of the sandbox. I would be happy to also help refactoring it. Jeff Alex Karasulu wrote: Do you have any idea on when we can release MINA proper 2.0 M1. I ask this because I would like to see at least some beta release of asyncweb which depends on it? Furthermore we probably need to move it out of the sandbox now that the IP has been cleared but it needs some work. I will start cleaning it up to get it ready for some kind of beta release. Also are we bound to maintain the MINA API between milestone releases? Any comment? Anyone besides Trustin know what's going on? If releases without freezing the API are not possible then we might have an issue with this model. Alex
Re: [ASYNCWEB] What's the plan regarding it's leaving the sandbox?
Thanks Jeff. Actually I was going to start refactoring it tomorrow while checking various legal matters so we can start releasing some candidates. I'll keep you updated. I'd love to see a rich community start to grow around asyncweb as it did around MINA. It's got a lot of potential and there are many users out there even as it is. However the present direction with pushing protocols into MINA core is somewhat of an issue which will distract from this goal. Alex On Jan 20, 2008 1:07 PM, Jeff Genender [EMAIL PROTECTED] wrote: I personally don't know what is going on but I really like AsyncWeb and would love to see it come out of the sandbox. I would be happy to also help refactoring it. Jeff Alex Karasulu wrote: Do you have any idea on when we can release MINA proper 2.0 M1. I ask this because I would like to see at least some beta release of asyncweb which depends on it? Furthermore we probably need to move it out of the sandbox now that the IP has been cleared but it needs some work. I will start cleaning it up to get it ready for some kind of beta release. Also are we bound to maintain the MINA API between milestone releases? Any comment? Anyone besides Trustin know what's going on? If releases without freezing the API are not possible then we might have an issue with this model. Alex
Problem with dispose(); Access denied Exception.
Hi, I am using NioSocketConnector in my application. At the time of quiting the client I am trying to call dispose() on the connector. On calling dispose my application throws an exception and the application hangs. At the same time the CPU usage of the client goes to 100%. The exception generated at the client side is as under: 20-Jan-2008 23:30:51 org.apache.mina.common.DefaultExceptionMonitor exceptionCaught WARNING: Unexpected exception. java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:959) at java.util.concurrent.ScheduledThreadPoolExecutor.shutdownNow(ScheduledThreadPoolExecutor.java:475) at org.apache.mina.common.IdleStatusChecker.stop(IdleStatusChecker.java:120) at org.apache.mina.common.IdleStatusChecker.removeService(IdleStatusChecker.java:103) at org.apache.mina.common.AbstractIoService$1.serviceDeactivated(AbstractIoService.java:50) at org.apache.mina.common.IoServiceListenerSupport.fireServiceDeactivated(IoServiceListenerSupport.java:153) at org.apache.mina.common.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:222) at org.apache.mina.common.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:330) at org.apache.mina.common.AbstractPollingIoProcessor.remove(AbstractPollingIoProcessor.java:300) at org.apache.mina.common.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:43) at org.apache.mina.common.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:678) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Please let me know what is going wrong here. Regards, Saurabh -- View this message in context: http://www.nabble.com/Problem-with-dispose%28%29--Access-denied-Exception.-tp14984654s16868p14984654.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: ApacheDS and ipv6 support on windows
reposting as didn't seem to make it onto MINA dev list, perhaps because my subscription hadn't been confirmed ... On Jan 17, 2008 12:58 PM, Norval Hope [EMAIL PROTECTED] wrote: I'm cross posting this query to the MINA dev list about support for ApacheDS listening on an ipv6 socket on Windows. My first posting was: - I was recently flabbergasted to find out that no Sun JDK 1.5+ supports NIO sever support over ipv6 on any version of Windows (due to lack of support for dual-mode sockets in the underlying Windows stack implementation), and that the situation is only likely to be resolved in the future in JDK 7 on top of Vista (refer http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6230761 ). Hence my current understanding is that clients who want ApacheDS to listen on an ipv6 socket at start-up will have to use a Unix variant on which the JDK doesn't suffer this problem. Have I missed / misunderstsood anything here, or is there perhaps another JDK implementation with an enhanced NIO implementation (or some other cunning technique) that may represent a get out of jail card for me and my clients as far as pre-Vista Windows is concerned? Many thanks. As MINA (very sensibly) uses NIO server socket channels, it unfortunately seems there will be a problem until an extension is made to JDK 7 running on top of Vista. Note the bug link above provides a test program which can be used to verify whether a particular configuration displays the problem or not. I'm not sure if running a different JDK implementation may help due to different bundled NIO implementations, but this is most probably not really an option for my customers. Any help / comments greatly appreciated. Thanks On Jan 17, 2008 2:24 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Alex Karasulu wrote: I don't know about this but MINA may be a consideration here. Does MINA allow for IPv6? Does it care? The problem is that IPV6 is the default stack on Windows... Unless we see an urge of Linux and MacOSX stations, we may have some kind of problem... (btw, I think that linux will see a huge increase as Asus eee and similar computers will be sold by millions soon ...) But I thought that if your desktop is IPV6 based, it should still be able to communicate with a IPV4 stack, otherwise, I can't see how those millions computers installed with many flavors of W$+Virii+spywares+rootkits will be able to connect to all those retarded web sites which still use Linux + Apache HTTPd server on a IPV4 stack ... Don't know exactly... I'm not really a specialist. May be posting this question to MINA will be the best move ! I've not even considered IPv6. I'm not really interested in it at this point but if we have to move to JDK 1.7 to support it people are going to be really pissed off. Yet another ugly balancing act. Alex On Jan 16, 2008 7:14 AM, Emmanuel Lecharny [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Norval Hope wrote: Thanks for the feedback. However, my problem is the other way around - i.e. the client wants ApacheDS to listen on an ipv6 socket only. Have you tried with JRockit or IBM JVM? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com http://www.iktek.com directory.apache.org http://directory.apache.org -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[StateMachine] Job well done.
Niklas, I took a serious look at the StateMachine code and documentation today and I was impressed. StateMachine is an elegant, simple and incredibly useful library in general. I could and will use this everywhere the State pattern applies besides just in my MINA codecs. BTW the documentation on the package is most excellent. Kudos! Alex
Re: [Asyncweb] Motives behind filter-codec-http and asyncweb
Trustin Lee wrote: BTW providing AHC as a subproject might be a good idea - for now it's included as a MINA submodule, but we can provide it as a separate subproject. I'd like to know what Jeff thinks about it. +1...I like the idea of it being a sub project ;-) Trustin On Jan 21, 2008 3:05 AM, Alex Karasulu [EMAIL PROTECTED] wrote: Hi, MINA 2.0 is pushing the inclusion of specific protocol codecs into the core: I am specifically referring to the filter-codec-http module. Who decided on this policy and why? Trustin, according to SVN logs you commit this and it seems as though some of it was extracted from or overlaps the asycweb functionality. What is the intention for asyncweb as a subproject if it's functionality is being moved over to MINA core? Thanks, Alex
Re: [Asyncweb] Motives behind filter-codec-http and asyncweb
With the discussion of Dave (the original author of AsyncWeb), we agreed to include the HTTP message model and codec into MINA, and make AsyncWeb focus on more high-level features like session management and proper error handling that turn a mere codec into a real world web server component. It's like AHC (AsyncHttpClient) is trying to do the same with the MINA HTTP codec. Another extracted portion of AsyncWeb is the state machine based codec I wrote all. It's a very general codec component that can be used to build virtually any kind of protocol, so it has been included into core. The state machine based codec (org.apache.mina.filter.codec.statemachin) has absolutely no dependency on AsyncWeb. HTTP codec depends on it though. And, I personally think providing the codecs for essential protocols such as HTTP, FTP and SMTP as a part of the main MINA distribution makes a developer's life much easier when what he wants is just a minimal client / server. That's what I've been talking in ApacheCons and you can see that clearly in my slide files, which were uploaded in the official site since 2005. It's interesting that nobody argued about the road map I proposed since then. Actually we got some positive feed back related with the HTTP codec from users due to this decision. Additionally, look at our PMC charter: http://svn.apache.org/viewvc/directory/sandbox/proyal/MINA-TLP-Proposal.txt?view=markuppathrev=437911 The idea itself about the road map was proposed since the MINA PMC is formed. We can strip down what we are doing, but I see a lot of synergy of providing some protocol codecs. Of course, this doesn't mean we have provide all kinds of protocols or high level features on top of it in the official MINA distribution. BTW providing AHC as a subproject might be a good idea - for now it's included as a MINA submodule, but we can provide it as a separate subproject. I'd like to know what Jeff thinks about it. Trustin On Jan 21, 2008 3:05 AM, Alex Karasulu [EMAIL PROTECTED] wrote: Hi, MINA 2.0 is pushing the inclusion of specific protocol codecs into the core: I am specifically referring to the filter-codec-http module. Who decided on this policy and why? Trustin, according to SVN logs you commit this and it seems as though some of it was extracted from or overlaps the asycweb functionality. What is the intention for asyncweb as a subproject if it's functionality is being moved over to MINA core? Thanks, Alex -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: [StateMachine] Job well done.
Alex Karasulu wrote: Niklas, I took a serious look at the StateMachine code and documentation today and I was impressed. StateMachine is an elegant, simple and incredibly useful library in general. I could and will use this everywhere the State pattern applies besides just in my MINA codecs. BTW the documentation on the package is most excellent. Kudos! Alex Thanks! Just let me know if there is anything that could be improved. /Niklas
Re: Problem with dispose(); Access denied Exception.
Hi Saurbh, What's the environment of your application? Are you running it as a Java Applet or something similar with strict security Manager? Trustin On Jan 21, 2008 3:10 AM, Saurabh Jain [EMAIL PROTECTED] wrote: Hi, I am using NioSocketConnector in my application. At the time of quiting the client I am trying to call dispose() on the connector. On calling dispose my application throws an exception and the application hangs. At the same time the CPU usage of the client goes to 100%. The exception generated at the client side is as under: 20-Jan-2008 23:30:51 org.apache.mina.common.DefaultExceptionMonitor exceptionCaught WARNING: Unexpected exception. java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:959) at java.util.concurrent.ScheduledThreadPoolExecutor.shutdownNow(ScheduledThreadPoolExecutor.java:475) at org.apache.mina.common.IdleStatusChecker.stop(IdleStatusChecker.java:120) at org.apache.mina.common.IdleStatusChecker.removeService(IdleStatusChecker.java:103) at org.apache.mina.common.AbstractIoService$1.serviceDeactivated(AbstractIoService.java:50) at org.apache.mina.common.IoServiceListenerSupport.fireServiceDeactivated(IoServiceListenerSupport.java:153) at org.apache.mina.common.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:222) at org.apache.mina.common.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:330) at org.apache.mina.common.AbstractPollingIoProcessor.remove(AbstractPollingIoProcessor.java:300) at org.apache.mina.common.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:43) at org.apache.mina.common.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:678) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Please let me know what is going wrong here. Regards, Saurabh -- View this message in context: http://www.nabble.com/Problem-with-dispose%28%29--Access-denied-Exception.-tp14984654s16868p14984654.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com. -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Directory restructuring (Re: [Asyncweb] Motives behind filter-codec-http and asyncweb)
Okay. Then it's time for restructuring. (Excited :) We have ftpserver, AHC and Asyncweb. FtpServer and AsyncWeb are under sandbox, but I think FtpServer is mature enough to bring it up to the subproject right away because Niklas G is working on the project and Niclas Hedman told me it's pretty mature project. So... I'd like to suggest the following directory structure: / - mina - trunk - tags - branches - ahc - trunk - tags - branches - ftpserver - trunk - tags - branches Does it make sense, or would you suggest better structure? Also we could give some nicer name to AHC. What about Superluminal? (http://en.wikipedia.org/wiki/Faster-than-light) Cheers, Trustin On Jan 21, 2008 4:13 PM, Jeff Genender [EMAIL PROTECTED] wrote: Trustin Lee wrote: BTW providing AHC as a subproject might be a good idea - for now it's included as a MINA submodule, but we can provide it as a separate subproject. I'd like to know what Jeff thinks about it. +1...I like the idea of it being a sub project ;-) Trustin On Jan 21, 2008 3:05 AM, Alex Karasulu [EMAIL PROTECTED] wrote: Hi, MINA 2.0 is pushing the inclusion of specific protocol codecs into the core: I am specifically referring to the filter-codec-http module. Who decided on this policy and why? Trustin, according to SVN logs you commit this and it seems as though some of it was extracted from or overlaps the asycweb functionality. What is the intention for asyncweb as a subproject if it's functionality is being moved over to MINA core? Thanks, Alex -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: [ASYNCWEB] What's the plan regarding it's leaving the sandbox?
The reason why AsyncWeb is still in the sandbox is because there's no dedicated active committer for it. Jeff and many others have a lot of interest on the project, so it should get a new life soon, considering Dave's current absence. However, it's just too early to say that it's ready to get out of the sandbox. It is also needed to clarify that MINA core doesn't contain HTTP codec. One submodule of MINA does, and this inclusion has been agreed when AsyncWeb is imported at the very initial discussion. Moreover, AsyncWeb is not the only module that depends on the HTTP codec submodule. AHC (AsyncHttpClient) also depends on it. And, merging AsyncWeb and AHC into one module was discussed before and we decided to stay as in the current state. The bottom line is that we are still in the course of evolution and we can discuss about project segmentation after some visible changes in AsyncWeb or AHC occurs. Trustin On Jan 21, 2008 3:15 AM, Alex Karasulu [EMAIL PROTECTED] wrote: Thanks Jeff. Actually I was going to start refactoring it tomorrow while checking various legal matters so we can start releasing some candidates. I'll keep you updated. I'd love to see a rich community start to grow around asyncweb as it did around MINA. It's got a lot of potential and there are many users out there even as it is. However the present direction with pushing protocols into MINA core is somewhat of an issue which will distract from this goal. Alex On Jan 20, 2008 1:07 PM, Jeff Genender [EMAIL PROTECTED] wrote: I personally don't know what is going on but I really like AsyncWeb and would love to see it come out of the sandbox. I would be happy to also help refactoring it. Jeff Alex Karasulu wrote: Do you have any idea on when we can release MINA proper 2.0 M1. I ask this because I would like to see at least some beta release of asyncweb which depends on it? Furthermore we probably need to move it out of the sandbox now that the IP has been cleared but it needs some work. I will start cleaning it up to get it ready for some kind of beta release. Also are we bound to maintain the MINA API between milestone releases? Any comment? Anyone besides Trustin know what's going on? If releases without freezing the API are not possible then we might have an issue with this model. Alex -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
