Re: [VOTE] Start using repository.apache.org for releases
+1 Regards, Alan On Mar 16, 2010, at 2:43 AM, Niklas Gustavsson wrote: Hi Since no-one objected on the discussion thread, here's the formal vote to move our releases to repository.apache.org. [ ] +1, do it [ ] 0 [ ] -1, don't do it because... /niklas
Re: Unable to build Vysper
On Tue, Mar 16, 2010 at 4:53 PM, Rick Bullotta wrote: > FYI, mvn clean install worked fine. Great. Yes, this is a known bug in how Maven handles test JARs. I'm planning to move the test support classes into a separate module which will fix this issue. /niklas
Re: Black/White List in FTP Server
2010/3/16 Niklas Gustavsson : > On Tue, Mar 16, 2010 at 2:52 PM, Sai Pullabhotla > wrote: >> If a filter can make use of this event, why not an >> Ftplet? > > To me, because writing your own Ftplet should require minimal > knowledge of the internals of FtpServer. Compare this to writing a > Servlet and your own Valve for Tomcat. > > /niklas niklas opinion makes sense but, of course, some users might need this sessionCreated event. My suggestion is that we wait until some of the inner workings of MINA 3.0 are agreed upson so we don't have to make a decision based on a threading/event model that is very likely to change. The IPFilter that can act as a blacklist or a whitelist is a pretty clever idea. What about programmatically changing the IPFilter? as if you want to update the blacklist but the whitelist 'version' is in use...
RE: Unable to build Vysper
FYI, mvn clean install worked fine. -Original Message- From: Rick Bullotta [mailto:rick.bullo...@burningskysoftware.com] Sent: Tuesday, March 16, 2010 11:47 AM To: dev@mina.apache.org Subject: Unable to build Vysper When running the Maven build on the latest trunk code from SVN (mvn compile), the build fails with the error shown below. Any thoughts? Thanks, Rick Downloading: http://oss.sonatype.org/content/repositories/sourceforge-releases/org/apache /vysper/vysper-core/1.0.0-SNAPSHOT/vysper-core-1.0.0-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT' in repository ehcache-repo (http://oss.sonatype.org/content/repositories/sourceforge-releases) Downloading: http://repository.apache.org/snapshots/org/apache/vysper/vysper-core/1.0.0-S NAPSHOT/vysper-core-1.0.0-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.vysper -DartifactId=vysper-core -Dversion=1.0.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.vysper -DartifactId=vysper-core -Dversion=1.0.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -repositoryId=[id] Path to dependency: 1) org.apache.vysper.extensions:xep0060-pubsub:jar:1.0.0-SNAPSHOT 2) org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.vysper.extensions:xep0060-pubsub:jar:1.0.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), central (http://repo1.maven.org/maven2), ehcache-repo (http://oss.sonatype.org/content/repositories/sourceforge-releases)
Unable to build Vysper
When running the Maven build on the latest trunk code from SVN (mvn compile), the build fails with the error shown below. Any thoughts? Thanks, Rick Downloading: http://oss.sonatype.org/content/repositories/sourceforge-releases/org/apache /vysper/vysper-core/1.0.0-SNAPSHOT/vysper-core-1.0.0-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT' in repository ehcache-repo (http://oss.sonatype.org/content/repositories/sourceforge-releases) Downloading: http://repository.apache.org/snapshots/org/apache/vysper/vysper-core/1.0.0-S NAPSHOT/vysper-core-1.0.0-SNAPSHOT-tests.jar [INFO] Unable to find resource 'org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.vysper -DartifactId=vysper-core -Dversion=1.0.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.vysper -DartifactId=vysper-core -Dversion=1.0.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -repositoryId=[id] Path to dependency: 1) org.apache.vysper.extensions:xep0060-pubsub:jar:1.0.0-SNAPSHOT 2) org.apache.vysper:vysper-core:test-jar:tests:1.0.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.vysper.extensions:xep0060-pubsub:jar:1.0.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), central (http://repo1.maven.org/maven2), ehcache-repo (http://oss.sonatype.org/content/repositories/sourceforge-releases)
Re: [vysper] java.security.KeyStoreException running XMPPServer with Apache Harmony
On Tue, Mar 16, 2010 at 10:12, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 10:00 AM, Bernd Fondermann > wrote: >> Yes. >> >> org.apache.vysper.xmpp.server.ServerFeatures.setStartTLSRequired(false); >> >> - or - >> >> > class="org.apache.vysper.xmpp.server.ServerFeatures"> >> ... >> >> >> >> Hope that works, long not tried... > > Sounds like this needs a test :-) exactly! found notes today that SSL and SASL have to be covered by tests. :-) Bernd
Re: Black/White List in FTP Server
On Tue, Mar 16, 2010 at 2:52 PM, Sai Pullabhotla wrote: > If a filter can make use of this event, why not an > Ftplet? To me, because writing your own Ftplet should require minimal knowledge of the internals of FtpServer. Compare this to writing a Servlet and your own Valve for Tomcat. /niklas
Re: Black/White List in FTP Server
Yes, you are correct, and I did read that note in the MINA documentation. Essentially, an IP filter should make use of Session Created to filter out unwanted clients. Filtering may take a while depending on how big the list is or how efficient the filtering algorithm is. If a filter can make use of this event, why not an Ftplet? I agree that Ftplet authors should know what they are doing when using this method, but do not see any harm in making this event available. Just throwing in my ideas for discussion/evaluation, not that I really want it to be included. :) Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 8:31 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 2:24 PM, Sai Pullabhotla > wrote: >> Currently, we call the Ftplet.onConnect from the sessionOpened method. >> May be we should add yet another method to the Ftplets to indicate a >> sessionCreated event, in case if some one wants to use it? > > If I recall correctly, sessionCreated is called from the IO processor > thread and we would therefore shortcut our threading model if we > expose it to Ftplets (letting an Ftplet block the entire listener). My > understanding is that sessionCreated is useful if you really know what > you're doing and I'm not sure that should be required by Ftplet users > :-) > > /niklas >
Re: Black/White List in FTP Server
On Tue, Mar 16, 2010 at 2:24 PM, Sai Pullabhotla wrote: > Currently, we call the Ftplet.onConnect from the sessionOpened method. > May be we should add yet another method to the Ftplets to indicate a > sessionCreated event, in case if some one wants to use it? If I recall correctly, sessionCreated is called from the IO processor thread and we would therefore shortcut our threading model if we expose it to Ftplets (letting an Ftplet block the entire listener). My understanding is that sessionCreated is useful if you really know what you're doing and I'm not sure that should be required by Ftplet users :-) /niklas
Re: Black/White List in FTP Server
I would not disagree that the IP restrictions should be handled by the filters, but at the same time. I was just looking for other ways that can be used when the filters do not provide the functionality the user wants. I do See that MINA propagates two different events - 1. session opened 2. session created Currently, we call the Ftplet.onConnect from the sessionOpened method. May be we should add yet another method to the Ftplets to indicate a sessionCreated event, in case if some one wants to use it? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:38 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 1:29 PM, Sai Pullabhotla > wrote: >> However, with FTPS (Implicit), the SSL negotiation is initiated prior >> to sending the onConnect event to the Ftplets. To be precise, the >> client does get the server's certificate before onConnect is called. I >> was wondering if this should be done differently so no data is >> exchanged (read/written) unless onConnect of all Ftplets are executed. > > With "data" in this case, we're only talking about the SSL handshake, > right? I think onConnect should indicate that the socket (session) is > established. With SSL, the socket might be ended (e.g due to > certificate validation failing) during the handshake. So, I think the > current behavior is correct. Besides, I think IP restriction is better > handled in the filter chain, rather than in Ftplets which I think > should contain things more like "business logic" (if you excuse the > very broad use of that term :-). > > /niklas >
Re: Black/White List in FTP Server
On Tue, Mar 16, 2010 at 1:29 PM, Sai Pullabhotla wrote: > However, with FTPS (Implicit), the SSL negotiation is initiated prior > to sending the onConnect event to the Ftplets. To be precise, the > client does get the server's certificate before onConnect is called. I > was wondering if this should be done differently so no data is > exchanged (read/written) unless onConnect of all Ftplets are executed. With "data" in this case, we're only talking about the SSL handshake, right? I think onConnect should indicate that the socket (session) is established. With SSL, the socket might be ended (e.g due to certificate validation failing) during the handshake. So, I think the current behavior is correct. Besides, I think IP restriction is better handled in the filter chain, rather than in Ftplets which I think should contain things more like "business logic" (if you excuse the very broad use of that term :-). /niklas
Re: Black/White List in FTP Server
Cool, I will see what I can do. I was also looking at other ways to implement this feature and looks like one should be able to make use of an Ftplet and capture the onConnect event to determine if the connection should be allowed or not. I did some quick tests and found the following: Plain FTP/Explicit SSL does not seem to have any visible issues. Check the client's IP in the Ftplet's onConnect and return DISCONNECT if the client connection should not be accepted. However, with FTPS (Implicit), the SSL negotiation is initiated prior to sending the onConnect event to the Ftplets. To be precise, the client does get the server's certificate before onConnect is called. I was wondering if this should be done differently so no data is exchanged (read/written) unless onConnect of all Ftplets are executed. What do you think? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 7:18 AM, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 1:05 PM, Sai Pullabhotla > wrote: >> Does this mean you want to wait until Mina 3.0, or should we start >> working on the FTP Server right away and share relevant code with >> MINA? > > I think we can start right away and copy the code upstream until we > move FtpServer to MINA 3.0. > > /niklas >
Re: Black/White List in FTP Server
On Tue, Mar 16, 2010 at 1:05 PM, Sai Pullabhotla wrote: > Does this mean you want to wait until Mina 3.0, or should we start > working on the FTP Server right away and share relevant code with > MINA? I think we can start right away and copy the code upstream until we move FtpServer to MINA 3.0. /niklas
Re: Black/White List in FTP Server
Does this mean you want to wait until Mina 3.0, or should we start working on the FTP Server right away and share relevant code with MINA? Regards, Sai Pullabhotla On Tue, Mar 16, 2010 at 1:13 AM, Niklas Gustavsson wrote: > On Mon, Mar 15, 2010 at 7:27 PM, Sai Pullabhotla > wrote: >> I've been trying to implement white/black lists in FTP server and >> thought of running my findings/ideas with you guys. > > +1 to all you say. I think we should aim to land this work in MINA 3.0. > > /niklas >
Re: [VOTE] Start using repository.apache.org for releases
On Tue, Mar 16, 2010 at 12:00, Niklas Gustavsson wrote: > On Tue, Mar 16, 2010 at 11:56 AM, Julien Vermillard > wrote: >> +1 for me as long as someone else does the maven configuration job :) +1 > I'll set up the Vysper and FtpServer 1.1.x builds (update POM to use > the Apache parent and update the release procedure) to use > repository.a.o if this vote passes. Given that knowledge, getting MINA > and Asyncweb updated should not be that hard, but I have no experience > of releasing either of these so it might be best done in cooperation. +1 Bernd
Re: [VOTE] Start using repository.apache.org for releases
On Tue, Mar 16, 2010 at 11:56 AM, Julien Vermillard wrote: > +1 for me as long as someone else does the maven configuration job :) I'll set up the Vysper and FtpServer 1.1.x builds (update POM to use the Apache parent and update the release procedure) to use repository.a.o if this vote passes. Given that knowledge, getting MINA and Asyncweb updated should not be that hard, but I have no experience of releasing either of these so it might be best done in cooperation. /niklas
Re: [VOTE] Start using repository.apache.org for releases
Le Tue, 16 Mar 2010 10:43:41 +0100, Niklas Gustavsson a écrit : > Hi > > Since no-one objected on the discussion thread, here's the formal vote > to move our releases to repository.apache.org. > > [ ] +1, do it > [ ] 0 > [ ] -1, don't do it because... > > /niklas +1 for me as long as someone else does the maven configuration job :) I'm not a maven expert but repository.a.o looks like much nicer than crawling in the www directories. -- Julien Vermillard Archean Technologies http://www.archean.fr signature.asc Description: PGP signature
[ANNOUNCE] Apache FtpServer 1.0.4 released
The Apache MINA project is pleased to announce the release of FtpServer 1.0.4. This release fixes the issues found since the release of 1.0.3. We consider this a stable and production ready release. We welcome you to try it out. We have tried to make it simple both to embed within your application as well as running it standalone. The latest release is now available here: http://mina.apache.org/ftpserver/downloads.html The change log for this release is: Bug * [FTPSERVER-336] - BaseUser class from ftpserver-core bundle can't be used in other bundles in an OSGi environment * [FTPSERVER-340] - DefaultFtpServer throws NPE on restart and lack documentation on restart not being supported * [FTPSERVER-342] - Incorrect reply codes from PORT and EPRT commands * [FTPSERVER-345] - Update the replies of MD5 and MMD5 commands to include the file path in double quotes when there are spaces in the path * [FTPSERVER-347] - Multiline replies does not handle lines starting with numbers * [FTPSERVER-348] - MKD command on linux checks for path separator before passing to filesystemview Improvement * [FTPSERVER-341] - Handling invalid port number from client Task * [FTPSERVER-353] - Upgrade to MINA 2.0.0-RC1 The full release notes can found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10571&styleName=Html&version=12314283 Thanks for the feedback that made this release possible!
Re: [VOTE] Start using repository.apache.org for releases
On Tue, Mar 16, 2010 at 10:46 AM, Emmanuel Lecharny wrote: > Hmmm... It's all about using Nexus, right ? Yes, Nexus is what's running on repository.apache.org. /niklas
Re: [VOTE] Start using repository.apache.org for releases
On 3/16/10 10:43 AM, Niklas Gustavsson wrote: Hi Since no-one objected on the discussion thread, here's the formal vote to move our releases to repository.apache.org. [ ] +1, do it [ ] 0 [ ] -1, don't do it because... /niklas Hmmm... It's all about using Nexus, right ? -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
[VOTE] Start using repository.apache.org for releases
Hi Since no-one objected on the discussion thread, here's the formal vote to move our releases to repository.apache.org. [ ] +1, do it [ ] 0 [ ] -1, don't do it because... /niklas
AW: Calling NioSocketSession.toString() causes java.lang.Error
Hi Emmanuel, created https://issues.apache.org/jira/browse/DIRMINA-771 what happens next? Regards Jörg -Ursprüngliche Nachricht- Von: Emmanuel Lecharny [mailto:elecha...@gmail.com] Gesendet: Mittwoch, 3. März 2010 12:22 An: dev@mina.apache.org Betreff: Re: Calling NioSocketSession.toString() causes java.lang.Error On 3/3/10 11:28 AM, Michelberger, Joerg wrote: > Hi there, > > using MINA 2.0.0 RC1 and have a log statement in my > IOHandler.exceptionCaught() method plugged on top of a NioSocketSession. > The log statement calls toString() on the IoSession passed in. In some cases > I get the appended Exception. > Thats not good. > Yeah, sure. Can you create a JIRA for this bug ? Should be easy to fix, as it's probably trying to print a closed socket. > Regards Jörg > > 2010-03-03 09:51:46,818 WARN [NioProcessor-2] > filterchain.DefaultIoFilterChain::callNextExceptionCaught() > (DefaultIoFilterChain.java:483) - Unexpected exception from exceptionCaught > handler. java.lang.Error: java.net.SocketException: Socket operation on > nonsocket: getsockname > at sun.nio.ch.Net.localAddress(Net.java:125) > at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430) > at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147) > at java.net.Socket.getLocalSocketAddress(Socket.java:703) > at > org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158) > at > org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:47) > at > org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1139) > at > com.ndsatcom.cecsdatamodel.cecsclient.newmulti.mina.MinaCecsIoHandler.exceptionCaught(MinaCecsIoHandler.java:33) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:694) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:46) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:788) > at > org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:111) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:468) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:397) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778) > at > org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778) > at > org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:345) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778) > at > org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:388) > at > org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:210) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:535) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:497) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:61) > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:974) > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) > at > java.util.concurrent.ThreadPoolExe
Fwd: Will your project feature at ApacheCon North America 2010?
The next ApacheCon is coming up. They are doing the same approach as last time, where projects organize into full day tracks (see more below). I'm thinking we might have a hard time filling a complete track, but we might collaborate with other projects on filling some sessions. What do you think, anyone interested in giving a talk? /niklas -- Forwarded message -- From: Nóirín Shirley for the ApacheCon 2010 Planning Team Date: Tue, Mar 16, 2010 at 12:22 AM Subject: Will your project feature at ApacheCon North America 2010? To: p...@apache.org, gene...@incubator.apache.org Dear PMC, ApacheCon 2010 North America is just around the corner, and it's time to roll out a program for this event! We'll be at the Westin Peachtree Plaza in Atlanta, GA, from 1st-5th November. Will you be there? If you'd like your project to be featured in the main conference tracks, please discuss it with your project community. A schedule is not needed at this time, but you have a coherent vision for a one day (6 sessions) program. We are particularly interested in programs that fit current themes, from Servers to Cloud Computing, from Search to NoSQL, as well as Innovation and Emerging Technologies. You'll also need to identify a track program organizer, who will be responsible for liaising with the planners, as well as collecting the session descriptions, speaker bios, and other programming information. Your track organizer should email planners-2010...@apachecon.com with your project's intent to participate, before Sunday, March 21st. Projects will be notified by the end of March as to whether their proposal has been accepted, and full programming should be completed by April 16th. Note that the planning committee will review the proposed tracks, and may offer feedback or specify necessary changes to ensure the success of the event. All accepted speakers (not co-presenters) qualify for general conference admission and a minimum of two nights lodging at the conference hotel. Additional hotel nights and travel assistance are possible, depending on the number of presentations given and type of assistance needed. If you think main track programming isn't for you, don't worry! You should expect to hear from us shortly about opportunities to present Training Sessions, as well as evening Meetups and other events. Looking forward to seeing you in Atlanta! Your ApacheCon 2010 NA Planning Team
Re: [vysper] java.security.KeyStoreException running XMPPServer with Apache Harmony
On Tue, Mar 16, 2010 at 10:00 AM, Bernd Fondermann wrote: > Yes. > > org.apache.vysper.xmpp.server.ServerFeatures.setStartTLSRequired(false); > > - or - > > class="org.apache.vysper.xmpp.server.ServerFeatures"> > ... > > > > Hope that works, long not tried... Sounds like this needs a test :-) /niklas
Re: Fwd: Google Summer of Code: Bring out your projects
On Tue, Mar 16, 2010 at 8:31 AM, Ashish wrote: > Which project are we submitting? I've added the BOSH/WebSockets project: https://issues.apache.org/jira/browse/VYSPER-189 /niklas
[jira] Created: (VYSPER-189) GSoC: Implement WebSockets/BOSH for XMPP AJAX clients
GSoC: Implement WebSockets/BOSH for XMPP AJAX clients -- Key: VYSPER-189 URL: https://issues.apache.org/jira/browse/VYSPER-189 Project: VYSPER Issue Type: Task Components: extension Reporter: Niklas Gustavsson Assignee: Niklas Gustavsson Apache Vysper is a modular, Java based XMPP/Jabber server. This project aims at developing a Vysper extension that enables AJAX clients to be a XMPP client, for example making it simple to expose IM/chat functionality in web apps. BOSH (XEP-124, XEP-206) defines a protocol where XMPP/Jabber can be used by AJAX clients. Also, with the development of WebSockets within the HTML5 work, WebSockets could be used as a way for browsers to communicate with Apache Vysper. This project could use either (or both) these protocols. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vysper] java.security.KeyStoreException running XMPPServer with Apache Harmony
On Tue, Mar 16, 2010 at 07:57, Jean-Sebastien Delfino wrote: > Bernd Fondermann wrote: >> >> On Sat, Mar 13, 2010 at 18:51, Jean-Sebastien Delfino >> wrote: >>> >>> Bernd Fondermann wrote: On Thu, Mar 11, 2010 at 08:58, Niklas Gustavsson wrote: >>> >>> ... >>> > Perhaps we should make this configurable on AbstractTLSContextFactory > and allow for injecting a TLSContextFactory into XMPPServer? Anyways, > could you open a JIRA issue for this problem and we'll have a look. >>> >>> Done: https://issues.apache.org/jira/browse/VYSPER-188 >>> > It would be very interesting to later on hear more about your results > of running Vysper on Harmony. >>> >>> ... >>> >>> I'm able to build the server and core modules, run XMPPServer, >> >> How do you do that? Our Harmony-based CI env exits because the apt >> tool is not available in Harmony. > > Like Niklas is doing too now [1]. I'm building spec-compliance with another > JDK, all other modules with Harmony, and spec-compliance is just picked up > from my local Maven repos. > >>> then I'm >>> hitting that KeyStore exception. >>> >>> Patching the code to use BKS gets me much further (see my additional >>> comments in VYSPER-188). >> >> Great! >> >>> That's a good sign, but I don't know yet if there's >>> other problems downstream hiding behind this one :) >> >> Do we need to get some Harmony people on board? >> > > I've asked on d...@harmony for how to trace SSL [2], and added the trace to > VYSPER-188. > > I'm not sure where to go from there, as the trace doesn't contain much, and > I really need this working even without SSL/TLS. > > Is there a way to disable SSL/TLS altogether with Vysper so that it won't > even try to use SSL? Yes. org.apache.vysper.xmpp.server.ServerFeatures.setStartTLSRequired(false); - or - ... Hope that works, long not tried... Bernd
Re: [jira] Commented: (VYSPER-188) java.security.KeyStoreException running XMPPServer with Apache Harmony
On Tue, Mar 16, 2010 at 07:42, Jean-Sebastien Delfino (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/VYSPER-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845741#action_12845741 > ] > > Jean-Sebastien Delfino commented on VYSPER-188: > --- > > I asked on d...@harmony [1]. > > Here's the output with > -Djsse=engine,socket,alert,record,conn_state,prf,ssocket. I'm not sure what > to do with that trace though :) mmhhh. According to the SSH RFCs, message type 128 is from the "reserved for client protocol" range, while type 21 is SSH_MSG_NEWKEYS. so, seems to be a problem in the (pre-)authentication handshake, maybe. Bernd > > Starting test Vysper server... > 23:33:24,420 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | replacing the > storage provider registry with > org.apache.vysper.storage.inmemory.MemoryStorageProviderRegistry > 23:33:24,807 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > servicediscovery (1.0beta) > 23:33:24,812 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > roster (1.0beta) > 23:33:24,916 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > XEP-0092 Software Version (1.0) > 23:33:24,918 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > XEP-0202 Entity Time (1.0) > 23:33:24,935 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > XEP-0054 Vcard-temp (1.0) > 23:33:24,936 | ERROR | > org.apache.vysper.xmpp.modules.extension.xep0054_vcardtemp.VcardTempModule | > no VcardTempPersistenceManager found > 23:33:24,936 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > XEP-0199 XMPP Ping (2.0) > 23:33:24,938 | INFO | > org.apache.vysper.xmpp.server.DefaultServerRuntimeContext | adding module... > XEP-0049 Private Data (1.2) > 23:33:24,939 | ERROR | > org.apache.vysper.xmpp.modules.extension.xep0049_privatedata.PrivateDataModule > | no PrivateDataPersistenceManager found > Test Vysper server started... > 23:33:55,709 | DEBUG | org.apache.vysper.xmpp.protocol.SessionStateHolder | > session state changed to = INITIATED > 23:33:55,777 | DEBUG | org.apache.vysper.xmpp.protocol.SessionStateHolder | > session state changed to = STARTED > 23:33:55,797 | DEBUG | org.apache.vysper.xmpp.protocol.SessionStateHolder | > session state changed to = ENCRYPTION_STARTED > record[pool-2-thread-3] SSLRecordProtocol.unwrap: BEGIN [ > record[pool-2-thread-3] Non v3.1 message type:128 > record[pool-2-thread-3] SSLRecordProtocol:unwrap ] END, SSLv2 type > record[pool-2-thread-3] SSLRecordProtocol.wrap: TLSPlaintext.fragment[774]: > 02 00 00 46 03 01 4B 9F 26 56 1C 59 3E 0D 12 D6 > A3 76 7F BB A8 0E 54 C6 1C 8A 13 8C F1 F6 D0 55 > 17 28 C4 D2 80 38 20 F1 1C FA 35 71 83 F1 8A 55 > 92 50 32 E3 CA 6E 2B E4 0D 0E F0 B8 46 CC 03 B9 > FD F5 65 4B 9F 26 56 00 16 00 0B 00 01 E7 00 01 > E4 00 01 E1 30 82 01 DD 30 82 01 89 A0 03 02 01 > 02 02 04 15 F4 C7 12 30 0B 06 09 2A 86 48 86 F7 > 0D 01 01 04 30 6D 31 0B 30 09 06 03 55 04 06 13 > 02 53 45 31 12 30 10 06 03 55 04 07 13 09 53 74 > 6F 63 6B 68 6F 6C 6D 31 25 30 23 06 03 55 04 0A > 13 1C 42 6F 67 75 73 54 72 75 73 74 4D 61 6E 61 > 67 65 72 46 61 63 74 6F 72 79 20 49 6E 63 31 0F > 30 0D 06 03 55 04 0B 13 06 58 58 58 20 43 41 31 > 12 30 10 06 03 55 04 03 13 09 62 6F 67 75 73 2E > 63 6F 6D 30 1E 17 0D 31 30 30 33 31 32 31 38 34 > 35 31 36 5A 17 0D 32 30 30 33 30 39 31 38 34 35 > 31 36 5A 30 6D 31 0B 30 09 06 03 55 04 06 13 02 > 53 45 31 12 30 10 06 03 55 04 07 13 09 53 74 6F > 63 6B 68 6F 6C 6D 31 25 30 23 06 03 55 04 0A 13 > 1C 42 6F 67 75 73 54 72 75 73 74 4D 61 6E 61 67 > 65 72 46 61 63 74 6F 72 79 20 49 6E 63 31 0F 30 > 0D 06 03 55 04 0B 13 06 58 58 58 20 43 41 31 12 > 30 10 06 03 55 04 03 13 09 62 6F 67 75 73 2E 63 > 6F 6D 30 5C 30 0D 06 09 2A 86 48 86 F7 0D 01 01 > 01 05 00 03 4B 00 30 48 02 41 00 CD DF 3D 26 37 > FE 4B 30 0A 0F BA 8E 80 F9 2D BA 72 89 86 FC 10 > E0 BC 29 15 2A 77 22 21 7D A1 DF C8 89 37 9E E0 > 6D C4 37 4B 96 6C 56 CC 9A C9 69 BE 79 84 F4 D8 > B9 40 D7 25 90 8D 0F 83 0A 4B 91 02 03 01 00 01 > A3 13 30 11 30 0F 06 03 55 1D 13 04 08 30 06 02 > 04 7F FF FF FF 30 0B 06 09 2A 86 48 86 F7 0D 01 > 01 04 03 41 00 8F DA 1F 3D 7D EE E4 D3 D8 83 E1 > 71 45 CF 4A BA 92 4B 16 D8 73 71 94 68 E9 3C 1A > D1 69 E7 24 E3 96 B5 F7 41 09 19 1E CA 03 BB 1D > 7E 9F 2C 96 63 AF 2F F3 03 92 59 18 09 14 1C B0 > 69 4F C8 39 35 0C 00 00 C9 00 40 F5 2A FF 3C E1 > B1 29 40 18 11 8D 7C 84 A7 0A 72 D6 86 C4 03 19 > C8 07 29 7A CA 95 0C D9 96 9F AB D0 0A 50 9B 02 > 46 D3 08 3D 66 A4 5D 41 9F 9C 7C BD 89 4B 22 19 > 26 BA AB A2 5E C3 55 E9 2A 05 5F 00 01 02 00 40 > 9D 80 16 10 3B BB B0 78 3C 47 CE DC 0A 84 87 50 > 09 68 6D B5 07 D3 51 18 AA 31 0E 2D C8
Re: Fwd: Google Summer of Code: Bring out your projects
On Fri, Mar 12, 2010 at 15:35, Ashish wrote: > On Fri, Mar 12, 2010 at 7:54 PM, Emmanuel Lecharny > wrote: >> On 3/12/10 2:53 PM, Niklas Gustavsson wrote: >>> >>> Hey >>> >>> GSoC is coming up, see more below. Anyone got ideas for projects? >>> >>> I'm considering volunteering as a mentor for a project on implementing >>> BoSH/WebSockets for Vysper. +1, great! >> I always wanted to build some tooling on top of MINA, and we already found a >> name for it : >> MinaReal >> >> It would be some kind of Ethereal, with plugged protocol decoder, and using >> http://jpcap.sourceforge.net/ to capture packets. >> >> Does it sound a good idea ? > > a big +1, I just wanted to put this proposal, and here you are with the same. > > WebSockets is also a real good addition. May be we can have 2 projects :) Actually, the original idea of GSoC is the other way round: Students bring their own ideas to the projects. Obviously, it is advisable for the project itself to make as many proposals as would fit to attract many students. There is a ranking process and only the best ones get accepted. Bernd
Re: Fwd: Google Summer of Code: Bring out your projects
Which project are we submitting? On Fri, Mar 12, 2010 at 7:54 PM, Emmanuel Lecharny wrote: > On 3/12/10 2:53 PM, Niklas Gustavsson wrote: >> >> Hey >> >> GSoC is coming up, see more below. Anyone got ideas for projects? >> >> I'm considering volunteering as a mentor for a project on implementing >> BoSH/WebSockets for Vysper. >> > > I always wanted to build some tooling on top of MINA, and we already found a > name for it : > MinaReal > > It would be some kind of Ethereal, with plugged protocol decoder, and using > http://jpcap.sourceforge.net/ to capture packets. > > Does it sound a good idea ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
