Re: Missing ASL header
Hi Nicolas, Ok no response on this, but I've decided to update the file in any case. Richard H pointed me at the $felix-svn/framework/src/main/resources/default.properties file that includes basically the same information as jvm-packages.properties. This includes a version attribute which I think will be useful later, so I've scrapped the previous contents of jvm-packages.properties and gone with this new format. You should find this file (with associated ASL header) here: http://svn.apache.org/repos/asf/felix/trunk/sigil/common/core/profiles/jvm-packages.properties Out of interest I believe bushel and sigil are providing similar capabilities - sigil has a mapping of OSGi meta data into an ivy resolution - however the way we go about it looks quite different to what bushel (does/proposes?). We perform import package resolution using an OSGi resolver outside of ivy and then synthesis ivy modules at runtime, I believe bushel is intending on pushing the meta information into ivy.xml files and then use the standard ivy resolver. Not saying either approach is right/wrong I think it'd be great if there is any useful collaborations we can build once you're setup on apache - let me know? Regards, Dave On Mon, Nov 29, 2010 at 4:19 PM, David Savage wrote: > Hi Nicolas, > > The commit you found replaces the profile files from Eclipse with a > new file which I generated independently. My understanding is that > given this file contains information that is public knowledge to the > Java community, is of a different format and uses different file > access semantics this constitutes it's own IP. As such I'm happy to > apply the ASL header on this basis. If that is acceptable then I will > push an update with this clarification, PM's please advise? > > Regards, > > Dave > > 2010/11/29 Nicolas Lalevée : >> Hi, >> >> I was working on the import of Bushel into Ivy [1], and there were some >> files under the EPL which I had to remove from the import. These files were >> defining the packages which should be part of the bootstrap classpath >> depending on the execution environment. >> >> I then thought I would find such similar files in the source of Felix but >> ASL friendly. I have found them: [2]. >> >> But the ASL header is missing. Then I started to wonder if this file was a >> real ASF one, and I searched svn and I have found a commit that makes me >> doubt [3]. >> >> Considering the IP contained is these files, I think that the new file is >> safe to be an ASF one. So could you add the ASL header so there won't be any >> doubt ? >> >> cheers, >> Nicolas >> >> [1] http://www.mail-archive.com/d...@ant.apache.org/msg42079.html >> [2] >> http://svn.apache.org/repos/asf/felix/trunk/sigil/common/core/profiles/jvm-packages.properties >> [3] http://svn.apache.org/viewvc?view=revision&revision=983901 >> >> >
Re: Missing ASL header
Hi David, > Ok no response on this, but I've decided to update the file in any > case. Richard H pointed me at the > $felix-svn/framework/src/main/resources/default.properties file that > includes basically the same information as jvm-packages.properties. > This includes a version attribute which I think will be useful later, > so I've scrapped the previous contents of jvm-packages.properties and > gone with this new format. > > You should find this file (with associated ASL header) here: > > http://svn.apache.org/repos/asf/felix/trunk/sigil/common/core/profiles/jvm-packages.properties finally I used a modified version of jvm-packages.properties [1] because I don't have a "property expander". Or maybe there is in Ivy but I wanted to quickly fix the unit tests. I'll probably review this later to use the new format. > > Out of interest I believe bushel and sigil are providing similar > capabilities - sigil has a mapping of OSGi meta data into an ivy > resolution - however the way we go about it looks quite different to > what bushel (does/proposes?). We perform import package resolution > using an OSGi resolver outside of ivy and then synthesis ivy modules > at runtime, I believe bushel is intending on pushing the meta > information into ivy.xml files and then use the standard ivy resolver. I think you have clearly summarized the difference here :) > Not saying either approach is right/wrong I think it'd be great if > there is any useful collaborations we can build once you're setup on > apache - let me know? The code has been imported. I am writing some doc right now. I'll try to probably write something about the difference with sigil. Hopefully I'll write something fair ;) I'll keep you posted if I write anything about Sigil. I'm not sure how we can collaborate and share some code, but I would be happy to do so. I'll keep subscribed to felix-dev. Nicolas [1] http://svn.apache.org/repos/asf/ant/ivy/core/trunk/src/java/org/apache/ivy/osgi/core/jvm-packages.properties > > Regards, > > Dave > > On Mon, Nov 29, 2010 at 4:19 PM, David Savage > wrote: >> Hi Nicolas, >> >> The commit you found replaces the profile files from Eclipse with a >> new file which I generated independently. My understanding is that >> given this file contains information that is public knowledge to the >> Java community, is of a different format and uses different file >> access semantics this constitutes it's own IP. As such I'm happy to >> apply the ASL header on this basis. If that is acceptable then I will >> push an update with this clarification, PM's please advise? >> >> Regards, >> >> Dave >> >> 2010/11/29 Nicolas Lalevée : >>> Hi, >>> >>> I was working on the import of Bushel into Ivy [1], and there were some >>> files under the EPL which I had to remove from the import. These files were >>> defining the packages which should be part of the bootstrap classpath >>> depending on the execution environment. >>> >>> I then thought I would find such similar files in the source of Felix but >>> ASL friendly. I have found them: [2]. >>> >>> But the ASL header is missing. Then I started to wonder if this file was a >>> real ASF one, and I searched svn and I have found a commit that makes me >>> doubt [3]. >>> >>> Considering the IP contained is these files, I think that the new file is >>> safe to be an ASF one. So could you add the ASL header so there won't be >>> any doubt ? >>> >>> cheers, >>> Nicolas >>> >>> [1] http://www.mail-archive.com/d...@ant.apache.org/msg42079.html >>> [2] >>> http://svn.apache.org/repos/asf/felix/trunk/sigil/common/core/profiles/jvm-packages.properties >>> [3] http://svn.apache.org/viewvc?view=revision&revision=983901 >>> >>> >>
Re: [VOTE] Apache Felix iPOJO Core 1.6.8 release
+1 regards, Karl On Tue, Nov 30, 2010 at 9:38 PM, Richard S. Hall wrote: > +1 > > -> richard > > On 11/29/10 11:59, Clement Escoffier wrote: >> >> I would like to call a vote for iPOJO Core 1.6.8. >> >> We have resolved a couple of issues in this release: >> >> ** Improvement >> >> * [FELIX-2688] - iPojo "requires.filters" - Array object instead of >> Dictionary object >> >> * [FELIX-2705] - Provide a way to extend the logger strategy >> >> >> >> ** Bug >> >> * [FELIX-2685] - Wrong Element name when XML namespace contains ':' >> >> * [FELIX-2694] - Instance state not recomputed after reconfiguration when >> the instance is stopped >> >> Staging repositories: >> https://repository.apache.org/content/repositories/orgapachefelix-028/ >> >> 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 028 /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> >> Regards, >> >> Clement >> >> >> > -- Karl Pauls karlpa...@gmail.com
[jira] Created: (FELIX-2714) Registered servlet throws java.net.ConnectException or returns 404 after updating the portnr using Config Admin
Registered servlet throws java.net.ConnectException or returns 404 after updating the portnr using Config Admin --- Key: FELIX-2714 URL: https://issues.apache.org/jira/browse/FELIX-2714 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Ivo Ladage-van Doorn When the "org.osgi.service.http.port" property is updated using Config Admin, without effectively changing it (so setting it to 8080 while the default is also 8080), it seems that subsequent servlet registrations fail. A HTTP GET to this servlet either results in a java.net.ConnectException: Connection refused: connect or it returns a 404. Changing it to any other port number results in exactly the same error. Attached is a bundle that reproduces the issue, depending on a HttpService and ConfigurationAdmin implementation. The issue can be reproduced by using the Felix httpservice and Felix config admin deployed on a Felix framework. Summarized this is the use case: - Start HttpService and wait for it to become available (runs on 8080 by default) - Update the "org.osgi.service.http.port" to 8080 using Config Admin (so effectively nothing is changed) - Register a servlet - Open a URL connection to this servlet Now the very first time, this error appears in the console: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:525) at java.net.Socket.connect(Socket.java:475) at sun.net.NetworkClient.doConnect(NetworkClient.java:163) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) at sun.net.www.http.HttpClient.(HttpClient.java:233) at sun.net.www.http.HttpClient.New(HttpClient.java:306) at sun.net.www.http.HttpClient.New(HttpClient.java:323) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726) at org.amdatu.test.PortSwitchTest.checkURL(PortSwitchTest.java:86) at org.amdatu.test.PortSwitchTest.test(PortSwitchTest.java:50) at org.amdatu.test.Activator.addingService(Activator.java:30) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3721) at org.apache.felix.framework.Felix.access$000(Felix.java:80) at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:717) at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107) at org.apache.felix.framework.Felix.registerService(Felix.java:2842) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251) at org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:64) at org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:41) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at
[jira] Updated: (FELIX-2714) Registered servlet throws java.net.ConnectException or returns 404 after updating the portnr using Config Admin
[ https://issues.apache.org/jira/browse/FELIX-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivo Ladage-van Doorn updated FELIX-2714: Attachment: portswitchtest.zip Attached the test bundle reproducing the issue > Registered servlet throws java.net.ConnectException or returns 404 after > updating the portnr using Config Admin > --- > > Key: FELIX-2714 > URL: https://issues.apache.org/jira/browse/FELIX-2714 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.0.4 >Reporter: Ivo Ladage-van Doorn > Attachments: portswitchtest.zip > > > When the "org.osgi.service.http.port" property is updated using Config Admin, > without effectively changing it (so setting it to 8080 while the default is > also 8080), it seems that subsequent servlet registrations fail. A HTTP GET > to this servlet either results in a java.net.ConnectException: Connection > refused: connect or it returns a 404. Changing it to any other port number > results in exactly the same error. > Attached is a bundle that reproduces the issue, depending on a HttpService > and ConfigurationAdmin implementation. The issue can be reproduced by using > the Felix httpservice and Felix config admin deployed on a Felix framework. > Summarized this is the use case: > - Start HttpService and wait for it to become available (runs on 8080 by > default) > - Update the "org.osgi.service.http.port" to 8080 using Config Admin (so > effectively nothing is changed) > - Register a servlet > - Open a URL connection to this servlet > Now the very first time, this error appears in the console: > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:525) > at java.net.Socket.connect(Socket.java:475) > at sun.net.NetworkClient.doConnect(NetworkClient.java:163) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) > at sun.net.www.http.HttpClient.(HttpClient.java:233) > at sun.net.www.http.HttpClient.New(HttpClient.java:306) > at sun.net.www.http.HttpClient.New(HttpClient.java:323) > at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860) > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801) > at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726) > at org.amdatu.test.PortSwitchTest.checkURL(PortSwitchTest.java:86) > at org.amdatu.test.PortSwitchTest.test(PortSwitchTest.java:50) > at org.amdatu.test.Activator.addingService(Activator.java:30) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3721) > at org.apache.felix.framework.Felix.access$000(Felix.java:80) > at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:717) > at > org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107) > at org.apache.felix.framework.Felix.registerService(Felix.java:2842) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251) > at > org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:64) > at > org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:41) > at > org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) > at > org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) > at > org.mortbay
[jira] Resolved: (FELIX-2468) [gogo] CharSequence types are converted to String
[ https://issues.apache.org/jira/browse/FELIX-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2468. --- Resolution: Cannot Reproduce works fine in release gogo-0.6.1 > [gogo] CharSequence types are converted to String > - > > Key: FELIX-2468 > URL: https://issues.apache.org/jira/browse/FELIX-2468 > Project: Felix > Issue Type: Bug > Components: Gogo Runtime >Affects Versions: gogo-0.6.0 >Reporter: Derek Baum >Assignee: Derek Baum >Priority: Minor > Fix For: gogo-0.8.0 > > > gogo now allows creation of a StringBuilder, but when it is accessed it is > converted to String > g! b = new StringBuilder > g! $b append > gogo: IllegalArgumentException: Cannot coerce append() to any of [] > g! c = $b > g! set > null0 null > String SCOPE gogo:* > String _ > StringBuilder b > String c > Closure e $exception printStackTrace > String prompt g! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Missing ASL header
2010/12/1 Nicolas Lalevée : > Hi David, > > >> Ok no response on this, but I've decided to update the file in any >> case. Richard H pointed me at the >> $felix-svn/framework/src/main/resources/default.properties file that >> includes basically the same information as jvm-packages.properties. >> This includes a version attribute which I think will be useful later, >> so I've scrapped the previous contents of jvm-packages.properties and >> gone with this new format. >> >> You should find this file (with associated ASL header) here: >> >> http://svn.apache.org/repos/asf/felix/trunk/sigil/common/core/profiles/jvm-packages.properties > > finally I used a modified version of jvm-packages.properties [1] because I > don't have a "property expander". Or maybe there is in Ivy but I wanted to > quickly fix the unit tests. I'll probably review this later to use the new > format. > >> >> Out of interest I believe bushel and sigil are providing similar >> capabilities - sigil has a mapping of OSGi meta data into an ivy >> resolution - however the way we go about it looks quite different to >> what bushel (does/proposes?). We perform import package resolution >> using an OSGi resolver outside of ivy and then synthesis ivy modules >> at runtime, I believe bushel is intending on pushing the meta >> information into ivy.xml files and then use the standard ivy resolver. > > I think you have clearly summarized the difference here :) > >> Not saying either approach is right/wrong I think it'd be great if >> there is any useful collaborations we can build once you're setup on >> apache - let me know? > > The code has been imported. I am writing some doc right now. I'll try to > probably write something about the difference with sigil. Hopefully I'll > write something fair ;) > I'll keep you posted if I write anything about Sigil. Great it's always useful to get feedback :) > > I'm not sure how we can collaborate and share some code, but I would be happy > to do so. I'll keep subscribed to felix-dev. Yep understood just to say I'm not pushing an uber answer here - in the end it's about making a good set of tools to build code with - where ever that happens is fine by me. I like what we've done with Sigil, but there are definitely many ways to think about these problems, I think at this stage trying all sorts of possibilities is good. Should I follow the ant-dev list for bushel? Regards, Dave > > Nicolas > > [1] > http://svn.apache.org/repos/asf/ant/ivy/core/trunk/src/java/org/apache/ivy/osgi/core/jvm-packages.properties > > >> >> Regards, >> >> Dave >> >> On Mon, Nov 29, 2010 at 4:19 PM, David Savage >> wrote: >>> Hi Nicolas, >>> >>> The commit you found replaces the profile files from Eclipse with a >>> new file which I generated independently. My understanding is that >>> given this file contains information that is public knowledge to the >>> Java community, is of a different format and uses different file >>> access semantics this constitutes it's own IP. As such I'm happy to >>> apply the ASL header on this basis. If that is acceptable then I will >>> push an update with this clarification, PM's please advise? >>> >>> Regards, >>> >>> Dave >>> >>> 2010/11/29 Nicolas Lalevée : Hi, I was working on the import of Bushel into Ivy [1], and there were some files under the EPL which I had to remove from the import. These files were defining the packages which should be part of the bootstrap classpath depending on the execution environment. I then thought I would find such similar files in the source of Felix but ASL friendly. I have found them: [2]. But the ASL header is missing. Then I started to wonder if this file was a real ASF one, and I searched svn and I have found a commit that makes me doubt [3]. Considering the IP contained is these files, I think that the new file is safe to be an ASF one. So could you add the ASL header so there won't be any doubt ? cheers, Nicolas [1] http://www.mail-archive.com/d...@ant.apache.org/msg42079.html [2] http://svn.apache.org/repos/asf/felix/trunk/sigil/common/core/profiles/jvm-packages.properties [3] http://svn.apache.org/viewvc?view=revision&revision=983901 >>> > >
