[jira] Commented: (FELIX-2780) Extension bundle implementation relies on urlhandlers service to start extension bundles
[
https://issues.apache.org/jira/browse/FELIX-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001905#comment-13001905
]
Ingo Bauersachs commented on FELIX-2780:
I use Felix in a WebStart application and got the same error as Psique. The
change introduced by Java 6u24 is that
com.sun.deploy.security.DeployURLClassPath$UrlLoader.findResource calls
URLUtil.checkTargetUrl with http://felix.extensions:9 as a parameter.
As a workaround I managed to get the application running by patching Felix
and replacing the http://felix.extensions:9 URL by file:///felix.extensions/9
(org.apache.felix.framework.ExtensionManager#static initializer)
I have no idea what other consequences this might have (especially on issue
FELIX-844), but at least I got my application running.
Regards,
Ingo
Extension bundle implementation relies on urlhandlers service to start
extension bundles
-
Key: FELIX-2780
URL: https://issues.apache.org/jira/browse/FELIX-2780
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-3.0.7
Environment: Host: Ubuntu Linux
JVM: JAMVM-1.5.4 (patched - see attached patches in Bug 2775)
Library: GNU Classpath 0.98 (patched - see attached patches in Bug 2775)
felix framework - 3.0.7 or 3.1.0-SNAPSHOT
framework.security - 1.4.1 or 1.5.0-SNAPSHOT
Other bundles that are being auto-deployed deployed:
-rw-r--r-- 1 root root 150520 2010-12-26 13:33
org.apache.felix.bundlerepository-1.6.2.jar
-rw-r--r-- 1 root root 90013 2011-01-10 20:06
org.apache.felix.framework.security-1.5.0-SNAPSHOT.jar
-rw-r--r-- 1 samba samba 62727 2011-01-13 12:34
org.apache.felix.shell-1.4.2.jar
-rw-r--r-- 1 samba samba 12748 2011-01-13 12:34
org.apache.felix.shell.tui-1.4.1.jar
Reporter: Samba
Assignee: Karl Pauls
Priority: Minor
I am trying to start the felix security framework extension bundle with the
urlhandler service disabled in the Felix framework.
COMMAND:
==
/usr/local/jamvm/bin/jamvm -Xmx256M -Dfelix.service.urlhandlers=false
-Dorg.osgi.framework.security=osgi
-Dpolicy.provider=gnu.java.security.PolicyFile
-Djava.security.policy=file:///home/samba/wurk/downloads/osgi/felix-framework-3.0.7/conf/java.policy
-jar bin/felix.jar
Policy file:
grant {
permission java.security.AllPermission;
}
grant codeBase http://felix.extensions:9/; {
permission java.security.AllPermission;
};
I get the following error and the security framework does not start
WARNING: Unable to start Felix Extension Activator
(java.nio.channels.UnresolvedAddressException)
Stack trace where the exception occurs
at java.lang.Thread.dumpStack(Thread.java:522)
at
java.nio.channels.UnresolvedAddressException.init(UnresolvedAddressException.java:55)
at gnu.java.nio.SocketChannelImpl.connect(SocketChannelImpl.java:160)
at gnu.java.net.PlainSocketImpl.connect(PlainSocketImpl.java:281)
at java.net.Socket.connect(Socket.java:454)
at java.net.Socket.connect(Socket.java:414)
at
gnu.java.net.protocol.http.HTTPConnection.getSocket(HTTPConnection.java:721)
at
gnu.java.net.protocol.http.HTTPConnection.getOutputStream(HTTPConnection.java:802)
at gnu.java.net.protocol.http.Request.dispatch(Request.java:292)
at
gnu.java.net.protocol.http.HTTPURLConnection.connect(HTTPURLConnection.java:219)
at
gnu.java.net.protocol.http.HTTPURLConnection.getHeaderField(HTTPURLConnection.java:582)
at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:426)
at java.net.URLConnection.getContentLength(URLConnection.java:302)
at gnu.java.net.loader.RemoteURLLoader.getResource(RemoteURLLoader.java:79)
at java.net.URLClassLoader.findClass(URLClassLoader.java:528)
at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
at java.lang.ClassLoader.loadClass(ClassLoader.java:293)
at
org.apache.felix.framework.ExtensionManager.startExtensionBundle(ExtensionManager.java:381)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2610)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2429)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:121)
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:107)
at
org.apache.felix.main.AutoProcessor.processAutoDeploy(AutoProcessor.java:173)
at org.apache.felix.main.AutoProcessor.process(AutoProcessor.java:78)
at org.apache.felix.main.Main.main(Main.java:291)
at java.lang.reflect.VMMethod.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:327)
at
Re: [suggestion] - OSGI WebConsole
Hi, First: This is the last cross posted message from me. Future communication should and will take place on the Felix list. Please, come to that list and discuss with us here ! Am Donnerstag, den 03.03.2011, 07:40 + schrieb Charles Moulliard: On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger fmesc...@adobe.com wrote: Hi, As the original developer of the Web Console I am flattered by this activity ;-) Am Mittwoch, den 02.03.2011, 17:37 + schrieb Charles Moulliard: Hi, As three users of Apache Felix WebConsole project, I contact you to have your opinion regarding to frameworks (JSon, javascript, ...) usage made with Apache Felix WebConsole. The project has been made light to avoid dependencies with external librairies but the way that it is used today lack of structure, complicate the Why lack of structure ? Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble. Well, this is just an implementation detail of the plugins coming with the Web Console proper. Nowhere is it prescribed that you have to do it this way. I think Guillaume has clearly described the issues around this. development of screens and decrease development productivity, html code is mixed in javascript, json variables are set everywhere in the code and use in several of javascript functions, no template is used to render html pages, locale is not used by all of us to translate text, That's all not required. The simplest plugin is a Servlet service with two service properties. Nothing fancy, really ;-) The consequence of that is that some developers are very frustrated and would like to make some suggestions about Webconsole. Within Karaf community we already started this discussion and now we would like to share with you some ideas about the future roadmap of Felix WebConsole. I'm sorry you are very frustrated .. at the same time I do not understand why you don't come to the Felix dev or user list to ask questions ? This is a bit frustrating to me. The word frustrated was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation. The Web Console lives in the Apache Felix project. So please, come to use and talk to us. Start the discussion here and with us. We will listen to you. Here are the different scenario possible : (1) Improve the existing usage of the frameworks JSon, OSGI and javascript by defining/providing a template project containing dummy code + guidelines/best practices to develop properly and so improve/increase productivity. This could be done with an archetype Sounds like an excellent idea. (2) Switch the existing architectural model to use frameworks like Apache Wicket or Vaadin where the content is clearly separated from the server side code. Apache Wicket and Vaadin librairies are already osgified so their integration in project like karaf, sling or felix will be done seamless even if we have the overhead to deploy them. But this is also the same for bundles like PAX-Web, ... Sounds like not soo go an idea. There is a reason why we don't use any of these frameworks: We wanted (and still want) to minimize dependencies. Adding such a nice GUI framework to the game makes it more complicated (remember the simple Servlet service mentioned above ?) and heavy weight. Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact. I know very well about the functionality provided by those platforms. But all these platforms come with additional dependencies. And this is where I start placing question marks. Also be reminded that Web Console is currently being used in embedded platforms which don't have place to spare for the developers delight. However, this is not to say, that we should not explore ways on how mechanism like JSP (or generic server side scripting) etc. can be used. No matter which scenario we will decide to adopt, we could also create a project to develop all together the OSGI WebConsole used by our projects and promote it as a new Apache project -- Name suggested Apache Orion. The scope of this project could be extended to include additional management, registration of datasources, What would be the advantage of developing the Web Console in its own TLP ? Is there something missing when living in the
[WebConsole] Own Top Level Project
Hi all, Taking from [1] into a separate thread. Charles Moulliard raised the question of creating a new Apache Top Level Project for the Web Console: No matter which scenario we will decide to adopt, we could also create a project to develop all together the OSGI WebConsole used by our projects and promote it as a new Apache project -- Name suggested Apache Orion. The scope of this project could be extended to include additional management, registration of datasources, I think moving the Web Console to its own top level project is not needed for the following reasons: * The Web Console (and its current developers) are quite happy living in the Apache Felix community. * The Apache Felix community is open to suggestions and extensions for the Web Console. What do others think ? Regards Felix [1] http://markmail.org/message/l3xyzpqzat3qvrjh
Re: [WebConsole] Own Top Level Project
In the current state of the web console, I fully agree with you. On Thu, Mar 3, 2011 at 09:50, Felix Meschberger fmesc...@adobe.com wrote: Hi all, Taking from [1] into a separate thread. Charles Moulliard raised the question of creating a new Apache Top Level Project for the Web Console: No matter which scenario we will decide to adopt, we could also create a project to develop all together the OSGI WebConsole used by our projects and promote it as a new Apache project -- Name suggested Apache Orion. The scope of this project could be extended to include additional management, registration of datasources, I think moving the Web Console to its own top level project is not needed for the following reasons: * The Web Console (and its current developers) are quite happy living in the Apache Felix community. * The Apache Felix community is open to suggestions and extensions for the Web Console. What do others think ? Regards Felix [1] http://markmail.org/message/l3xyzpqzat3qvrjh -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] main.distribution 3.0.9
+1 regards, Karl On Mon, Feb 28, 2011 at 5:03 PM, Carsten Ziegeler cziege...@apache.org wrote: +1 Carsten Karl Pauls wrote I would like to call a vote on the following subproject release: main.distribution 3.0.9 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-060/ 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 060 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Carsten Ziegeler cziege...@apache.org -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] main.distribution 3.0.9
+1 On Sun, Feb 27, 2011 at 23:37, Karl Pauls karlpa...@gmail.com wrote: I would like to call a vote on the following subproject release: main.distribution 3.0.9 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-060/ 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 060 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE][RESULT] main.distribution 3.0.9
Time to call the vote on the Felix main.distribution 3.0.9 subproject release. * +1 votes from Clement Escoffier, Richard S. Hall, Felix Meschberger, Pierre De Rop, Carsten Ziegeler, and Karl Pauls. * No other votes The vote is successful. I will make the release artifacts available as soon as possible
Check staging script does not work anymore
Hi, I just realized that our check staging script does not work anymore. You can try this with: ./check_staged_release.sh 003 It seems that requesting the index.html of a dir does not work anymore. Maybe it's possible to change wget to not request index.html when the url ends in a slash? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [WebConsole] Own Top Level Project
IMHO, the WebConsole and core plugins should stay in Felix. Other projects (ASF or not) should have their own plugins as necessary. The two items mentioned below (management datasource registration) belong with Aries IMHO. Justin On Mar 3, 2011, at 3:50 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi all, Taking from [1] into a separate thread. Charles Moulliard raised the question of creating a new Apache Top Level Project for the Web Console: No matter which scenario we will decide to adopt, we could also create a project to develop all together the OSGI WebConsole used by our projects and promote it as a new Apache project -- Name suggested Apache Orion. The scope of this project could be extended to include additional management, registration of datasources, I think moving the Web Console to its own top level project is not needed for the following reasons: * The Web Console (and its current developers) are quite happy living in the Apache Felix community. * The Apache Felix community is open to suggestions and extensions for the Web Console. What do others think ? Regards Felix [1] http://markmail.org/message/l3xyzpqzat3qvrjh
Board report time
I've taken an initial pass at the board report: https://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282011-03%29 It is somewhat paltry, so hopefully other people can think of some things I'm missing. Related question, is it worthwhile to mention that Felix framework as well as some other subprojects were included in the recently released GlassFish 3.1? - richard
Re: Board report time
On 3 Mar 2011, at 21:50 , Richard S. Hall wrote: It is somewhat paltry, so hopefully other people can think of some things I'm missing. Well, we could hire a good story teller to make it look better, but I think it nicely sums up that we've been quite productive releasing different bundles. Trying hard to think of things to say about the community, but I think it is pretty stable now and working well. Nothing particular I feel worth reporting to the board. Related question, is it worthwhile to mention that Felix framework as well as some other subprojects were included in the recently released GlassFish 3.1? I definitely think it is! Greetings, Marcel
Re: Board report time
Seems I forgot to delete tags for failed releases. I'll delete them and update the report asap. On Thu, Mar 3, 2011 at 21:50, Richard S. Hall he...@ungoverned.org wrote: I've taken an initial pass at the board report: https://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282011-03%29 It is somewhat paltry, so hopefully other people can think of some things I'm missing. Related question, is it worthwhile to mention that Felix framework as well as some other subprojects were included in the recently released GlassFish 3.1? - richard -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Board report time
Hi, Am Donnerstag, den 03.03.2011, 20:50 + schrieb Richard S. Hall: I've taken an initial pass at the board report: https://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282011-03%29 It is somewhat paltry, so hopefully other people can think of some things I'm missing. Related question, is it worthwhile to mention that Felix framework as well as some other subprojects were included in the recently released GlassFish 3.1? Hehe, so its time to wear my company's hat ? Our very own products also include the framework and other subprojects, of course ;-) Yet, I am somewhat unsure, whether the board report is the right place to note this ... In Sling we have created a Wiki page [1] listing known users of Sling and wo which we invite participation. How about something like this (in the community section): A number of open source and commercial products are making use of the Apache Felix framework and other subprojects. Details on url here. WDYT ? Regards Felix [1] https://cwiki.apache.org/SLING/who-is-using-sling-.html
