Re: [FileInstall] Review patch for custom deployers
I'll apply the patch on monday if noone objects. On Mon, Aug 24, 2009 at 10:05, Guillaume Nodet gno...@gmail.com wrote: Some time ago, I've attached a patch for FELIX-922. The patch is quite big, but I'd like to gather feedback about it and apply it if it makes sense, so if some people could have a look at it that would be awesome. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Resolved: (FELIX-1529) The console does not work anymore when connecting to another karaf instance
[ https://issues.apache.org/jira/browse/FELIX-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1529. Resolution: Fixed Fix Version/s: karaf-1.0.0 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?rev=808782view=rev The console does not work anymore when connecting to another karaf instance --- Key: FELIX-1529 URL: https://issues.apache.org/jira/browse/FELIX-1529 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf-1.0.0 Using: admin:create k1 admin:start k1 admin:connect k1 It seems keystrokes are eaten by another thread -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details
[ https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748702#action_12748702 ] Guillaume Nodet commented on FELIX-1221: Wanna write a patch for Karaf then ? I'm not sure to completely follow you here ... Display the alias ID created by Karaf Features when showing service details --- Key: FELIX-1221 URL: https://issues.apache.org/jira/browse/FELIX-1221 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Tim Moloney Priority: Minor Attachments: FELIX-1221-bundles-aliasId.patch Display the alias ID for services configured via Karaf Features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix HttpService improvement...
Looked quickly at cometd and especially cometd-java. It looks to me that this is trivial to include in the http service implementation. Will look into this. On Fri, Aug 28, 2009 at 9:03 AM, Sten Roger Sandvik s...@x3m.com wrote: The new http service is not testet alot. It's only been used in our own projects for now, but I will need to create more unit tests and some integration tests. As for comet support - I have tought of it, but have not come around to do it. I will gladly look at the current comet support to see if it's a trivial ting to include. Yes, it would be great to be included as a committer. I really like the Felix project and are really committed to create the best http service implementation out there :-) BR, Sten Roger On Fri, Aug 28, 2009 at 8:52 AM, Rob Walker r...@ascert.com wrote: Good point - we also have a home grown cometd approach which we use for server push to our GWT application, so something built into the http server would definitely be of interest - R Clement Escoffier wrote: Hi, Just my 2 cents. any plan to support Cometd ? We slightly change the current HTTP Service to support Cometd. I don't see any issue to do the same on Sten's version. (of course, I can send what we quickly did). As a reminder, Cometd is an HTTP based MOM, allowing (after a handshake) a server to notify browser. In Ajax-based interaction, the client (periodically) query the server. With Comet, the server notifies the clients. As you can imagine, this is definitely important for dynamic web application. Regards, Clement On 28.08.2009, at 08:40, Rob Walker wrote: What do we need to do make this happen guys? Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
[jira] Created: (FELIX-1537) File Install should support XML property files
File Install should support XML property files -- Key: FELIX-1537 URL: https://issues.apache.org/jira/browse/FELIX-1537 Project: Felix Issue Type: New Feature Components: File Install Affects Versions: fileinstall-1.2.0 Reporter: Clement Escoffier File Install already supports .cfg file. It would be interristing to also support XML property files, as described in http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix HttpService improvement...
Hi, This would certainly be a very valuable addition, but I don't think this should stop us from continuing. Regards Felix Sten Roger Sandvik schrieb: Looked quickly at cometd and especially cometd-java. It looks to me that this is trivial to include in the http service implementation. Will look into this. On Fri, Aug 28, 2009 at 9:03 AM, Sten Roger Sandvik s...@x3m.com wrote: The new http service is not testet alot. It's only been used in our own projects for now, but I will need to create more unit tests and some integration tests. As for comet support - I have tought of it, but have not come around to do it. I will gladly look at the current comet support to see if it's a trivial ting to include. Yes, it would be great to be included as a committer. I really like the Felix project and are really committed to create the best http service implementation out there :-) BR, Sten Roger On Fri, Aug 28, 2009 at 8:52 AM, Rob Walker r...@ascert.com wrote: Good point - we also have a home grown cometd approach which we use for server push to our GWT application, so something built into the http server would definitely be of interest - R Clement Escoffier wrote: Hi, Just my 2 cents. any plan to support Cometd ? We slightly change the current HTTP Service to support Cometd. I don't see any issue to do the same on Sten's version. (of course, I can send what we quickly did). As a reminder, Cometd is an HTTP based MOM, allowing (after a handshake) a server to notify browser. In Ajax-based interaction, the client (periodically) query the server. With Comet, the server notifies the clients. As you can imagine, this is definitely important for dynamic web application. Regards, Clement On 28.08.2009, at 08:40, Rob Walker wrote: What do we need to do make this happen guys? Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
JIRA and default notification scheme
I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Felix HttpService improvement...
Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: JIRA and default notification scheme
2009/8/28 Guillaume Nodet gno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: JIRA and default notification scheme
I think we need an admin on the whole jira instance to do that. I'm not one on this instance ... 2009/8/28 Stuart McCulloch mccu...@gmail.com: 2009/8/28 Guillaume Nodet gno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-1538) Exporter can load classes from importer
Exporter can load classes from importer --- Key: FELIX-1538 URL: https://issues.apache.org/jira/browse/FELIX-1538 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-2.0.0 Reporter: Thomas Diesler A imports X B imports X Can X load a class from A or B? Can A load a class from B and vice versa? testLoadClass(org.jboss.test.osgi.jbosgi142.OSGI142TestCase) Time elapsed: 1.743 sec FAILURE! java.lang.AssertionError: ClassNotFoundException expected for: jbosgi142-bundleX loads org.jboss.test.osgi.jbosgi142.bundleA.BeanA at org.junit.Assert.fail(Assert.java:92) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.assertBundleLoadClass(OSGI142TestCase.java:105) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.testLoadClass(OSGI142TestCase.java:83) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1538) Exporter can load classes from importer
[ https://issues.apache.org/jira/browse/FELIX-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748788#action_12748788 ] Thomas Diesler commented on FELIX-1538: --- The related jboss issue is: https://jira.jboss.org/jira/browse/JBOSGI-142 Exporter can load classes from importer --- Key: FELIX-1538 URL: https://issues.apache.org/jira/browse/FELIX-1538 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-2.0.0 Reporter: Thomas Diesler A imports X B imports X Can X load a class from A or B? Can A load a class from B and vice versa? testLoadClass(org.jboss.test.osgi.jbosgi142.OSGI142TestCase) Time elapsed: 1.743 sec FAILURE! java.lang.AssertionError: ClassNotFoundException expected for: jbosgi142-bundleX loads org.jboss.test.osgi.jbosgi142.bundleA.BeanA at org.junit.Assert.fail(Assert.java:92) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.assertBundleLoadClass(OSGI142TestCase.java:105) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.testLoadClass(OSGI142TestCase.java:83) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JIRA and default notification scheme
Hi, I could do that. Currently the scheme is defined to _only_ send mail to d...@felix. Over in Sling we have mail to d...@sling, reporter, watchers, and current assignee. I could change this for Felix, too. WDYT ? Regards Felix Guillaume Nodet schrieb: I think we need an admin on the whole jira instance to do that. I'm not one on this instance ... 2009/8/28 Stuart McCulloch mccu...@gmail.com: 2009/8/28 Guillaume Nodet gno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: JIRA and default notification scheme
2009/8/28 Felix Meschberger fmesc...@gmail.com Hi, I could do that. Currently the scheme is defined to _only_ send mail to d...@felix. Over in Sling we have mail to d...@sling, reporter, watchers, and current assignee. I could change this for Felix, too. the Sling setting looks reasonable to me, let's see what others think WDYT ? Regards Felix Guillaume Nodet schrieb: I think we need an admin on the whole jira instance to do that. I'm not one on this instance ... 2009/8/28 Stuart McCulloch mccu...@gmail.com: 2009/8/28 Guillaume Nodet gno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart -- Cheers, Stuart
[jira] Commented: (FELIX-1538) Exporter can load classes from importer
[ https://issues.apache.org/jira/browse/FELIX-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748798#action_12748798 ] Thomas Diesler commented on FELIX-1538: --- Here is the test http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/testsuite/functional/src/test/java/org/jboss/test/osgi/jbosgi142/OSGI142TestCase.java Exporter can load classes from importer --- Key: FELIX-1538 URL: https://issues.apache.org/jira/browse/FELIX-1538 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-2.0.0 Reporter: Thomas Diesler A imports X B imports X Can X load a class from A or B? Can A load a class from B and vice versa? testLoadClass(org.jboss.test.osgi.jbosgi142.OSGI142TestCase) Time elapsed: 1.743 sec FAILURE! java.lang.AssertionError: ClassNotFoundException expected for: jbosgi142-bundleX loads org.jboss.test.osgi.jbosgi142.bundleA.BeanA at org.junit.Assert.fail(Assert.java:92) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.assertBundleLoadClass(OSGI142TestCase.java:105) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.testLoadClass(OSGI142TestCase.java:83) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
dead link: downloads config admin
getting 404 not found... ???
Re: Felix HttpService improvement...
Hi, Here is what we did : http://clement.plop-plop.net/comet/ As you will see, it's quite simple, but has quite well worked. Regards, Clement On 28.08.2009, at 09:26, Sten Roger Sandvik wrote: Looked quickly at cometd and especially cometd-java. It looks to me that this is trivial to include in the http service implementation. Will look into this. On Fri, Aug 28, 2009 at 9:03 AM, Sten Roger Sandvik s...@x3m.com wrote: The new http service is not testet alot. It's only been used in our own projects for now, but I will need to create more unit tests and some integration tests. As for comet support - I have tought of it, but have not come around to do it. I will gladly look at the current comet support to see if it's a trivial ting to include. Yes, it would be great to be included as a committer. I really like the Felix project and are really committed to create the best http service implementation out there :-) BR, Sten Roger On Fri, Aug 28, 2009 at 8:52 AM, Rob Walker r...@ascert.com wrote: Good point - we also have a home grown cometd approach which we use for server push to our GWT application, so something built into the http server would definitely be of interest - R Clement Escoffier wrote: Hi, Just my 2 cents. any plan to support Cometd ? We slightly change the current HTTP Service to support Cometd. I don't see any issue to do the same on Sten's version. (of course, I can send what we quickly did). As a reminder, Cometd is an HTTP based MOM, allowing (after a handshake) a server to notify browser. In Ajax-based interaction, the client (periodically) query the server. With Comet, the server notifies the clients. As you can imagine, this is definitely important for dynamic web application. Regards, Clement On 28.08.2009, at 08:40, Rob Walker wrote: What do we need to do make this happen guys? Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
[jira] Commented: (FELIX-33) Implement system bundle update
[ https://issues.apache.org/jira/browse/FELIX-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748868#action_12748868 ] Richard S. Hall commented on FELIX-33: -- Also made it so the framework is restarted if an extension bundle is refreshed using update(). Implement system bundle update -- Key: FELIX-33 URL: https://issues.apache.org/jira/browse/FELIX-33 Project: Felix Issue Type: New Feature Components: Framework, Specification compliance Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-2.0.0 This issue is described in section 4.5 of the OSGi R4 specification. When the system bundle is updated, the framework is supposed to shutdown and restart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Felix Configuration Admin Service 1.2.2
+1, Regards, Clement On 27.08.2009, at 22:37, Felix Meschberger wrote: Hi, Testing the Configuration Admin 1.2.0 revealed a bug in the permission checking code causing the bundle to fail the OSGi TCK tests. For this reason, I come up with yet another release... We solved 1 issues in this release: https://issues.apache.org/jira/secure/BrowseVersion.jspa?versionId=12314169 There are no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/felix-staging-038/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 038 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks and Regards Felix
[jira] Closed: (FELIX-1122) Extension bundles are not being removed from the bundle list when uninstalled
[ https://issues.apache.org/jira/browse/FELIX-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1122. -- Resolution: Fixed Assignee: Richard S. Hall Extensions bundles are now handle in a similar fashion to other bundles, except they are not stopped during uninstall, they are stopped during framework shutdown instead. Extension bundles are not being removed from the bundle list when uninstalled - Key: FELIX-1122 URL: https://issues.apache.org/jira/browse/FELIX-1122 Project: Felix Issue Type: Bug Components: Framework, Specification compliance Affects Versions: felix-1.6.1 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-2.0.0 We need to remove the extension bundle from the installed bundle data structures in Felix.uninstallBundle(). I think the code in there can be merged a little better to bring handling of extension bundles and normal bundles into closer alignment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FELIX-1537) File Install should support XML property files
Hi, This should not be really an issue, as this feature can be done in another 'Deployer' (which requires Java 5). This deployer does not impact the core of file install. Regards, Clement On 28.08.2009, at 16:29, Karl Pauls (JIRA) wrote: [ https://issues.apache.org/jira/browse/FELIX-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748830 #action_12748830 ] Karl Pauls commented on FELIX-1537: --- Well, we could try to implement it in a way where it is only available if we are on java5 or greater, no? File Install should support XML property files -- Key: FELIX-1537 URL: https://issues.apache.org/jira/browse/FELIX-1537 Project: Felix Issue Type: New Feature Components: File Install Affects Versions: fileinstall-1.2.0 Reporter: Clement Escoffier File Install already supports .cfg file. It would be interristing to also support XML property files, as described in http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1537) File Install should support XML property files
[ https://issues.apache.org/jira/browse/FELIX-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748881#action_12748881 ] Clement Escoffier commented on FELIX-1537: -- Hi, This should not be really an issue, as this feature can be done in another 'Deployer' (which requires Java 5). This deployer does not impact the core of file install. Regards, Clement File Install should support XML property files -- Key: FELIX-1537 URL: https://issues.apache.org/jira/browse/FELIX-1537 Project: Felix Issue Type: New Feature Components: File Install Affects Versions: fileinstall-1.2.0 Reporter: Clement Escoffier File Install already supports .cfg file. It would be interristing to also support XML property files, as described in http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FELIX-1537) File Install should support XML property files
Great! - richard On 8/28/09 12:24, Clement Escoffier wrote: Hi, This should not be really an issue, as this feature can be done in another 'Deployer' (which requires Java 5). This deployer does not impact the core of file install. Regards, Clement On 28.08.2009, at 16:29, Karl Pauls (JIRA) wrote: [ https://issues.apache.org/jira/browse/FELIX-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748830#action_12748830 ] Karl Pauls commented on FELIX-1537: --- Well, we could try to implement it in a way where it is only available if we are on java5 or greater, no? File Install should support XML property files -- Key: FELIX-1537 URL: https://issues.apache.org/jira/browse/FELIX-1537 Project: Felix Issue Type: New Feature Components: File Install Affects Versions: fileinstall-1.2.0 Reporter: Clement Escoffier File Install already supports .cfg file. It would be interristing to also support XML property files, as described in http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1538) Exporter can load classes from importer
[ https://issues.apache.org/jira/browse/FELIX-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated FELIX-1538: -- Attachment: jbosgi142-bundleX.jar jbosgi142-bundleB.jar jbosgi142-bundleA.jar Attached are the bundles that I use Exporter can load classes from importer --- Key: FELIX-1538 URL: https://issues.apache.org/jira/browse/FELIX-1538 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-2.0.0 Reporter: Thomas Diesler Attachments: jbosgi142-bundleA.jar, jbosgi142-bundleB.jar, jbosgi142-bundleX.jar A imports X B imports X Can X load a class from A or B? Can A load a class from B and vice versa? testLoadClass(org.jboss.test.osgi.jbosgi142.OSGI142TestCase) Time elapsed: 1.743 sec FAILURE! java.lang.AssertionError: ClassNotFoundException expected for: jbosgi142-bundleX loads org.jboss.test.osgi.jbosgi142.bundleA.BeanA at org.junit.Assert.fail(Assert.java:92) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.assertBundleLoadClass(OSGI142TestCase.java:105) at org.jboss.test.osgi.jbosgi142.OSGI142TestCase.testLoadClass(OSGI142TestCase.java:83) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix HttpService improvement...
Will look at that and see how to include it. It's not going in right now, since my first priority is to get it up in felix svn. BR, Sten Roger On Fri, Aug 28, 2009 at 5:46 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, Here is what we did : http://clement.plop-plop.net/comet/ As you will see, it's quite simple, but has quite well worked. Regards, Clement On 28.08.2009, at 09:26, Sten Roger Sandvik wrote: Looked quickly at cometd and especially cometd-java. It looks to me that this is trivial to include in the http service implementation. Will look into this. On Fri, Aug 28, 2009 at 9:03 AM, Sten Roger Sandvik s...@x3m.com wrote: The new http service is not testet alot. It's only been used in our own projects for now, but I will need to create more unit tests and some integration tests. As for comet support - I have tought of it, but have not come around to do it. I will gladly look at the current comet support to see if it's a trivial ting to include. Yes, it would be great to be included as a committer. I really like the Felix project and are really committed to create the best http service implementation out there :-) BR, Sten Roger On Fri, Aug 28, 2009 at 8:52 AM, Rob Walker r...@ascert.com wrote: Good point - we also have a home grown cometd approach which we use for server push to our GWT application, so something built into the http server would definitely be of interest - R Clement Escoffier wrote: Hi, Just my 2 cents. any plan to support Cometd ? We slightly change the current HTTP Service to support Cometd. I don't see any issue to do the same on Sten's version. (of course, I can send what we quickly did). As a reminder, Cometd is an HTTP based MOM, allowing (after a handshake) a server to notify browser. In Ajax-based interaction, the client (periodically) query the server. With Comet, the server notifies the clients. As you can imagine, this is definitely important for dynamic web application. Regards, Clement On 28.08.2009, at 08:40, Rob Walker wrote: What do we need to do make this happen guys? Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
Re: [VOTE] Release Apache Felix Configuration Admin Service 1.2.2
2009/8/28 Felix Meschberger fmesc...@gmail.com Hi, Testing the Configuration Admin 1.2.0 revealed a bug in the permission checking code causing the bundle to fail the OSGi TCK tests. For this reason, I come up with yet another release... We solved 1 issues in this release: https://issues.apache.org/jira/secure/BrowseVersion.jspa?versionId=12314169 There are no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/felix-staging-038/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 038 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks and Regards Felix +1 (remember to update the version on the downloads page) -- Cheers, Stuart
Re: Felix HttpService improvement...
On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hall he...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandvik s...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hall he...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
On 8/28/09 13:29, Sten Roger Sandvik wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hallhe...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? Yes, on the private mailing list. - richard * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
On 8/28/09 13:48, Sten Roger Sandvik wrote: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. That's fine. - richard On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandviks...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hallhe...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
RE: dead link: downloads config admin
Hi, Thanks.. I ended up cheating by just changing the link to 1.2.0 and it worked... Not to hijack this thread, but have an unrelated question... I've been away a few months... I downloaded felix 1.8... My System.out.println()'s are no longer apparent / presented on the console... What am I doing wrong? Much appreciated... Craig Phillips From: Felix Meschberger [mailto:fmesc...@gmail.com] Sent: Fri 8/28/2009 9:23 AM To: dev@felix.apache.org Subject: Re: dead link: downloads config admin Hi Craig, Craig Phillips schrieb: getting 404 not found... Sorry about that. Point is, that Apache seems to have some issues with infrastructure at the moment (and yes, there are people working on it to fix it) A secondary issue, is that our site is not up-to-date and the download page still contains the the old version linked. If you just want to grab the bundle, you might want to go to your local mirror (displayed on the Felix download page) go to the felix folder and grab the org.apache.felix.configadmin-1.2.0.jar file. Sorry, for the inconvenience. Regards Felix
Re: dead link: downloads config admin
On 8/28/09 14:55, Craig Phillips wrote: Hi, Thanks.. I ended up cheating by just changing the link to 1.2.0 and it worked... Not to hijack this thread, but have an unrelated question... I've been away a few months... I downloaded felix 1.8... My System.out.println()'s are no longer apparent / presented on the console... What am I doing wrong? Good question. We don't do anything to subvert stdout. - richard Much appreciated... Craig Phillips From: Felix Meschberger [mailto:fmesc...@gmail.com] Sent: Fri 8/28/2009 9:23 AM To: dev@felix.apache.org Subject: Re: dead link: downloads config admin Hi Craig, Craig Phillips schrieb: getting 404 not found... Sorry about that. Point is, that Apache seems to have some issues with infrastructure at the moment (and yes, there are people working on it to fix it) A secondary issue, is that our site is not up-to-date and the download page still contains the the old version linked. If you just want to grab the bundle, you might want to go to your local mirror (displayed on the Felix download page) go to the felix folder and grab the org.apache.felix.configadmin-1.2.0.jar file. Sorry, for the inconvenience. Regards Felix
Re: JIRA and default notification scheme
Done. Notifications for all events now go to d...@felix, all watchers, the reporter and the current assignee. Regards Felix Richard S. Hall schrieb: Fine by me. - richard On 8/28/09 9:08, Guillaume Nodet wrote: Sounds good. That's what I've been used to usually. On Fri, Aug 28, 2009 at 13:48, Felix Meschbergerfmesc...@gmail.com wrote: Hi, I could do that. Currently the scheme is defined to _only_ send mail to d...@felix. Over in Sling we have mail to d...@sling, reporter, watchers, and current assignee. I could change this for Felix, too. WDYT ? Regards Felix Guillaume Nodet schrieb: I think we need an admin on the whole jira instance to do that. I'm not one on this instance ... 2009/8/28 Stuart McCullochmccu...@gmail.com: 2009/8/28 Guillaume Nodetgno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: JIRA and default notification scheme
Yeah, I did notice that I now get some duplicates since I tend to be the reporter on a lot of them... :-( - richard On 8/28/09 16:11, Felix Meschberger wrote: Done. Notifications for all events now go to d...@felix, all watchers, the reporter and the current assignee. Regards Felix Richard S. Hall schrieb: Fine by me. - richard On 8/28/09 9:08, Guillaume Nodet wrote: Sounds good. That's what I've been used to usually. On Fri, Aug 28, 2009 at 13:48, Felix Meschbergerfmesc...@gmail.com wrote: Hi, I could do that. Currently the scheme is defined to _only_ send mail to d...@felix. Over in Sling we have mail to d...@sling, reporter, watchers, and current assignee. I could change this for Felix, too. WDYT ? Regards Felix Guillaume Nodet schrieb: I think we need an admin on the whole jira instance to do that. I'm not one on this instance ... 2009/8/28 Stuart McCullochmccu...@gmail.com: 2009/8/28 Guillaume Nodetgno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: [VOTE] Release Apache Felix Configuration Admin Service 1.2.2
Hi, Stuart McCulloch schrieb: (remember to update the version on the downloads page) I've done it but it is not synced to the site -- and due to today's issues, I could not (yet) look into it. Regards Felix
Re: Felix HttpService improvement...
Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandvik s...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hall he...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
[jira] Commented: (FELIX-1456) Contribution: Extended and improved HttpService
[ https://issues.apache.org/jira/browse/FELIX-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748971#action_12748971 ] Felix Meschberger commented on FELIX-1456: -- Thanks for submitting the patch. I have quickly checked it: * MD5 checksum matches * source files have license headers notes: * pom files are missing the license headers * the runner folder contains a jar file and some batch files we can probably fix the pom license header issue on import and decide upon handling the runner folder while importing into SVN Contribution: Extended and improved HttpService --- Key: FELIX-1456 URL: https://issues.apache.org/jira/browse/FELIX-1456 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Sten Roger Sandvik Attachments: http-service.tar.gz, http-service.tar.gz.md5 I have created an improved version of the HttpService. A similar version has been deployed at my company (Enonic) for some time. Instead of hosting this code ourself, we (or I) tought it would be better to contribute this to Apache. So, the feaures: * Extended API to support servlet filters. * Backward compatible with standard HttpService (without Filter support). * A bridged implementation. Using HttpService from a standard WAR file inside your favourite container. Same as Equinox Servlet Bridge except with Filter support. * A jetty implementation (very influenced by the existing Felix implementation). * Seperate dispatcher so that we can have different transports. Where's can I try it? Since I do not have committer rights (I would very much like so :-)) and I really to use Jira as a source and patch repository the code is hosted at my own place for now. This is so that you can try it out and tell me what you think. Go to http://github.com/srs/felix-contrib/tree/master for sources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JIRA and default notification scheme
Hi, Richard S. Hall schrieb: Yeah, I did notice that I now get some duplicates since I tend to be the reporter on a lot of them... :-( I generally do not get such duplicates for my edits on bugs I report or which are assigned to me. Probably this is related to the fact that I have unchecked the Email me when I make changes checkbox in my user preferences. Regards Felix - richard On 8/28/09 16:11, Felix Meschberger wrote: Done. Notifications for all events now go to d...@felix, all watchers, the reporter and the current assignee. Regards Felix Richard S. Hall schrieb: Fine by me. - richard On 8/28/09 9:08, Guillaume Nodet wrote: Sounds good. That's what I've been used to usually. On Fri, Aug 28, 2009 at 13:48, Felix Meschbergerfmesc...@gmail.com wrote: Hi, I could do that. Currently the scheme is defined to _only_ send mail to d...@felix. Over in Sling we have mail to d...@sling, reporter, watchers, and current assignee. I could change this for Felix, too. WDYT ? Regards Felix Guillaume Nodet schrieb: I think we need an admin on the whole jira instance to do that. I'm not one on this instance ... 2009/8/28 Stuart McCullochmccu...@gmail.com: 2009/8/28 Guillaume Nodetgno...@gmail.com I'm quite puzzled by the default notification schema for FELIX jira project. I'm quite used that the user that created an issue is automatically notified of any change to this issue. Currently, this is not the case, which mean that if a user create an issue and does not specifically watch it, he won't receive any notifications. Is that a desired behavior or should we change that ? hmm, I'd also expect that whoever creates an issue would receive notifications from it the Felix JIRA admin page just shows Notification Scheme: Felix notifications, any idea where this scheme is configured? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: Felix HttpService improvement...
On 8/28/09 16:30, Felix Meschberger wrote: Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Which will require Sten to fill out a Software Grant, which may need to come from his employer if it is actually the employer who is contributing the code. - richard Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandviks...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hallhe...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
On 8/28/09 16:43, Richard S. Hall wrote: On 8/28/09 16:30, Felix Meschberger wrote: Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Which will require Sten to fill out a Software Grant, which may need to come from his employer if it is actually the employer who is contributing the code. And of course, we still have to vote and accept it before any of this is truly necessary... - richard - richard Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandviks...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hallhe...@ungoverned.orgwrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
[jira] Commented: (FELIX-1456) Contribution: Extended and improved HttpService
[ https://issues.apache.org/jira/browse/FELIX-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748991#action_12748991 ] Sten Roger Sandvik commented on FELIX-1456: --- Ah, forgot the license in the pom. And the runner was acually not supposed to be there. I can fix it and upload new attachements. Will do first thing in the morning. Contribution: Extended and improved HttpService --- Key: FELIX-1456 URL: https://issues.apache.org/jira/browse/FELIX-1456 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Sten Roger Sandvik Attachments: http-service.tar.gz, http-service.tar.gz.md5 I have created an improved version of the HttpService. A similar version has been deployed at my company (Enonic) for some time. Instead of hosting this code ourself, we (or I) tought it would be better to contribute this to Apache. So, the feaures: * Extended API to support servlet filters. * Backward compatible with standard HttpService (without Filter support). * A bridged implementation. Using HttpService from a standard WAR file inside your favourite container. Same as Equinox Servlet Bridge except with Filter support. * A jetty implementation (very influenced by the existing Felix implementation). * Seperate dispatcher so that we can have different transports. Where's can I try it? Since I do not have committer rights (I would very much like so :-)) and I really to use Jira as a source and patch repository the code is hosted at my own place for now. This is so that you can try it out and tell me what you think. Go to http://github.com/srs/felix-contrib/tree/master for sources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix HttpService improvement...
On Fri, Aug 28, 2009 at 10:30 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) Yes, just omit the runner folder. That was a mistake. Was only using that to make quick tests. As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Yes, but the email is wrong. It's s...@x3m.com. And the name Sten Roger Sandvik :-) Do I need another one? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandvik s...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hall he...@ungoverned.org wrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
On Fri, Aug 28, 2009 at 10:43 PM, Richard S. Hall he...@ungoverned.orgwrote: On 8/28/09 16:30, Felix Meschberger wrote: Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Which will require Sten to fill out a Software Grant, which may need to come from his employer if it is actually the employer who is contributing the code. No, it does not need to be from my employer. Been coding this in my spare time. It has been used at Enonic (my current workplace) in form of some binaries. So a grant from Enonic is not neccessary. But will be happy to provide one if you really need it. - richard Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandviks...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hallhe...@ungoverned.org wrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
Hi, Sten Roger Sandvik schrieb: On Fri, Aug 28, 2009 at 10:43 PM, Richard S. Hall he...@ungoverned.orgwrote: On 8/28/09 16:30, Felix Meschberger wrote: Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Which will require Sten to fill out a Software Grant, which may need to come from his employer if it is actually the employer who is contributing the code. No, it does not need to be from my employer. Been coding this in my spare time. It has been used at Enonic (my current workplace) in form of some binaries. So a grant from Enonic is not neccessary. But will be happy to provide one if you really need it. A Corporate CLA is only required if your employer pays your for working on Apache projects. But what we would probably need to be good for IP clearance is a software grant [1]. You may fax it to the same number as the ICLA. Thanks. Regards Felix [1] http://www.apache.org/licenses/software-grant.txt - richard Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandviks...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hallhe...@ungoverned.org wrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
Re: Felix HttpService improvement...
Hi Sten Sten Roger Sandvik schrieb: On Fri, Aug 28, 2009 at 10:30 PM, Felix Meschberger fmesc...@gmail.comwrote: As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Yes, but the email is wrong. It's s...@x3m.com. And the name Sten Roger Sandvik :-) Do I need another one? Thanks for the confirmation. I just crosschecked: It looks like there are two bugs ;-) The wrong spelling on your last name is my fault: It is correct in the registration. The wrong mail address stems from an incorrect transmission from your ICLA fax submission (the fax clearly reads s...@x3m.com. I will care to have this fixed. Regards Felix Thanks again for your submission, I will now start the process of getting this into Felix SVN. Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandvik s...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hall he...@ungoverned.org wrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
[jira] Commented: (FELIX-1456) Contribution: Extended and improved HttpService
[ https://issues.apache.org/jira/browse/FELIX-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749003#action_12749003 ] Felix Meschberger commented on FELIX-1456: -- Excellent. I will start the vote on accepting your submission on monday (starting on friday tends to be problematic), Contribution: Extended and improved HttpService --- Key: FELIX-1456 URL: https://issues.apache.org/jira/browse/FELIX-1456 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Sten Roger Sandvik Attachments: http-service.tar.gz, http-service.tar.gz.md5 I have created an improved version of the HttpService. A similar version has been deployed at my company (Enonic) for some time. Instead of hosting this code ourself, we (or I) tought it would be better to contribute this to Apache. So, the feaures: * Extended API to support servlet filters. * Backward compatible with standard HttpService (without Filter support). * A bridged implementation. Using HttpService from a standard WAR file inside your favourite container. Same as Equinox Servlet Bridge except with Filter support. * A jetty implementation (very influenced by the existing Felix implementation). * Seperate dispatcher so that we can have different transports. Where's can I try it? Since I do not have committer rights (I would very much like so :-)) and I really to use Jira as a source and patch repository the code is hosted at my own place for now. This is so that you can try it out and tell me what you think. Go to http://github.com/srs/felix-contrib/tree/master for sources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Felix HttpService improvement...
Yes. Will fill it out on monday. On Sat, Aug 29, 2009 at 12:31 AM, Felix Meschberger fmesc...@gmail.comwrote: Hi Sten, Sten Roger Sandvik schrieb: Ah, ok. Actually my employer is paying for my involvement in projects, but not the work done on this particular piece. Maybe I need to fax in a Corporate CLA then? Hmm, ok. Maybe it would be better then -- it certainly does not hurt. Regards Felix On Fri, Aug 28, 2009 at 11:56 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Sten Roger Sandvik schrieb: On Fri, Aug 28, 2009 at 10:43 PM, Richard S. Hall he...@ungoverned.org wrote: On 8/28/09 16:30, Felix Meschberger wrote: Hi Sten, Looks bascially good (files as appropriate have the license headers, MD5 checksum matches). Just two remarks: * The pom.xml should also have the license headers (this can probably be fixed when we import into SVN) * there is a runner folder containing scripts and the pax runner library. This should probably not be included, right ? (again, I think we can start the process and just omit this directory when importing into SVN) As part of the IP-process we also need an ICLA of you, Sten, on file. I see there is one for Sten Roger Sanvik with email s...@xbm.com. Am I correct to assume, that this is your ICLA ? Thanks again for your submission, I will now start the process of getting this into Felix SVN. Which will require Sten to fill out a Software Grant, which may need to come from his employer if it is actually the employer who is contributing the code. No, it does not need to be from my employer. Been coding this in my spare time. It has been used at Enonic (my current workplace) in form of some binaries. So a grant from Enonic is not neccessary. But will be happy to provide one if you really need it. A Corporate CLA is only required if your employer pays your for working on Apache projects. But what we would probably need to be good for IP clearance is a software grant [1]. You may fax it to the same number as the ICLA. Thanks. Regards Felix [1] http://www.apache.org/licenses/software-grant.txt - richard Regards Felix Sten Roger Sandvik schrieb: Attached the source in the jira task ( https://issues.apache.org/jira/browse/FELIX-1456). Not sure on what format that the attachement should be, but created a tar.gz file. Attached a md5 checksum for the package. On Fri, Aug 28, 2009 at 7:29 PM, Sten Roger Sandviks...@x3m.com wrote: On Fri, Aug 28, 2009 at 4:05 PM, Richard S. Hall he...@ungoverned.org wrote: On 8/28/09 4:36, Felix Meschberger wrote: Hi, Rob Walker schrieb: What do we need to do make this happen guys? The next steps are IIRC the following: * Sten packages the source and attaches the package to the issue and publishes a package checksum. I will add to this, removes any existing header/copyright notices from the files and adds the standard Apache header (see any Felix Java file). Package renaming is not necessary at this point. Have added apache (2.0) on top of all files. Will now create a tarball and add it to the JIRA task. I'm also interested in getting committer rights so that I can still maintain the code. Will that be handled in a seperate vote? * We vote on accepting this submission * We do the IP-clearance (filling out a form, sending a mail to incubator@ and wait for 72h) * Add the code into the SVN I think, we also need someone from the PMC to drive this process. Any volunteers (I could do it) ? I am happy to have you do it. :-) Of course, I can help if needed. - richard Regards Felix Sten - sounds like you've done a great job, kudos. Felix/Marcel - sounds like you guys are happy with the approach and code From our side, we can certainly run some real world compatibility tests - which isn't to say in fact that Sten's new service would be wrong and the current one right, just whether thenew version breaks anything present in the exisiting service. If it does, I'm sure it'll either be fixable, or something that's actually not correct in the current service - so not a major issue. It'll be useful though to be able to advise other Felix guys of anything that might differ and need application changes. I'm happy to make time to look at this next week. After that - do we just call a vote? I'm guessing Sten, we also need to propose you as a committter for maintenance? Great progress though - the current Http service has served us pretty well, but it's always been on the list to have cleaner and fuller solution -- Rob
