Sign up for ApacheCon US by 14 August and save up to $500!
-- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org ---BeginMessage--- Sign up for ApacheCon US by 14 August and save up to $500! This year's ApacheCon US promises to deliver our most extensive program to date, and largest anticipated gathering of the global Apache community to celebrate the ASF's milestone 10th Anniversary. The San Francisco Bay Area is where the very first ASF official user conference was held, and we hope that you will join us in celebrating the ASF's success! Apache members, code contributors, users, developers, system administrators, business managers, service providers, and vendors will convene 2-6 November in Oakland, California, for a week of training, presentations, sharing and hacking. ApacheCon US 2009 features new content tracks, MeetUps, and GetTogethers, as well as a number of events open to the public free of charge, such as the Hackathon and 2-day BarCampApache, in appreciation of their support over the past decade. Be sure to register by 14 August to save up to $500! To sign up, visit http://www.us.apachecon.com/ Those wishing to attend ApacheCon, but may be unable to do so due to financial reasons are encouraged to apply for Travel Assistance by completing the form at http://www.apache.org/travel/ Financial support for flights, accommodation, subsistence, and conference fees are availablAnyone involved in Open Source is welcome to apply for financial support for flights, accommodation, subsistence and Conference fees. Hurry, applications close on 17 August. Conference sponsor, exhibitor, and community partnerships are also available: please contact Delia Frees at de...@apachecon.com for details. # # # - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org ---End Message---
Re: [vysper][pusub] pubsub entity
Hi! On Fri, Aug 7, 2009 at 16:20, Bernd Fondermannbf_...@brainlounge.de wrote: Michael Jakl wrote: The extension is completely agnostic about the to address, it'll happily take no to address as well (subdomain installation). So to have two pubsubs running side by side, either pubsub1.vysper.org and pubsub2.vysper.org, or pubs...@vysper.org and pubs...@vysper.org, we'd have to still do some works. But that's fine for now. I think this is part of the Component architecture, isn't it? I'm not sure if our module should verify that it's the correct recipient of a message. I wasn't aware of the goal to have multiple instances of the extension running in one Vysper instance since it already supports multiple collection nodes and leaf nodes, but I think it should be no problem as long as the ProtocolWorker(?) routes the stanzas to the correct instance. Maybe we should record such open tasks as 'improvement'- or 'feature'-JIRAs so we can keep track of them. Yes. Should we create a new JIRA-component (XEP-0114)? Michael
Re: [Vysper] Stanzas for a module without namespace
Hi! On Sun, Aug 9, 2009 at 22:35, Niklas Gustavssonnik...@protocol7.com wrote: In the MUC XEP, implementations should also support the old groupchat protocol. This was defined before the extension-based-on-namespaces approach was invented and thus use regular stanzas without namespaces, for example: Enter a room: presence from='ha...@shakespeare.lit/pda' to='darkc...@chat.shakespeare.lit/thirdwitch'/ darkc...@chat.shakespeare.lit in the example is a room in the group chat. What would be the best way to route such messages to the appropriate handler? Maybe component support will handle this by being able to replace the default presence handler completely? Routing via subdomain seems to be the only viable alternative. Only broadcasting to all modules might work too, but doesn't sound as clean. I don't know whether it's a good idea to register modules with a specific to address? But that is very close to the subdomain routing of the component support... . Michael
Re: [vysper][pusub] pubsub entity
On Mon, Aug 10, 2009 at 09:28, Michael Jakljakl.mich...@gmail.com wrote: Hi! On Fri, Aug 7, 2009 at 16:20, Bernd Fondermannbf_...@brainlounge.de wrote: Michael Jakl wrote: The extension is completely agnostic about the to address, it'll happily take no to address as well (subdomain installation). So to have two pubsubs running side by side, either pubsub1.vysper.org and pubsub2.vysper.org, or pubs...@vysper.org and pubs...@vysper.org, we'd have to still do some works. But that's fine for now. I think this is part of the Component architecture, isn't it? I'm not sure if our module should verify that it's the correct recipient of a message. I wasn't aware of the goal to have multiple instances of the extension running in one Vysper instance since it already supports multiple collection nodes and leaf nodes, It's not a goal, but I'd like to understand what the current limitations might be. And, if you think of it for a second, two pubsubs for two distinct business needs could make sense. but I think it should be no problem as long as the ProtocolWorker(?) routes the stanzas to the correct instance. That's right, the core has to make sure to route correctly. But the pubsub part or any other extension has to somehow make the information available which stanzas it expects to have routed to it (as handlers do, too). And that information is not in pubsub right now... Maybe we should record such open tasks as 'improvement'- or 'feature'-JIRAs so we can keep track of them. ... and that's what we have to keep track of in respect to the pubsub module. Yes. Should we create a new JIRA-component (XEP-0114)? We could have a JIRA for that, too (if there isn't already). Bernd
[jira] Commented: (DIRMINA-477) Update page about differences between 1.x and 2.x
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741310#action_12741310 ] Ashish Paliwal commented on DIRMINA-477: Have added some basic details on JMX and Spring integration. Since the modules have been re-written, adding precise differences shall not help. Do we know of any other stuff that needs to be documented or we close this issue? Update page about differences between 1.x and 2.x - Key: DIRMINA-477 URL: https://issues.apache.org/jira/browse/DIRMINA-477 Project: MINA Issue Type: Task Components: Web Site / Documentation Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 2.0.0-RC1 Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-477) Update page about differences between 1.x and 2.x
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Paliwal reassigned DIRMINA-477: -- Assignee: Ashish Paliwal (was: Trustin Lee) Update page about differences between 1.x and 2.x - Key: DIRMINA-477 URL: https://issues.apache.org/jira/browse/DIRMINA-477 Project: MINA Issue Type: Task Components: Web Site / Documentation Reporter: Trustin Lee Assignee: Ashish Paliwal Fix For: 2.0.0-RC1 Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-575) Add the missing Javadoc, add some comments
[ https://issues.apache.org/jira/browse/DIRMINA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741312#action_12741312 ] Ashish Paliwal commented on DIRMINA-575: This JIRA issue is very generic and we may not be able to close it. We may choose to create specific JIRA issues for places where we want to add documentation and close this issue. wdyt? Add the missing Javadoc, add some comments -- Key: DIRMINA-575 URL: https://issues.apache.org/jira/browse/DIRMINA-575 Project: MINA Issue Type: Task Components: Web Site / Documentation Reporter: Emmanuel Lecharny Priority: Blocker Fix For: 2.0.0-RC1 If we except the interfaces, the code lacks of javadoc and comments, which make it complicated for new committers to get into it. We need to add those missing javadocs, and comments where it's necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-593) Javadoc documentation for org/apache/mina/filter/reqres
[ https://issues.apache.org/jira/browse/DIRMINA-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Paliwal reassigned DIRMINA-593: -- Assignee: Ashish Paliwal Javadoc documentation for org/apache/mina/filter/reqres - Key: DIRMINA-593 URL: https://issues.apache.org/jira/browse/DIRMINA-593 Project: MINA Issue Type: Improvement Components: Filter, Web Site / Documentation Affects Versions: 2.0.0-M1 Reporter: Julien Vermillard Assignee: Ashish Paliwal Fix For: 2.0.0-RC1 no javadoc nor doc on the request/response filter, it need some examples too -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DIRMINA-593] request/response filter
Can someone throw some light on the usage of Request/Response filter? What it can be used for? Any real life examples, if available, shall be of help. -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [DIRMINA-593] request/response filter
Ashish wrote: Can someone throw some light on the usage of Request/Response filter? What it can be used for? I think I have created the issue because I had no clue about what is was good for ... Will check further ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vysper] Stanzas for a module without namespace
On Mon, Aug 10, 2009 at 9:54 AM, Michael Jakljakl.mich...@gmail.com wrote: Routing via subdomain seems to be the only viable alternative. Only broadcasting to all modules might work too, but doesn't sound as clean. Agreed, this also seems to be what the spec assumes. Reading further into the spec, it turns out the this type of routing is used for all message stanzas, rather than extension namespaces. So, in addition to the component support (using the component protocol), how about we allow for registering modules with a subdomain? For example, adding a XMPPServer.addModule(String subdomain, Module module) method. Then we do a SubdomainHandlerDictionary working similar to the NamespaceHandlerDictionary which takes care of finding the handler. That way, we can have the server respond to different subdomains in an easy way. What do you think? /niklas
[jira] Created: (DIRMINA-736) MdcInjectionFilterTest sometimes fails for SESSION_CLOSED event
MdcInjectionFilterTest sometimes fails for SESSION_CLOSED event --- Key: DIRMINA-736 URL: https://issues.apache.org/jira/browse/DIRMINA-736 Project: MINA Issue Type: Bug Components: Filter Environment: [16:09:14]$ uname -a Linux devws 2.6.18-92.1.22.el5.centos.plus #1 SMP Wed Dec 17 10:50:49 EST 2008 i686 i686 i386 GNU/Linux [vl...@devws ~/tools/mina/svn-20090810] [16:09:19]$ $JAVA_HOME/bin/java -version java version 1.6.0_14 Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) Reporter: james defelice building from svn trunk: mvn -Dwith-LGPL-dependencies clean install mvn -Dwith-LGPL-dependencies site completed succesfully, then the next command failed: mvn -Dwith-LGPL-dependencies package assembly:assembly stack trace from bug report: Test set: org.apache.mina.filter.logging.MdcInjectionFilterTest --- Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 9.42 sec FAILURE! testOnlyRemoteAddress(org.apache.mina.filter.logging.MdcInjectionFilterTest) Time elapsed: 1.03 sec FAILURE! java.lang.AssertionError: MDC[handlerClass] set for [Event SESSION_CLOSED has been fired for session 91] at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertNull(Assert.java:375) at org.apache.mina.filter.logging.MdcInjectionFilterTest.testOnlyRemoteAddress(MdcInjectionFilterTest.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) ... so this test doesn't use handlerClass MDC, but other test cases in this test class do, so maybe there's some garbage lingering somewhere else in the stack that's not being cleaned up between tests? Strange since this test case allocates an entirely new IO stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vysper] Stanzas for a module without namespace
Hi! On Mon, Aug 10, 2009 at 22:15, Niklas Gustavssonnik...@protocol7.com wrote: On Mon, Aug 10, 2009 at 9:54 AM, Michael Jakljakl.mich...@gmail.com wrote: So, in addition to the component support (using the component protocol), how about we allow for registering modules with a subdomain? For example, adding a XMPPServer.addModule(String subdomain, Module module) method. Then we do a SubdomainHandlerDictionary working similar to the NamespaceHandlerDictionary which takes care of finding the handler. That way, we can have the server respond to different subdomains in an easy way. What do you think? That's exactly how I'd do it. If it's no problem that subdomain routing takes precedence over namespace routing this is the way to go IMHO. On a second thought we might want to keep the namespace routing within the subdomain routing. Is there a use-case where we need to route by subdomain first, then by namespace or should the module take care of that? In the pubsub case, we have two namespaces (the general namespace and the owner namespace). In my case it's handled by the same module, but is this always the case? Michael
Re: [Vysper] Stanzas for a module without namespace
On Mon, Aug 10, 2009 at 10:31 PM, Michael Jakljakl.mich...@gmail.com wrote: That's exactly how I'd do it. If it's no problem that subdomain routing takes precedence over namespace routing this is the way to go IMHO. On a second thought we might want to keep the namespace routing within the subdomain routing. Is there a use-case where we need to route by subdomain first, then by namespace or should the module take care of that? In the pubsub case, we have two namespaces (the general namespace and the owner namespace). In my case it's handled by the same module, but is this always the case? I would say that the module should deal with that. So, subdomain routing first. Everything matching the subdomain goes to the handler dictionary. The SubdomainHandlerDictionery.get() will have to do the namespace routing in the case where a module works like the pubsub module (and the MUC module btw). Makes sense? /niklas
Re: [Vysper] Stanzas for a module without namespace
Niklas Gustavsson wrote: On Mon, Aug 10, 2009 at 10:31 PM, Michael Jakljakl.mich...@gmail.com wrote: That's exactly how I'd do it. If it's no problem that subdomain routing takes precedence over namespace routing this is the way to go IMHO. On a second thought we might want to keep the namespace routing within the subdomain routing. Is there a use-case where we need to route by subdomain first, then by namespace or should the module take care of that? In the pubsub case, we have two namespaces (the general namespace and the owner namespace). In my case it's handled by the same module, but is this always the case? I would say that the module should deal with that. So, subdomain routing first. Everything matching the subdomain goes to the handler dictionary. The SubdomainHandlerDictionery.get() will have to do the namespace routing in the case where a module works like the pubsub module (and the MUC module btw). Makes sense? +1, sounds good. Bernd
[DIRMINA-477] Update page about differences between 1.x and 2.x
Folks, Have updated the page based on the comments in the issue. Do we see any more updates in that area or is it fine to close the issue? -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [DIRMINA-593] request/response filter
What it can be used for? I think I have created the issue because I had no clue about what is was good for ... Will check further ... Traced it back to DIRMINA-92 :-) Finally have some clue of what it is. Julien: The issue has one of your examples. Do you think, it will be a good idea to put it in examples? -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
