Re: Google Summer of Code
Hi, Guillaume wrote about pluggable user authentication mechanism for Karaf shell. I think it's good for second part of my GSoC program. Could you write more about security in Karaf and Felix? Where passwords are stored and how? regards, Marcin 2009/6/10 Guillaume Nodet gno...@gmail.com The security part can be slit in two different goals imho; * pluggable user authentication mechanism * command based authorization for the authenticated user The last one is much more optional, but it would mean defining roles / groups that the user needs to belong to for each shell command / ui tab / ui action, and make sure the authenticated user is authorized to perform such a command. On Wed, Jun 10, 2009 at 13:17, Felix Meschbergerfmesc...@gmail.com wrote: Hi, Guillaume Nodet schrieb: Another idea as the first step for security would be the authentication mechanism we discussed on another thread. Currently, the web console uses a ConfigAdmin to retrieve the username / password. This layer should be pluggable and allow the current mechanism, UserAdmin or JAAS to be plugged in somehow. That's in fact how I understood your first point ;-) Regards Felix On Wed, Jun 10, 2009 at 12:04, Guillaume Nodetgno...@gmail.com wrote: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. On Wed, Jun 10, 2009 at 09:37, Gert Vanthienen gert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
can be used to render the 'main' contents of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? What else would be required ? Wouldn't we need an implementation of the API to glue this all together? What do you mean by register a JAX-RS bean ? IMHO registering a javax.servlet.Service is very appropriate in the OSGi context. Regards Felix Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? What else would be required ? Wouldn't we need an implementation of the API to glue this all together? What do you mean by register a JAX-RS bean ? IMHO registering a javax.servlet.Service is very appropriate in the OSGi context. Regards Felix Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked
Re: Google Summer of Code
Hi, Moloney, Tim M schrieb: My point was that this thread is concerned with using web technologies to enhance the webconsole. If applicable, these web technologies could be wrapped/ported/extended/whatever to make them generally available in OSGi. Then the webconsole could use them just like any other servlet. I agree and I think we settled this issue in this direction. Thanks for the pointer to Sling's JSON bundle. I currently do use a modified version of Sling's JSON bundle (version 2.0.2-incubator). The stock version requires JCR which we don't need, so I just remove src/main/java/org/apache/sling/commons/json/jcr/JsonItemWriter.java and src/test/java/org/apache/sling/commons/json/jcr/JsonItemWriterTest.java then rebuild. Good point. Maybe it would be good for the Sling JSON bundle to import the JCR dependency either dynamically or optionally. WDYT ? Regards Felix I just recently started using gson (http://code.google.com/p/google-gson/) which is a higher level library. So far, I'm very happy with it. The trunk now packages gson as a bundle and should be in their next release (gson 1.4). Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Felix Meschberger [mailto:fmesc...@gmail.com] Sent: Wednesday, June 10, 2009 09:24 To: dev@felix.apache.org Subject: Re: Google Summer of Code Hi Tim, The Apache Sling project has a bundle-ized version of the JSON library. I am sure there are others around. Is that what is of interest to you ? Regards Felix Moloney, Tim M schrieb: I'm not familiar with JAX-RS but I do use JSON. Most bundles that I've seen that use JSON simply embed a JSON library. Could some of these technologies be made available to bundles implementing servlets that are *not* part of the webconsole? Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Juan José Vázquez Delgado [mailto:juanjo.vazq...@gmail.com] Sent: Wednesday, June 10, 2009 04:23 To: dev@felix.apache.org Subject: Re: Google Summer of Code Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Ok. In the other hand, I´m agree with Felix, a pluggable design would be desirable. What about a JSON based server layer?. You could still use JAX-RS anyway. BR, Juanjo.
Re: Google Summer of Code
I've given you karma on the wiki. On Wed, Jun 10, 2009 at 17:41, Marcin Wilkosmarcin.wil...@gmail.com wrote: I can't edit this wiki. I think I need credentials to do this. My user name: mwilkos 2009/6/10 Gert Vanthienen gert.vanthie...@gmail.com Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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
RE: Google Summer of Code
Felix Meschberger [mailto:fmesc...@gmail.com] wrote Moloney, Tim M schrieb: Thanks for the pointer to Sling's JSON bundle. I currently do use a modified version of Sling's JSON bundle (version 2.0.2-incubator). The stock version requires JCR which we don't need, so I just remove src/main/java/org/apache/sling/commons/json/jcr/JsonItemWriter .java and src/test/java/org/apache/sling/commons/json/jcr/JsonItemWriter Test.java then rebuild. Good point. Maybe it would be good for the Sling JSON bundle to import the JCR dependency either dynamically or optionally. WDYT ? Sure. If you can have the optional/dynamic dependency that would provide for general resuse and satisfy Sling's current needs. Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw
Re: Google Summer of Code
Hi Marcin Marcin Wilkos schrieb: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. Nice to hear that. Looking forward to your patches ! In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Cool ! For things related to the Web Console itself our issue tracking system [1] has a Web Console component. There is also a master issue with three sub-issues regarding the extensibility of the Web Console (FELIX-1013, [2]), which you might want to use. Thanks. Regards Felix [1] https://issues.apache.org/jira/browse/FELIX [2] https://issues.apache.org/jira/browse/FELIX-1013
Re: Google Summer of Code
implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSL the world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man. George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSL the world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man. George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
Juanjo, Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/10 Juan José Vázquez Delgado juanjo.vazq...@gmail.com: You're right about the dependencies obviously: the plugin bundle would need to depend on the JAXRS API but the web console itself would depend on the API and some implementation like Jersey. Just a point, why Jersey? What about Apache CXF JAX-RS implementation [1]? [1] http://cwiki.apache.org/CXF20DOC/jax-rs.html Juanjo.
Re: Google Summer of Code
Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Ok. In the other hand, I´m agree with Felix, a pluggable design would be desirable. What about a JSON based server layer?. You could still use JAX-RS anyway. BR, Juanjo.
Re: Google Summer of Code
without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? What else would be required ? Wouldn't we need an implementation of the API to glue this all together? What do you mean by register a JAX-RS bean ? IMHO registering a javax.servlet.Service is very appropriate in the OSGi context. Regards Felix Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
Two ideas for the console: * add some security to the console / shell (role based for a given action / command) * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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
Re: Google Summer of Code
Another idea as the first step for security would be the authentication mechanism we discussed on another thread. Currently, the web console uses a ConfigAdmin to retrieve the username / password. This layer should be pluggable and allow the current mechanism, UserAdmin or JAAS to be plugged in somehow. On Wed, Jun 10, 2009 at 12:04, Guillaume Nodetgno...@gmail.com wrote: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
Hi, Guillaume Nodet schrieb: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) +1 * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. This already exists: If you install the shell service bundle, the web console has a Shell page which provides you with shell access inside the browser. Regards Felix On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
Hi, Guillaume Nodet schrieb: Another idea as the first step for security would be the authentication mechanism we discussed on another thread. Currently, the web console uses a ConfigAdmin to retrieve the username / password. This layer should be pluggable and allow the current mechanism, UserAdmin or JAAS to be plugged in somehow. That's in fact how I understood your first point ;-) Regards Felix On Wed, Jun 10, 2009 at 12:04, Guillaume Nodetgno...@gmail.com wrote: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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
Re: Google Summer of Code
The security part can be slit in two different goals imho; * pluggable user authentication mechanism * command based authorization for the authenticated user The last one is much more optional, but it would mean defining roles / groups that the user needs to belong to for each shell command / ui tab / ui action, and make sure the authenticated user is authorized to perform such a command. On Wed, Jun 10, 2009 at 13:17, Felix Meschbergerfmesc...@gmail.com wrote: Hi, Guillaume Nodet schrieb: Another idea as the first step for security would be the authentication mechanism we discussed on another thread. Currently, the web console uses a ConfigAdmin to retrieve the username / password. This layer should be pluggable and allow the current mechanism, UserAdmin or JAAS to be plugged in somehow. That's in fact how I understood your first point ;-) Regards Felix On Wed, Jun 10, 2009 at 12:04, Guillaume Nodetgno...@gmail.com wrote: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
From a Karaf point of view, we need to plug in the karaf shell into it instead of the felix shell. The karaf shell provides more features (additional commands, command / argument completion, history, etc...) that karaf users would want to leverage. I guess the added difficulty is that the karaf shell does not work the same way: i.e. you don't launch a command and grab the ouput of the command, but rather you have an output stream and an error stream which are not tied to a given command, so the ui has to be implemented slightly differently. On Wed, Jun 10, 2009 at 13:16, Felix Meschbergerfmesc...@gmail.com wrote: Hi, Guillaume Nodet schrieb: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) +1 * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. This already exists: If you install the shell service bundle, the web console has a Shell page which provides you with shell access inside the browser. Regards Felix On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- 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
Re: Google Summer of Code
Guillaume Nodet schrieb: From a Karaf point of view, we need to plug in the karaf shell into it instead of the felix shell. The karaf shell provides more features (additional commands, command / argument completion, history, etc...) that karaf users would want to leverage. I guess the added difficulty is that the karaf shell does not work the same way: i.e. you don't launch a command and grab the ouput of the command, but rather you have an output stream and an error stream which are not tied to a given command, so the ui has to be implemented slightly differently. Ok, this sounds more like how the new OSGi shell is defined with respect to streams. On Wed, Jun 10, 2009 at 13:16, Felix Meschbergerfmesc...@gmail.com wrote: Hi, Guillaume Nodet schrieb: Two ideas for the console: * add some security to the console / shell (role based for a given action / command) +1 * have a low level shell access from the console (using command line as we already discussed) I guess both are not simple problems to tackle, so not sure Marcin availability will be enough. If not, I'd be glad to try implementing the low level shell access from the console. My thinking about that was to have a hidden feature as Hiram demonstrated some time ago on his prototype. Typing '~' in the console would bring up a popup and start a shell with the credentials of the user that logged into the web console (not sure how to retrieve those in a safe manner yet). Typing again the same key would hide the popup. This already exists: If you install the shell service bundle, the web console has a Shell page which provides you with shell access inside the browser. Regards Felix On Wed, Jun 10, 2009 at 09:37, Gert Vanthienengert.vanthie...@gmail.com wrote: Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
RE: Google Summer of Code
I'm not familiar with JAX-RS but I do use JSON. Most bundles that I've seen that use JSON simply embed a JSON library. Could some of these technologies be made available to bundles implementing servlets that are *not* part of the webconsole? Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Juan José Vázquez Delgado [mailto:juanjo.vazq...@gmail.com] Sent: Wednesday, June 10, 2009 04:23 To: dev@felix.apache.org Subject: Re: Google Summer of Code Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Ok. In the other hand, I´m agree with Felix, a pluggable design would be desirable. What about a JSON based server layer?. You could still use JAX-RS anyway. BR, Juanjo.
Re: Google Summer of Code
Hi Tim, The Apache Sling project has a bundle-ized version of the JSON library. I am sure there are others around. Is that what is of interest to you ? Regards Felix Moloney, Tim M schrieb: I'm not familiar with JAX-RS but I do use JSON. Most bundles that I've seen that use JSON simply embed a JSON library. Could some of these technologies be made available to bundles implementing servlets that are *not* part of the webconsole? Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Juan José Vázquez Delgado [mailto:juanjo.vazq...@gmail.com] Sent: Wednesday, June 10, 2009 04:23 To: dev@felix.apache.org Subject: Re: Google Summer of Code Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Ok. In the other hand, I´m agree with Felix, a pluggable design would be desirable. What about a JSON based server layer?. You could still use JAX-RS anyway. BR, Juanjo.
RE: Google Summer of Code
My point was that this thread is concerned with using web technologies to enhance the webconsole. If applicable, these web technologies could be wrapped/ported/extended/whatever to make them generally available in OSGi. Then the webconsole could use them just like any other servlet. Thanks for the pointer to Sling's JSON bundle. I currently do use a modified version of Sling's JSON bundle (version 2.0.2-incubator). The stock version requires JCR which we don't need, so I just remove src/main/java/org/apache/sling/commons/json/jcr/JsonItemWriter.java and src/test/java/org/apache/sling/commons/json/jcr/JsonItemWriterTest.java then rebuild. I just recently started using gson (http://code.google.com/p/google-gson/) which is a higher level library. So far, I'm very happy with it. The trunk now packages gson as a bundle and should be in their next release (gson 1.4). Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Felix Meschberger [mailto:fmesc...@gmail.com] Sent: Wednesday, June 10, 2009 09:24 To: dev@felix.apache.org Subject: Re: Google Summer of Code Hi Tim, The Apache Sling project has a bundle-ized version of the JSON library. I am sure there are others around. Is that what is of interest to you ? Regards Felix Moloney, Tim M schrieb: I'm not familiar with JAX-RS but I do use JSON. Most bundles that I've seen that use JSON simply embed a JSON library. Could some of these technologies be made available to bundles implementing servlets that are *not* part of the webconsole? Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Juan José Vázquez Delgado [mailto:juanjo.vazq...@gmail.com] Sent: Wednesday, June 10, 2009 04:23 To: dev@felix.apache.org Subject: Re: Google Summer of Code Yeah, sorry about that. Jersey was just an example but obviously CXF JAX-RS would be a great alternative to that ;) Ok. In the other hand, I´m agree with Felix, a pluggable design would be desirable. What about a JSON based server layer?. You could still use JAX-RS anyway. BR, Juanjo.
Re: Google Summer of Code
I can't edit this wiki. I think I need credentials to do this. My user name: mwilkos 2009/6/10 Gert Vanthienen gert.vanthie...@gmail.com Guillaume, I created http://cwiki.apache.org/confluence/display/FELIX/GSoC+2009 to keep track of this. The current working schedule is at the top of the page, with the bits of information I'm aware of already filled in. I added the original schedule at the bottom, but because of our decision to leverage the Felix Web Console, most of the tasks in that schedule are no longer necessary. So if people have any suggestions for other work to fill in those gaps... Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Guillaume Nodet gno...@gmail.com: Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code
Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code
L.S., How about adding support for using JAX-RS resource beans for extending the felix web console? So instead of registering a servlet, you can register a JAX-RS bean. One of the methods on the bean can be used to render the 'main' contents of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSL the world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man. George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
RE: Google Summer of Code
On Tuesday, June 09, 2009 03:29, Felix Meschberger [mailto:fmesc...@gmail.com] wrote: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Great information. Now that I'm better informed, I'll give it another go. Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Granted, I made some assumptions. Most of the time when you implement an interface or extend an abstract class that is part of a plugin system, especially ones with method names like init() and activate(), you register the object and the plugin system initializes the object by calling the init() or activate() method. I see that the feature plugin didn't do that in the Java code so I assumed that whatever code found and loaded the feature plugin would also call activate(). With the information you provided above, I see that Spring is registering the service but is it calling activate()? I don't know Spring. How would I register a URL other than the plugin page? For example, the bundles plugin has bundles.js and several images. Is there a convenient way to register URLs for a plugin or do I just register them with the HttpService myself? Thanks for the missing information. Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw
Re: Google Summer of Code
Hi, Moloney, Tim M schrieb: On Tuesday, June 09, 2009 03:29, Felix Meschberger [mailto:fmesc...@gmail.com] wrote: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Great information. Now that I'm better informed, I'll give it another go. Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Granted, I made some assumptions. Most of the time when you implement an interface or extend an abstract class that is part of a plugin system, especially ones with method names like init() and activate(), you register the object and the plugin system initializes the object by calling the init() or activate() method. Yes, true. This may be part of the history and evolvment of the plugin API. And I fully agree, that without any JavaDoc at all, this is hard to understand and grock !! I see that the feature plugin didn't do that in the Java code so I assumed that whatever code found and loaded the feature plugin would also call activate(). With the information you provided above, I see that Spring is registering the service but is it calling activate()? I don't know Spring. I don't know (yet) how the plugin is done, I will have a look at it and try to see, what is going on. How would I register a URL other than the plugin page? For example, the bundles plugin has bundles.js and several images. Is there a convenient way to register URLs for a plugin or do I just register them with the HttpService myself? This is registering resources. It is listed as one of the open issues with respect to the console extensibility. For the Web Console itself we register a resource location with the HttpService. For plugins, I think this is not appropriate. Rather there should probably be a mechanism to provide the resource such that the Web Console can grab it much like we do for plugin servlets. One idea I had was listing the resource paths (or locations) in the bundle manifest and the Web Console would pick these up and delegate appropriately. Regards Felix Thanks for the missing information. Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015
Re: Google Summer of Code
Hi, Gert Vanthienen schrieb: L.S., How about adding support for using JAX-RS resource beans for extending the felix web console? So instead of registering a servlet, you can register a JAX-RS bean. One of the methods on the bean can be used to render the 'main' contents of the web console plugin page, but you can also add other methods and annotate them with GET/POST for providing JSON resources or handling form submits. This will also remove the dependency on the felix web console bundle for the extension bundle while making it easier to implement multiple uris/actions without having to override the doGet/doPost methods and allow us to use some other template engine/language (JSP, Lift, ...) in the extension bundle without the need for the felix web console to be aware of those. The only real drawback I see is the fact that the Felix Web Console bundle itself would get another dependency, it would need the JAX-RS API. Wdyt? What else would be required ? Wouldn't we need an implementation of the API to glue this all together? What do you mean by register a JAX-RS bean ? IMHO registering a javax.servlet.Service is very appropriate in the OSGi context. Regards Felix Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger fmesc...@gmail.com: Hi, Moloney, Tim M schrieb: I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the inner contents of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named felix.webconsole.label must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. How do you define work as expected ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused
Re: Google Summer of Code
Yeah ! Keep up the good work. Do you have a plan for the coming weeks / monthes. Maybe you could create a wiki page somewhere or maybe even an email so we can get see what you plan to work on and maybe give some input / discuss things ? On Mon, Jun 8, 2009 at 23:32, Marcin Wilkosmarcin.wil...@gmail.com wrote: Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Google Summer of Code
Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
RE: Google Summer of Code
I've been working with Karaf and features a lot recently. I was curious how a webconsole plugin would work so I looked at your code. I was happy to see that things seemed very simple and straight-forward so I was inspired to try to extend your features plugin. I quickly discovered that things are not what they appeared. I didn't investigate how the core plugins are loaded but the features plugin appears to be loaded via Spring. Loading plugins this way doesn't use AbstractWebConsolePlugin as it is advertised and many things just don't work (activate() and deactivate() are never called, getBundleContext() returns null, etc). It looks like a lot of the webconsole infrastructure is hidden in org.apache.felix.webconsole.internal so to get a plugin working with any reasonable functionality would require duplicating a lot of those classes. Perhaps I missed the proper way to initialize a webconsole plugin and get at the utility methods. If not, I would suggest refactoring the infrastructure of webconsole so that extending AbstractWebConsolePlugin does work as expected. Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] Sent: Monday, June 08, 2009 17:32 To: dev@felix.apache.org Subject: Google Summer of Code Hi, I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on webconsole for Karaf and ServiceMix as GSoC project. I'll be sending weekly reports to this list. In last week I focused on first extension for felix web console, which lists Karaf features. I created JIRA issue for this and uploaded a patch. Gert checked it and uploaded to svn. Regards, Marcin Wilkos
Re: Google Summer of Code: Marcin Wilkos
L.S., Using the optional import by default (for quick and easy branding) and documenting how to build a more 'safe' branding by unzipping the distro and hacking it to remove the optional imports sounds like a good compromise to me. Having something like goosh.org for our own console inside the web console sounds like a great idea too. For securing the web console, wouldn't it make sense to integrate that with Karaf's JAAS support, so we can plug in other providers afterwards (e.g. things like LDAP)? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/26 Guillaume Nodet gno...@gmail.com: On Tue, May 26, 2009 at 11:00, Carsten Ziegeler cziege...@apache.org wrote: Filippo Diotalevi wrote: On Tue, May 26, 2009 at 8:11 AM, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. That's very interesting. I think some starting points might be http://issues.apache.org/jira/browse/FELIX-1013 (umbrella issue for web console extensibility) http://issues.apache.org/jira/browse/FELIX-1051 (localization support) We had some discussions on this topic, but never really got to the point to implement it (just because of lack of time :) ). I've been thinking about this lately and I'm more and more thinking about not using an optional import. Rebranding something is usely meant that it stays rebranded, like if you want to bundle the web console with your own product. It is too easy to uninstall the optional bundle. You're right to some degree. I'd like the console to be branded with Karaf, while people using Karaf may want to rebrand it too. Rebranding Karaf also means rebranding the Karaf shell and both should be able to be done easily and I don't think unzipping karaf distribution and hacking more than one bundle is an easy way. So I think we need a safer way. We also had the discussion (and I think there is a jira issue for this as well), to configure which configuration tabs are available - you might not want to use the tab for the config admin which comes with the web console - or you want to disable the obr tab etc. Again this could be done with some configuration and/or optional importants but can be easily overriden which is not what you want. So to keep the long story short, I'm more in favour of customization at build time, you create your project, which depends on the web console and it just adds additional files, overwrites configs (whatever) and creates your web console bundle. Maybe there is a better way inbetween those two solutions? If we use an optional import, people wanting to safely rebrand the console without allowing people to modify it could still choose to repackage the web console bundle by putting customized resources directly into it and remove this optional import, right ? Btw, I also think that we should secure the web console and check the role of the current user for authorization purposes. Right. I think at some point we also want to add access to the shell through the web console and we also need to secure the shell commands. Hiram and I did some experiment some time ago, but it was based on a gwt web console, so it will need to be rewritten. Such a shell could provided access to other shell commands for admin confortable with command lines. Carsten -- Carsten Ziegeler cziege...@apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
On May 27, 2009, at 8:53 , Gert Vanthienen wrote: For securing the web console, wouldn't it make sense to integrate that with Karaf's JAAS support, so we can plug in other providers afterwards (e.g. things like LDAP)? Should we not use the UserAdmin compendium service for that? To be honest, I'm not familiar with Karaf's JAAS support, is that build as an implementation of UserAdmin? Greetings, Marcel
Re: Google Summer of Code: Marcin Wilkos
Guillaume Nodet wrote: If we use an optional import, people wanting to safely rebrand the console without allowing people to modify it could still choose to repackage the web console bundle by putting customized resources directly into it and remove this optional import, right ? Doh, yepp, of course :) Sometimes things are too easy. Great! Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Google Summer of Code: Marcin Wilkos
Marcel Offermans wrote: On May 27, 2009, at 8:53 , Gert Vanthienen wrote: For securing the web console, wouldn't it make sense to integrate that with Karaf's JAAS support, so we can plug in other providers afterwards (e.g. things like LDAP)? Should we not use the UserAdmin compendium service for that? To be honest, I'm not familiar with Karaf's JAAS support, is that build as an implementation of UserAdmin? Yes, I think we should go with UserAdmin, too. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Google Summer of Code: Marcin Wilkos
I need to read a bit more about UserAdmin. I think it should be possible to have a JAAS LoginModule delegating to UserAdmin. However, for the console, it may be quite easy to come up with a very simple interface that would delegate to either JAAS or UserAdmin. The OSGi EEG is working on a spec for integrating JAAS into OSGi, so I think it makes sense to be able to support both. On Wed, May 27, 2009 at 09:08, Carsten Ziegeler cziege...@apache.org wrote: Marcel Offermans wrote: On May 27, 2009, at 8:53 , Gert Vanthienen wrote: For securing the web console, wouldn't it make sense to integrate that with Karaf's JAAS support, so we can plug in other providers afterwards (e.g. things like LDAP)? Should we not use the UserAdmin compendium service for that? To be honest, I'm not familiar with Karaf's JAAS support, is that build as an implementation of UserAdmin? Yes, I think we should go with UserAdmin, too. Carsten -- Carsten Ziegeler cziege...@apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
Hi Gert, Gert Vanthienen schrieb: Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. We would definitely consider building this on top the Felix Web Console. Makes absolute sense. It already has some of the functionality we're looking for and it already is extensible -- there some information on the Felix website [2] and I know the Sling project has built some extensions to the console, so we can find a code example there. Is there any other information around for this? Are there any limitations we have to be aware of before starting the project? Yes, it currently is extensible by just registering a javax.servlet.Servlet service with a particular service property set to be used as a marker. For simplicity there is an AbstractWebConsolePlugin which may be extended so as the plugin servlet does not need to render the navigation stuff itself. The drawback is, that you have to import the AbstractWebConsolePlugin package in your bundle, which is kind of intrusive IMHO. So I am working on a proxy approach, where again the service is a plain Servlet with two service properties: one denoting the Servlet as a plugin and a second one asking the console to wrap the Servlet inside a proxy for the AbstractWebConsolePlugin. This way the registered Servlet only renders the interior. I guess we already know about one such limitation: Apache Felix Karaf has the ability to 'rebrand' the text console with another ASCII art logo and header, so we would want that for the web console as well. As far as I can see, this is not yet supported by the Felix Web Console. Are there any plans to support that? We have been discussing this and I think there is also an issue for this already. Rebranding is very interesting and important, so I would also be interested in seeing this in the console. Regards Felix
Re: Google Summer of Code: Marcin Wilkos
Hi, I would also prefer UserAdmin over JAAS, since this would allow for other implementations of that service to provide access control. For example Carsten and I have once been discussing implementing UserAdmin on top of a JCR Repository (e.g. Jackrabbit) to leverage existing user setups. Regards Felix Guillaume Nodet schrieb: I need to read a bit more about UserAdmin. I think it should be possible to have a JAAS LoginModule delegating to UserAdmin. However, for the console, it may be quite easy to come up with a very simple interface that would delegate to either JAAS or UserAdmin. The OSGi EEG is working on a spec for integrating JAAS into OSGi, so I think it makes sense to be able to support both. On Wed, May 27, 2009 at 09:08, Carsten Ziegeler cziege...@apache.org wrote: Marcel Offermans wrote: On May 27, 2009, at 8:53 , Gert Vanthienen wrote: For securing the web console, wouldn't it make sense to integrate that with Karaf's JAAS support, so we can plug in other providers afterwards (e.g. things like LDAP)? Should we not use the UserAdmin compendium service for that? To be honest, I'm not familiar with Karaf's JAAS support, is that build as an implementation of UserAdmin? Yes, I think we should go with UserAdmin, too. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Google Summer of Code: Marcin Wilkos
Right, I think there is a real need to support UserAdmin, but given
both JAAS and UserAdmin will be used for the same thing, it should be
easy to support both using a simple interface:
public interface WebConsoleSecurityProvider {
/** Check if the user with the specified password exists and
return an object identifying the user, else throw an exception */
public Object authenticate(String username, String password)
throws SecurityException;
/** Check that the authenticated user has the given role
permission or throw an exception */
public void authorize(Object user, String role) throws SecurityException;
}
Imho, this should be sufficient to provide authentication and
authorization for the web console and can be easily implemented using
UserAdmin or JAAS.
On Wed, May 27, 2009 at 10:24, Felix Meschberger fmesc...@gmail.com wrote:
Hi,
I would also prefer UserAdmin over JAAS, since this would allow for
other implementations of that service to provide access control.
For example Carsten and I have once been discussing implementing
UserAdmin on top of a JCR Repository (e.g. Jackrabbit) to leverage
existing user setups.
Regards
Felix
Guillaume Nodet schrieb:
I need to read a bit more about UserAdmin.
I think it should be possible to have a JAAS LoginModule delegating to
UserAdmin.
However, for the console, it may be quite easy to come up with a very
simple interface that would delegate to either JAAS or UserAdmin. The
OSGi EEG is working on a spec for integrating JAAS into OSGi, so I
think it makes sense to be able to support both.
On Wed, May 27, 2009 at 09:08, Carsten Ziegeler cziege...@apache.org wrote:
Marcel Offermans wrote:
On May 27, 2009, at 8:53 , Gert Vanthienen wrote:
For securing the web console,
wouldn't it make sense to integrate that with Karaf's JAAS support, so
we can plug in other providers afterwards (e.g. things like LDAP)?
Should we not use the UserAdmin compendium service for that? To be
honest, I'm not familiar with Karaf's JAAS support, is that build as an
implementation of UserAdmin?
Yes, I think we should go with UserAdmin, too.
Carsten
--
Carsten Ziegeler
cziege...@apache.org
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
Hello Guillaume,
On May 27, 2009, at 11:20 , Guillaume Nodet wrote:
Right, I think there is a real need to support UserAdmin, but given
both JAAS and UserAdmin will be used for the same thing, it should be
easy to support both using a simple interface:
public interface WebConsoleSecurityProvider {
/** Check if the user with the specified password exists and
return an object identifying the user, else throw an exception */
public Object authenticate(String username, String password)
throws SecurityException;
/** Check that the authenticated user has the given role
permission or throw an exception */
public void authorize(Object user, String role) throws
SecurityException;
}
Imho, this should be sufficient to provide authentication and
authorization for the web console and can be easily implemented using
UserAdmin or JAAS.
To be honest, UserAdmin already is an interface which abstracts from
an implementation, so I don't really see a need to add another
interface to abstract from that. Having a JAAS backend for UserAdmin
would be nice too since that would be usable in a much broader context.
Greetings, Marcel
Re: Google Summer of Code: Marcin Wilkos
I don't think having a UserAdmin delegating to JAAS could work because
JAAS does not provide anything about modifying the underlying storage
for creating / removing users or groups. UserAdmin provides such
features, so I think it has to be to other way around: it should be
quite easy to implement a JAAS login module that delegates to
UserAdmin.
Given I don't think requiring JAAS is a good idea, that's why I
proposed such a simple API.
I don't really see any drawback to such a pluggable mechanism, as I
think it can be implemented for both JAAS and UserAdmin in a few lines
of code:
public class UserAdminProvider implements WebConsoleSecurityProvider {
private UserAdmin userAdmin;
private String userProperty;
private String credProperty;
public class UserAdminProvider(UserAdmin userAdmin, String
userProperty, String credProperty) {
this.userAdmin = userAdmin;
this.userProperty = userProperty;
this.credProperty = credProperty;
}
public Object authenticate(String username, Object credential)
throws SecurityException {
User user = userAdmin.getUser(userProperty, userName);
if (user == null) throw new SecurityException(No such user);
if (!user.hasCredential(credProperty, credential)) throw new
SecurityException(Bad credential);
return user;
}
public void authorize(Object user, String role) throws SecurityException {
Authorization auth = userAdmin.getAuthorization((User) user);
if (!auth.hasRole(role)) throw new SecurityException(Not authorized);
}
}
public class JAASProvider implements WebConsoleSecurityProvider {
private String domain;
public JAASProvider(String domain) {
this.domain = domain;
}
public Object authenticate(String username, Object credential)
throws SecurityException {
Subject subject = new Subject();
LoginContext loginContext = new LoginContext(domain, subject,
new CallbackHandler() {
public void handle(Callback[] callbacks) throws
IOException, UnsupportedCallbackException {
for (int i = 0; i callbacks.length; i++) {
if (callbacks[i] instanceof NameCallback) {
((NameCallback) callbacks[i]).setName(username);
} else if (callbacks[i] instanceof
PasswordCallback credentials instanceof String) {
((PasswordCallback)
callbacks[i]).setPassword(((String) credential).toCharArray());
} else if (callbacks[i] instanceof
CertificateCallback credentials instanceof X509Certificate) {
((CertificateCallback)
callbacks[i]).setCertificate((X509Certificate) credential);
} else {
throw new UnsupportedCallbackException(callbacks[i]);
}
}
}
});
loginContext.login();
return subject;
}
public void authorize(Object user, String role) throws SecurityException {
if (!((Subject) user).getPrincipals().contains(new
GroupPrincipal(role))) throw new SecurityException(Not authorized);
}
}
Pluggability / extensibility is always a good thing imho, as long as
it's not overengineered, which is not the case here imho.
On Wed, May 27, 2009 at 11:31, Marcel Offermans
marcel.offerm...@luminis.nl wrote:
Hello Guillaume,
On May 27, 2009, at 11:20 , Guillaume Nodet wrote:
Right, I think there is a real need to support UserAdmin, but given
both JAAS and UserAdmin will be used for the same thing, it should be
easy to support both using a simple interface:
public interface WebConsoleSecurityProvider {
/** Check if the user with the specified password exists and
return an object identifying the user, else throw an exception */
public Object authenticate(String username, String password)
throws SecurityException;
/** Check that the authenticated user has the given role
permission or throw an exception */
public void authorize(Object user, String role) throws
SecurityException;
}
Imho, this should be sufficient to provide authentication and
authorization for the web console and can be easily implemented using
UserAdmin or JAAS.
To be honest, UserAdmin already is an interface which abstracts from an
implementation, so I don't really see a need to add another interface to
abstract from that. Having a JAAS backend for UserAdmin would be nice too
since that would be usable in a much broader context.
Greetings, Marcel
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
L.S., From now on, you can expect a weekly report on the mailing lists from Marcin about his progress (as well as probably a lot of other mails with questions/remarks/... ;)). You can also follow his work on http://twitter.com/mwilkos Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/26 Gert Vanthienen gert.vanthie...@gmail.com: L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. We would definitely consider building this on top the Felix Web Console. It already has some of the functionality we're looking for and it already is extensible -- there some information on the Felix website [2] and I know the Sling project has built some extensions to the console, so we can find a code example there. Is there any other information around for this? Are there any limitations we have to be aware of before starting the project? I guess we already know about one such limitation: Apache Felix Karaf has the ability to 'rebrand' the text console with another ASCII art logo and header, so we would want that for the web console as well. As far as I can see, this is not yet supported by the Felix Web Console. Are there any plans to support that? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ [1] http://www.nabble.com/%22Web-based-management-console-for-ServiceMix%22-proposal-for-Google--Summer-of-Code-2009-td22967846ef12049.html#a22967846 [2] http://felix.apache.org/site/apache-felix-web-console.html
Re: Google Summer of Code: Marcin Wilkos
Hi,
While I would argue along the same lines as Marcel, your proposal is
quote appealing ...
So, as much as I would probably prefer to reuse existing API (namely
UserAdmin), for then purpose of the WebConsole this might be sufficient.
Regards
Felix
Guillaume Nodet schrieb:
I don't think having a UserAdmin delegating to JAAS could work because
JAAS does not provide anything about modifying the underlying storage
for creating / removing users or groups. UserAdmin provides such
features, so I think it has to be to other way around: it should be
quite easy to implement a JAAS login module that delegates to
UserAdmin.
Given I don't think requiring JAAS is a good idea, that's why I
proposed such a simple API.
I don't really see any drawback to such a pluggable mechanism, as I
think it can be implemented for both JAAS and UserAdmin in a few lines
of code:
public class UserAdminProvider implements WebConsoleSecurityProvider {
private UserAdmin userAdmin;
private String userProperty;
private String credProperty;
public class UserAdminProvider(UserAdmin userAdmin, String
userProperty, String credProperty) {
this.userAdmin = userAdmin;
this.userProperty = userProperty;
this.credProperty = credProperty;
}
public Object authenticate(String username, Object credential)
throws SecurityException {
User user = userAdmin.getUser(userProperty, userName);
if (user == null) throw new SecurityException(No such user);
if (!user.hasCredential(credProperty, credential)) throw new
SecurityException(Bad credential);
return user;
}
public void authorize(Object user, String role) throws SecurityException {
Authorization auth = userAdmin.getAuthorization((User) user);
if (!auth.hasRole(role)) throw new SecurityException(Not authorized);
}
}
public class JAASProvider implements WebConsoleSecurityProvider {
private String domain;
public JAASProvider(String domain) {
this.domain = domain;
}
public Object authenticate(String username, Object credential)
throws SecurityException {
Subject subject = new Subject();
LoginContext loginContext = new LoginContext(domain, subject,
new CallbackHandler() {
public void handle(Callback[] callbacks) throws
IOException, UnsupportedCallbackException {
for (int i = 0; i callbacks.length; i++) {
if (callbacks[i] instanceof NameCallback) {
((NameCallback) callbacks[i]).setName(username);
} else if (callbacks[i] instanceof
PasswordCallback credentials instanceof String) {
((PasswordCallback)
callbacks[i]).setPassword(((String) credential).toCharArray());
} else if (callbacks[i] instanceof
CertificateCallback credentials instanceof X509Certificate) {
((CertificateCallback)
callbacks[i]).setCertificate((X509Certificate) credential);
} else {
throw new UnsupportedCallbackException(callbacks[i]);
}
}
}
});
loginContext.login();
return subject;
}
public void authorize(Object user, String role) throws SecurityException {
if (!((Subject) user).getPrincipals().contains(new
GroupPrincipal(role))) throw new SecurityException(Not authorized);
}
}
Pluggability / extensibility is always a good thing imho, as long as
it's not overengineered, which is not the case here imho.
On Wed, May 27, 2009 at 11:31, Marcel Offermans
marcel.offerm...@luminis.nl wrote:
Hello Guillaume,
On May 27, 2009, at 11:20 , Guillaume Nodet wrote:
Right, I think there is a real need to support UserAdmin, but given
both JAAS and UserAdmin will be used for the same thing, it should be
easy to support both using a simple interface:
public interface WebConsoleSecurityProvider {
/** Check if the user with the specified password exists and
return an object identifying the user, else throw an exception */
public Object authenticate(String username, String password)
throws SecurityException;
/** Check that the authenticated user has the given role
permission or throw an exception */
public void authorize(Object user, String role) throws
SecurityException;
}
Imho, this should be sufficient to provide authentication and
authorization for the web console and can be easily implemented using
UserAdmin or JAAS.
To be honest, UserAdmin already is an interface which abstracts from an
implementation, so I don't really see a need to add another interface to
abstract from that. Having a JAAS backend for UserAdmin would be nice too
since that would be usable in a much broader context.
Greetings, Marcel
Google Summer of Code: Marcin Wilkos
L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. We would definitely consider building this on top the Felix Web Console. It already has some of the functionality we're looking for and it already is extensible -- there some information on the Felix website [2] and I know the Sling project has built some extensions to the console, so we can find a code example there. Is there any other information around for this? Are there any limitations we have to be aware of before starting the project? I guess we already know about one such limitation: Apache Felix Karaf has the ability to 'rebrand' the text console with another ASCII art logo and header, so we would want that for the web console as well. As far as I can see, this is not yet supported by the Felix Web Console. Are there any plans to support that? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ [1] http://www.nabble.com/%22Web-based-management-console-for-ServiceMix%22-proposal-for-Google--Summer-of-Code-2009-td22967846ef12049.html#a22967846 [2] http://felix.apache.org/site/apache-felix-web-console.html
Re: Google Summer of Code: Marcin Wilkos
I think I've seen a JIRA about the ability to change the stylesheet of the console, so it seems like an already envisioned enhancement to the console. I haven't dived to much into the code, so I'm not sure how all non-html resources are loaded. We need to find a mechanism to to allow someone to override those resources. Maybe we can use the same as we did for rebranding karaf: use an optional import package which will be used if present, else default to the other resources. This package has to be exported by the branding bundle. On Tue, May 26, 2009 at 08:11, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. We would definitely consider building this on top the Felix Web Console. It already has some of the functionality we're looking for and it already is extensible -- there some information on the Felix website [2] and I know the Sling project has built some extensions to the console, so we can find a code example there. Is there any other information around for this? Are there any limitations we have to be aware of before starting the project? I guess we already know about one such limitation: Apache Felix Karaf has the ability to 'rebrand' the text console with another ASCII art logo and header, so we would want that for the web console as well. As far as I can see, this is not yet supported by the Felix Web Console. Are there any plans to support that? Regards, Gert Vanthienen Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ [1] http://www.nabble.com/%22Web-based-management-console-for-ServiceMix%22-proposal-for-Google--Summer-of-Code-2009-td22967846ef12049.html#a22967846 [2] http://felix.apache.org/site/apache-felix-web-console.html -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Google Summer of Code: Marcin Wilkos
Filippo Diotalevi wrote: On Tue, May 26, 2009 at 8:11 AM, Gert Vanthienen gert.vanthie...@gmail.com wrote: L.S., Marcin Wilkos will start coding on his Google Summer of Code project this week after spending the last few weeks on getting to know the projects a bit better. The goal of the project is to build an extensible web-based management console for Apache Felix Karaf and ServiceMix 4. We've had a very short discussion on the ServiceMix dev list in April [1], but we would like to continue working on the Felix dev list for now, as most of the work will be targeted at Felix Karaf anyway. That's very interesting. I think some starting points might be http://issues.apache.org/jira/browse/FELIX-1013 (umbrella issue for web console extensibility) http://issues.apache.org/jira/browse/FELIX-1051 (localization support) We had some discussions on this topic, but never really got to the point to implement it (just because of lack of time :) ). I've been thinking about this lately and I'm more and more thinking about not using an optional import. Rebranding something is usely meant that it stays rebranded, like if you want to bundle the web console with your own product. It is too easy to uninstall the optional bundle. So I think we need a safer way. We also had the discussion (and I think there is a jira issue for this as well), to configure which configuration tabs are available - you might not want to use the tab for the config admin which comes with the web console - or you want to disable the obr tab etc. Again this could be done with some configuration and/or optional importants but can be easily overriden which is not what you want. So to keep the long story short, I'm more in favour of customization at build time, you create your project, which depends on the web console and it just adds additional files, overwrites configs (whatever) and creates your web console bundle. Maybe there is a better way inbetween those two solutions? Btw, I also think that we should secure the web console and check the role of the current user for authorization purposes. Carsten -- Carsten Ziegeler cziege...@apache.org
