[jira] Updated: (FELIX-1211) How to provide resources like CSS or JavaScript files for plugins
[ https://issues.apache.org/jira/browse/FELIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-1211: - Component/s: Web Console Affects Version/s: webconsole-1.2.10 > How to provide resources like CSS or JavaScript files for plugins > - > > Key: FELIX-1211 > URL: https://issues.apache.org/jira/browse/FELIX-1211 > Project: Felix > Issue Type: Sub-task > Components: Web Console >Affects Versions: webconsole-1.2.10 >Reporter: Felix Meschberger > Attachments: FELIX-1211-getResource.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1211) How to provide resources like CSS or JavaScript files for plugins
[ https://issues.apache.org/jira/browse/FELIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-1211: - Attachment: FELIX-1211-getResource.patch Untested patch implementing option 2b in the AbstractWebConsolePlugin. This might possible be needed to be refined for FELIX-1043. > How to provide resources like CSS or JavaScript files for plugins > - > > Key: FELIX-1211 > URL: https://issues.apache.org/jira/browse/FELIX-1211 > Project: Felix > Issue Type: Sub-task > Components: Web Console >Affects Versions: webconsole-1.2.10 >Reporter: Felix Meschberger > Attachments: FELIX-1211-getResource.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1211) How to provide resources like CSS or JavaScript files for plugins
[ https://issues.apache.org/jira/browse/FELIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717951#action_12717951 ] Felix Meschberger commented on FELIX-1211: -- The Web Console bundle itself registers a path with the OSGi HttpService as resources. This makes it easy to supply resources, since the Web Console just has to provide an URL to the resource, while the HttpService itself spools the resource with the correct response headers to the client. For plugins various options exist: (1) Plugins register resources with HttpService I am not sure, whether it is a good idea to create dependencies on the HttpService for web console plugins (2) The plugins spool the resource themselves This option is implemented by the Apache Sling Commons MIME console plugin in the MimeTypeWebConsolePlugin [1] class. This plugin overwrites the doGet method and checks whether the request is for a "/res/*" resource below the plugins own page. (2a) Approach (2) could be enhanced by abstracting the spoolResource method into the AbstractWebConsolePlugin and define a new abstract getResource method, which returns an URL to a resource, should the request address an URL. This method would be implemented in the AbstractWebConsolePlugin extension (2b) The drawback of approach (2a) is, that it requires a plugin to extend the AbstractWebConsolePlugin to provide resources. Going in the direction of the Declarative Services specification, the web console looks for a "URL getResource(String)" method in the plugin class (and its ancestor classes) to call to resolve resources. This would allow for automatic support for resources. The method must be public or protected, but may be private if it is declared in the plugin class itself. (3) Plugin lists resource paths in Manifest The bundle manifest of the plugin could provide a manifest header listing resource-paths. The Web Console would then use the providing bundle to access resources. The drawback of this approach is, that it detaches the plugin from the resource it needs. In light of FELIX-1043 (not requiring to extend AbstractWebConsolePlugin to extend the web console) I prefer approach 2b. [1] https://svn.apache.org/repos/asf/incubator/sling/trunk/bundles/commons/mime/src/main/java/org/apache/sling/commons/mime/internal/MimeTypeWebConsolePlugin.java > How to provide resources like CSS or JavaScript files for plugins > - > > Key: FELIX-1211 > URL: https://issues.apache.org/jira/browse/FELIX-1211 > Project: Felix > Issue Type: Sub-task >Reporter: Felix Meschberger > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OSGi 4.2 (was Re: [Karaf] Switching to blueprint ...)
Yeah, I missed the fact that the framework export the osgi bundles, so that bnd actually put those in the jar. However, I've just spotted that a wrong version of the tracker package is used. We still point to the old version instead of including the new BundleTracker stuff. On Wed, Jun 10, 2009 at 01:12, Richard S. Hall wrote: > On 6/9/09 5:45 PM, Guillaume Nodet wrote: >> >> I heard that for the compendium spec. But iirc, the idea was to >> include each part of the spec in the implementation bundle. >> What about doing the same for core ? i.e. include the core osgi api >> inside the framework jar. That would remove some potential problem >> where user need to find the corresponding version of the api somewhere >> else ... >> > > Yep. > > We do embed the OSGi API needed by the framework (+ service tracker) into > the framework JAR. We will continue to do this. I just mean there will be no > separate OSGi JARs released by us anymore...and we likely can delete the > source from our repo if the official JARs are put into a maven repo some > place. > > -> richard > >> On Tue, Jun 9, 2009 at 23:13, Richard S. Hall >> wrote: >> >>> >>> On 6/9/09 4:52 PM, Guillaume Nodet wrote: >>> The only dependency is on the ServiceException which is part of 4.2. I guess we can use a snapshot of the osgi api for now. Btw, is there any location where such snapshots are deployed ? I haven't found any recent build on http://people.apache.org/repo/m2-snapshot-repository >>> >>> We don't plan on publishing the OSGi APIs any more, nor am I aware of >>> anyone >>> who does. The R4.2 JAR should go final and be made public any day now, so >>> we >>> won't have to wait too long and then someone can put it in a repo some >>> place. >>> >>> Regarding the ServiceException, that is in trunk now. >>> >>> -> richard >>> >>> On Tue, Jun 9, 2009 at 22:24, Richard S. Hall wrote: > > On 6/9/09 4:11 PM, Guillaume Nodet wrote: > > >> >> I'm maintaing locally a git branch of karaf which uses blueprint >> instead of spring-dm. The blueprint implementation is a bit more >> mature / stable now and I think it would be a good idea to switch. >> That said, we should also provide a feature to allow spring-dm powered >> bundles to be deployed. There are still a couple of things to do (fix >> the integration tests, display back spring-dm bundles in osgi/list >> command if spring-dm is installed), but my branch does not seem too >> broken. >> >> The only drawback I can see is that blueprint will depend on OSGi 4.2 >> (the current implementation has hacked the only dep on 4.2 so that it >> can run on the latest felix release). I've seen the api has been >> updated, so maybe we can depend on a felix snapshot for now. >> >> >> > > What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 > API > as you've already noticed, so this shouldn't be an issue, but if you > need > something specific implemented, we should try to coordinate that... > > -> richard > > >> >> So i'd like to commit the changes I have locally to avoid doing that >> in the dark for too long a time. Thoughts ? >> >> On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet >> wrote: >> >> >> >>> >>> The past days, I've been working on the blueprint implementation >>> inside Geronimo [1]. >>> The spec is still being written so the implementation is not really >>> stable and is still missing a lot of features. >>> However, it's already somewhat usable and as I've hacked Karaf to >>> start using blueprint instead of spring-dm in a branch [2]. >>> Tests do not even compile, but I've been able to start the console, >>> so >>> I thought I would talk about it a bit. >>> >>> This raises the question whether we want to switch to blueprint >>> instead of spring-dm. >>> I think we should, and even have to, given that Spring-DM will >>> switch >>> to support Blueprint at some point in the future too. Also the >>> blueprint spec is way better than spring-dm wrt to namespace handlers >>> (that are considered dependencies, so we would not have problems with >>> namespace handlers not being available when a bundle is started) and >>> classloading (i think classes loaded for namespace handlers will be >>> loaded from the namespace handler bundle, thus freeing the bundle to >>> import all the namespace handlers packages), though those areas are >>> in >>> flux. >>> >>> If so, we might even want to do that before renaming the packages, as >>> the patch is quite big and would be quite broken after the rename >>> imho >>> ... >>> >>> As for tests, we'd have to switch to something else, which could be >>> junit4osgi from iPojo or pax-exam for example.
[jira] Created: (FELIX-1211) How to provide resources like CSS or JavaScript files for plugins
How to provide resources like CSS or JavaScript files for plugins - Key: FELIX-1211 URL: https://issues.apache.org/jira/browse/FELIX-1211 Project: Felix Issue Type: Sub-task Reporter: Felix Meschberger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
[jira] Updated: (FELIX-1171) Enhance Configuration Status Page
[ https://issues.apache.org/jira/browse/FELIX-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-1171: - Attachment: tabbed_configuration_status.png Another option is to display the different sections of the Configuration Printer in tabbed panel (see attached image). > Enhance Configuration Status Page > - > > Key: FELIX-1171 > URL: https://issues.apache.org/jira/browse/FELIX-1171 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-1.2.10 >Reporter: Felix Meschberger > Fix For: webconsole-1.2.12 > > Attachments: tabbed_configuration_status.png > > > Currently the Configuration Status Page of the web console just lists all > information as is. This causes the table to get enlarged. Rather the output > should be drawn in a frame with its own scrollbar (maybe). > In addition support should be added to download the status information as a > file to make it easier to supply the information to support personel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why reference: scheme is supported only for file URLs?
Stuart McCulloch wrote: 2009/6/8 Sahoo Stuart McCulloch wrote: 2009/6/8 Sahoo Stuart McCulloch wrote: I guess I'm not seeing why you want to use the reference: scheme with non-file URLs? do you just want to avoid copying the remote content locally or is there another reason? Good question. I want to modify the content as it is read. e.g., I want to process the MANIFEST.MF by having my own URL handler for a custom protocol. All these work as long as I don't use reference scheme. Ah, ok - I think I understand now. You want to have "reference:" in the URL and have Felix ignore it for non-"file:" schemes. Not really. hmm, well at the moment it throws an exception which I doubt you want ;) but seriously the only alternative is to log a message and treat it as a non-reference URL (see below) I think exception is a better choice (as is the current case) when reference semantics can't be supported. So, I am OK if there is no change made. See below for a description of my use case. ie. log a warning / info / debug and continue as if the URL was not a "reference:" instead of throwing an exception as it currently does. I just want Felix to read the content off the JarInputStream when it encounters a non-file URL after reference:. Is there a reason why Felix must copy? Is performance the reason? yes - as Richard pointed out we need access to the file, remotely querying a jar over the network is very slow compared to copying it and querying locally What if the custom url handler is already backed by a JarFile object? problem is we have no way of knowing that - we'd have to repeatedly query through the handler, which could also be slow Let's put it this way. How can we have directory deployment of bundles with support for content filtering? isn't this what the various OPS4J URL handlers do? they let you install and auto-wrap jars into bundles, etc. as you say everything works when you don't have "reference:" in front of your custom URLs, so what's the benefit that you expect to gain from adding it? What I wanted to do was directory deployment with MANIFEST.MF replacement. So, it involved both reference: scheme (for directory deployment) and my custom webbundle: scheme (for MANIFEST .MF processing). The reason for directory deployment was to allow users to change JSP pages in the source directory and see the effect immediately next time when they accessed the JSP over the web. Without directory deployment, they would have had to package the changed JSPs and update the bundle. Since, this is all happening in the development environment, I feel performance is not a big concern here. Plus, network is actually not involved here. I am fine if this is not considered a valid use case. Thanks, Sahoo
[jira] Created: (FELIX-1210) Allow jars with missing intermediate entries to be handled as if they were present in Bundle.getEntryPaths
Allow jars with missing intermediate entries to be handled as if they were present in Bundle.getEntryPaths -- Key: FELIX-1210 URL: https://issues.apache.org/jira/browse/FELIX-1210 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: felix-1.8.0 Environment: generic Reporter: Sahoo Fix For: felix-2.0.0 Refer to the entire discussion in users alias: http://markmail.org/message/hd6wp7c6agadr6al?q=how+to+iterate+entries+sahoo I think it will be good if Felix could tolerate the broken jar and return the entries just like KF and Equinox does, otherwise there is no way to iterate over all the entries of such a jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Karaf] Switching to blueprint ...
On 6/9/09 5:45 PM, Guillaume Nodet wrote: I heard that for the compendium spec. But iirc, the idea was to include each part of the spec in the implementation bundle. What about doing the same for core ? i.e. include the core osgi api inside the framework jar. That would remove some potential problem where user need to find the corresponding version of the api somewhere else ... Yep. We do embed the OSGi API needed by the framework (+ service tracker) into the framework JAR. We will continue to do this. I just mean there will be no separate OSGi JARs released by us anymore...and we likely can delete the source from our repo if the official JARs are put into a maven repo some place. -> richard On Tue, Jun 9, 2009 at 23:13, Richard S. Hall wrote: On 6/9/09 4:52 PM, Guillaume Nodet wrote: The only dependency is on the ServiceException which is part of 4.2. I guess we can use a snapshot of the osgi api for now. Btw, is there any location where such snapshots are deployed ? I haven't found any recent build on http://people.apache.org/repo/m2-snapshot-repository We don't plan on publishing the OSGi APIs any more, nor am I aware of anyone who does. The R4.2 JAR should go final and be made public any day now, so we won't have to wait too long and then someone can put it in a repo some place. Regarding the ServiceException, that is in trunk now. -> richard On Tue, Jun 9, 2009 at 22:24, Richard S. Hall wrote: On 6/9/09 4:11 PM, Guillaume Nodet wrote: I'm maintaing locally a git branch of karaf which uses blueprint instead of spring-dm. The blueprint implementation is a bit more mature / stable now and I think it would be a good idea to switch. That said, we should also provide a feature to allow spring-dm powered bundles to be deployed. There are still a couple of things to do (fix the integration tests, display back spring-dm bundles in osgi/list command if spring-dm is installed), but my branch does not seem too broken. The only drawback I can see is that blueprint will depend on OSGi 4.2 (the current implementation has hacked the only dep on 4.2 so that it can run on the latest felix release). I've seen the api has been updated, so maybe we can depend on a felix snapshot for now. What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 API as you've already noticed, so this shouldn't be an issue, but if you need something specific implemented, we should try to coordinate that... ->richard So i'd like to commit the changes I have locally to avoid doing that in the dark for too long a time. Thoughts ? On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet wrote: The past days, I've been working on the blueprint implementation inside Geronimo [1]. The spec is still being written so the implementation is not really stable and is still missing a lot of features. However, it's already somewhat usable and as I've hacked Karaf to start using blueprint instead of spring-dm in a branch [2]. Tests do not even compile, but I've been able to start the console, so I thought I would talk about it a bit. This raises the question whether we want to switch to blueprint instead of spring-dm. I think we should, and even have to, given that Spring-DM will switch to support Blueprint at some point in the future too. Also the blueprint spec is way better than spring-dm wrt to namespace handlers (that are considered dependencies, so we would not have problems with namespace handlers not being available when a bundle is started) and classloading (i think classes loaded for namespace handlers will be loaded from the namespace handler bundle, thus freeing the bundle to import all the namespace handlers packages), though those areas are in flux. If so, we might even want to do that before renaming the packages, as the patch is quite big and would be quite broken after the rename imho ... As for tests, we'd have to switch to something else, which could be junit4osgi from iPojo or pax-exam for example. Feedback welcome. [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint [2] https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Karaf] Switching to blueprint ...
I heard that for the compendium spec. But iirc, the idea was to include each part of the spec in the implementation bundle. What about doing the same for core ? i.e. include the core osgi api inside the framework jar. That would remove some potential problem where user need to find the corresponding version of the api somewhere else ... On Tue, Jun 9, 2009 at 23:13, Richard S. Hall wrote: > On 6/9/09 4:52 PM, Guillaume Nodet wrote: >> >> The only dependency is on the ServiceException which is part of 4.2. >> I guess we can use a snapshot of the osgi api for now. >> Btw, is there any location where such snapshots are deployed ? I >> haven't found any recent build on >> http://people.apache.org/repo/m2-snapshot-repository >> > > We don't plan on publishing the OSGi APIs any more, nor am I aware of anyone > who does. The R4.2 JAR should go final and be made public any day now, so we > won't have to wait too long and then someone can put it in a repo some > place. > > Regarding the ServiceException, that is in trunk now. > > -> richard > >> On Tue, Jun 9, 2009 at 22:24, Richard S. Hall >> wrote: >> >>> >>> On 6/9/09 4:11 PM, Guillaume Nodet wrote: >>> I'm maintaing locally a git branch of karaf which uses blueprint instead of spring-dm. The blueprint implementation is a bit more mature / stable now and I think it would be a good idea to switch. That said, we should also provide a feature to allow spring-dm powered bundles to be deployed. There are still a couple of things to do (fix the integration tests, display back spring-dm bundles in osgi/list command if spring-dm is installed), but my branch does not seem too broken. The only drawback I can see is that blueprint will depend on OSGi 4.2 (the current implementation has hacked the only dep on 4.2 so that it can run on the latest felix release). I've seen the api has been updated, so maybe we can depend on a felix snapshot for now. >>> >>> What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 >>> API >>> as you've already noticed, so this shouldn't be an issue, but if you need >>> something specific implemented, we should try to coordinate that... >>> >>> -> richard >>> So i'd like to commit the changes I have locally to avoid doing that in the dark for too long a time. Thoughts ? On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet wrote: > > The past days, I've been working on the blueprint implementation > inside Geronimo [1]. > The spec is still being written so the implementation is not really > stable and is still missing a lot of features. > However, it's already somewhat usable and as I've hacked Karaf to > start using blueprint instead of spring-dm in a branch [2]. > Tests do not even compile, but I've been able to start the console, so > I thought I would talk about it a bit. > > This raises the question whether we want to switch to blueprint > instead of spring-dm. > I think we should, and even have to, given that Spring-DM will switch > to support Blueprint at some point in the future too. Also the > blueprint spec is way better than spring-dm wrt to namespace handlers > (that are considered dependencies, so we would not have problems with > namespace handlers not being available when a bundle is started) and > classloading (i think classes loaded for namespace handlers will be > loaded from the namespace handler bundle, thus freeing the bundle to > import all the namespace handlers packages), though those areas are in > flux. > > If so, we might even want to do that before renaming the packages, as > the patch is quite big and would be quite broken after the rename imho > ... > > As for tests, we'd have to switch to something else, which could be > junit4osgi from iPojo or pax-exam for example. > > Feedback welcome. > > [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint > [2] > https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ > > -- > 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: [Karaf] Switching to blueprint ...
On 6/9/09 4:52 PM, Guillaume Nodet wrote: The only dependency is on the ServiceException which is part of 4.2. I guess we can use a snapshot of the osgi api for now. Btw, is there any location where such snapshots are deployed ? I haven't found any recent build on http://people.apache.org/repo/m2-snapshot-repository We don't plan on publishing the OSGi APIs any more, nor am I aware of anyone who does. The R4.2 JAR should go final and be made public any day now, so we won't have to wait too long and then someone can put it in a repo some place. Regarding the ServiceException, that is in trunk now. -> richard On Tue, Jun 9, 2009 at 22:24, Richard S. Hall wrote: On 6/9/09 4:11 PM, Guillaume Nodet wrote: I'm maintaing locally a git branch of karaf which uses blueprint instead of spring-dm. The blueprint implementation is a bit more mature / stable now and I think it would be a good idea to switch. That said, we should also provide a feature to allow spring-dm powered bundles to be deployed. There are still a couple of things to do (fix the integration tests, display back spring-dm bundles in osgi/list command if spring-dm is installed), but my branch does not seem too broken. The only drawback I can see is that blueprint will depend on OSGi 4.2 (the current implementation has hacked the only dep on 4.2 so that it can run on the latest felix release). I've seen the api has been updated, so maybe we can depend on a felix snapshot for now. What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 API as you've already noticed, so this shouldn't be an issue, but if you need something specific implemented, we should try to coordinate that... -> richard So i'd like to commit the changes I have locally to avoid doing that in the dark for too long a time. Thoughts ? On Tue, Apr 28, 2009 at 15:45, Guillaume Nodetwrote: The past days, I've been working on the blueprint implementation inside Geronimo [1]. The spec is still being written so the implementation is not really stable and is still missing a lot of features. However, it's already somewhat usable and as I've hacked Karaf to start using blueprint instead of spring-dm in a branch [2]. Tests do not even compile, but I've been able to start the console, so I thought I would talk about it a bit. This raises the question whether we want to switch to blueprint instead of spring-dm. I think we should, and even have to, given that Spring-DM will switch to support Blueprint at some point in the future too. Also the blueprint spec is way better than spring-dm wrt to namespace handlers (that are considered dependencies, so we would not have problems with namespace handlers not being available when a bundle is started) and classloading (i think classes loaded for namespace handlers will be loaded from the namespace handler bundle, thus freeing the bundle to import all the namespace handlers packages), though those areas are in flux. If so, we might even want to do that before renaming the packages, as the patch is quite big and would be quite broken after the rename imho ... As for tests, we'd have to switch to something else, which could be junit4osgi from iPojo or pax-exam for example. Feedback welcome. [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint [2] https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Karaf] Switching to blueprint ...
The only dependency is on the ServiceException which is part of 4.2. I guess we can use a snapshot of the osgi api for now. Btw, is there any location where such snapshots are deployed ? I haven't found any recent build on http://people.apache.org/repo/m2-snapshot-repository On Tue, Jun 9, 2009 at 22:24, Richard S. Hall wrote: > > On 6/9/09 4:11 PM, Guillaume Nodet wrote: >> >> I'm maintaing locally a git branch of karaf which uses blueprint >> instead of spring-dm. The blueprint implementation is a bit more >> mature / stable now and I think it would be a good idea to switch. >> That said, we should also provide a feature to allow spring-dm powered >> bundles to be deployed. There are still a couple of things to do (fix >> the integration tests, display back spring-dm bundles in osgi/list >> command if spring-dm is installed), but my branch does not seem too >> broken. >> >> The only drawback I can see is that blueprint will depend on OSGi 4.2 >> (the current implementation has hacked the only dep on 4.2 so that it >> can run on the latest felix release). I've seen the api has been >> updated, so maybe we can depend on a felix snapshot for now. >> > > What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 API > as you've already noticed, so this shouldn't be an issue, but if you need > something specific implemented, we should try to coordinate that... > > -> richard >> >> So i'd like to commit the changes I have locally to avoid doing that >> in the dark for too long a time. Thoughts ? >> >> On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet wrote: >> >>> >>> The past days, I've been working on the blueprint implementation >>> inside Geronimo [1]. >>> The spec is still being written so the implementation is not really >>> stable and is still missing a lot of features. >>> However, it's already somewhat usable and as I've hacked Karaf to >>> start using blueprint instead of spring-dm in a branch [2]. >>> Tests do not even compile, but I've been able to start the console, so >>> I thought I would talk about it a bit. >>> >>> This raises the question whether we want to switch to blueprint >>> instead of spring-dm. >>> I think we should, and even have to, given that Spring-DM will switch >>> to support Blueprint at some point in the future too. Also the >>> blueprint spec is way better than spring-dm wrt to namespace handlers >>> (that are considered dependencies, so we would not have problems with >>> namespace handlers not being available when a bundle is started) and >>> classloading (i think classes loaded for namespace handlers will be >>> loaded from the namespace handler bundle, thus freeing the bundle to >>> import all the namespace handlers packages), though those areas are in >>> flux. >>> >>> If so, we might even want to do that before renaming the packages, as >>> the patch is quite big and would be quite broken after the rename imho >>> ... >>> >>> As for tests, we'd have to switch to something else, which could be >>> junit4osgi from iPojo or pax-exam for example. >>> >>> Feedback welcome. >>> >>> [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint >>> [2] >>> https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ >>> >>> -- >>> 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: [Karaf] Switching to blueprint ...
On 6/9/09 4:11 PM, Guillaume Nodet wrote: I'm maintaing locally a git branch of karaf which uses blueprint instead of spring-dm. The blueprint implementation is a bit more mature / stable now and I think it would be a good idea to switch. That said, we should also provide a feature to allow spring-dm powered bundles to be deployed. There are still a couple of things to do (fix the integration tests, display back spring-dm bundles in osgi/list command if spring-dm is installed), but my branch does not seem too broken. The only drawback I can see is that blueprint will depend on OSGi 4.2 (the current implementation has hacked the only dep on 4.2 so that it can run on the latest felix release). I've seen the api has been updated, so maybe we can depend on a felix snapshot for now. What 4.2 dependencies? The Felix 2.0.0 release should include the R4.2 API as you've already noticed, so this shouldn't be an issue, but if you need something specific implemented, we should try to coordinate that... -> richard So i'd like to commit the changes I have locally to avoid doing that in the dark for too long a time. Thoughts ? On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet wrote: The past days, I've been working on the blueprint implementation inside Geronimo [1]. The spec is still being written so the implementation is not really stable and is still missing a lot of features. However, it's already somewhat usable and as I've hacked Karaf to start using blueprint instead of spring-dm in a branch [2]. Tests do not even compile, but I've been able to start the console, so I thought I would talk about it a bit. This raises the question whether we want to switch to blueprint instead of spring-dm. I think we should, and even have to, given that Spring-DM will switch to support Blueprint at some point in the future too. Also the blueprint spec is way better than spring-dm wrt to namespace handlers (that are considered dependencies, so we would not have problems with namespace handlers not being available when a bundle is started) and classloading (i think classes loaded for namespace handlers will be loaded from the namespace handler bundle, thus freeing the bundle to import all the namespace handlers packages), though those areas are in flux. If so, we might even want to do that before renaming the packages, as the patch is quite big and would be quite broken after the rename imho ... As for tests, we'd have to switch to something else, which could be junit4osgi from iPojo or pax-exam for example. Feedback welcome. [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint [2] https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Karaf] Switching to blueprint ...
I'm maintaing locally a git branch of karaf which uses blueprint instead of spring-dm. The blueprint implementation is a bit more mature / stable now and I think it would be a good idea to switch. That said, we should also provide a feature to allow spring-dm powered bundles to be deployed. There are still a couple of things to do (fix the integration tests, display back spring-dm bundles in osgi/list command if spring-dm is installed), but my branch does not seem too broken. The only drawback I can see is that blueprint will depend on OSGi 4.2 (the current implementation has hacked the only dep on 4.2 so that it can run on the latest felix release). I've seen the api has been updated, so maybe we can depend on a felix snapshot for now. So i'd like to commit the changes I have locally to avoid doing that in the dark for too long a time. Thoughts ? On Tue, Apr 28, 2009 at 15:45, Guillaume Nodet wrote: > The past days, I've been working on the blueprint implementation > inside Geronimo [1]. > The spec is still being written so the implementation is not really > stable and is still missing a lot of features. > However, it's already somewhat usable and as I've hacked Karaf to > start using blueprint instead of spring-dm in a branch [2]. > Tests do not even compile, but I've been able to start the console, so > I thought I would talk about it a bit. > > This raises the question whether we want to switch to blueprint > instead of spring-dm. > I think we should, and even have to, given that Spring-DM will switch > to support Blueprint at some point in the future too. Also the > blueprint spec is way better than spring-dm wrt to namespace handlers > (that are considered dependencies, so we would not have problems with > namespace handlers not being available when a bundle is started) and > classloading (i think classes loaded for namespace handlers will be > loaded from the namespace handler bundle, thus freeing the bundle to > import all the namespace handlers packages), though those areas are in > flux. > > If so, we might even want to do that before renaming the packages, as > the patch is quite big and would be quite broken after the rename imho > ... > > As for tests, we'd have to switch to something else, which could be > junit4osgi from iPojo or pax-exam for example. > > Feedback welcome. > > [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint > [2] https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/ > > -- > 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
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 Wilkos 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, 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 : >> 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
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.ap
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
[jira] Closed: (FELIX-905) Felix needs an RFC 126 FindHook
[ https://issues.apache.org/jira/browse/FELIX-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert closed FELIX-905. -- > Felix needs an RFC 126 FindHook > --- > > Key: FELIX-905 > URL: https://issues.apache.org/jira/browse/FELIX-905 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Reporter: David Bosschaert >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > Attachments: hooks_servicefactory.patch, > rfc126_eventhook_findhook.patch > > > RFC 126 defines a FindHook that Felix needs to implement. > For more information see: > http://www.osgi.org/download/osgi-4.2-early-draft2.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-905) Felix needs an RFC 126 FindHook
[ https://issues.apache.org/jira/browse/FELIX-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717691#action_12717691 ] David Bosschaert commented on FELIX-905: Ok - makes sense. I'm happy to upgrade the test and submit a patch for it. Have created a separate JIRA for that: FELIX-1208 Also, we still need to implement ListenerHookInfo.isRemoved(). I've also added a separate JIRA for that: FELIX-1209 Closing this bug now. > Felix needs an RFC 126 FindHook > --- > > Key: FELIX-905 > URL: https://issues.apache.org/jira/browse/FELIX-905 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Reporter: David Bosschaert >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > Attachments: hooks_servicefactory.patch, > rfc126_eventhook_findhook.patch > > > RFC 126 defines a FindHook that Felix needs to implement. > For more information see: > http://www.osgi.org/download/osgi-4.2-early-draft2.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-906) Felix needs an RFC 126 EventHook
[ https://issues.apache.org/jira/browse/FELIX-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert closed FELIX-906. -- > Felix needs an RFC 126 EventHook > > > Key: FELIX-906 > URL: https://issues.apache.org/jira/browse/FELIX-906 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Reporter: David Bosschaert >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > > RFC 126 defines an EventHook that Felix needs to implement. > For more information see: > http://www.osgi.org/download/osgi-4.2-early-draft2.pdf > Note that in this document the hook is called 'PublishHook'. It has since > been renamed to EventHook. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1209) Need to implement ListenerHook.ListenerInfo.isRemoved()
Need to implement ListenerHook.ListenerInfo.isRemoved() --- Key: FELIX-1209 URL: https://issues.apache.org/jira/browse/FELIX-1209 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: felix-1.8.1 Reporter: David Bosschaert The /org.apache.felix.framework/src/main/java/org/apache/felix/framework/util/ListenerHookInfoImpl.java class currently has no implementation for the isRemoved() method. This needs to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1208) Need migrate the EventDispatcherTest to newer version of EasyMock
Need migrate the EventDispatcherTest to newer version of EasyMock - Key: FELIX-1208 URL: https://issues.apache.org/jira/browse/FELIX-1208 Project: Felix Issue Type: Test Components: Framework Affects Versions: felix-1.8.1 Reporter: David Bosschaert The following test is not compatible with the current version of EasyMock, need to update the test: http://svn.apache.org/repos/asf/felix/trunk/framework/src/test/java/org/apache/felix/framework/util/EventDispatcherTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-905) Felix needs an RFC 126 FindHook
[ https://issues.apache.org/jira/browse/FELIX-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717685#action_12717685 ] Richard S. Hall commented on FELIX-905: --- Actually, I remember what was going on here now. When we did the last release of the framework we had to delete this test case since it was not compatible with the new version of mocking library, which were changed to make things "simpler". We need a patch to bring the old test case up to speed. > Felix needs an RFC 126 FindHook > --- > > Key: FELIX-905 > URL: https://issues.apache.org/jira/browse/FELIX-905 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Reporter: David Bosschaert >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > Attachments: hooks_servicefactory.patch, > rfc126_eventhook_findhook.patch > > > RFC 126 defines a FindHook that Felix needs to implement. > For more information see: > http://www.osgi.org/download/osgi-4.2-early-draft2.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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 : > 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. >>> R
[jira] Commented: (FELIX-905) Felix needs an RFC 126 FindHook
[ https://issues.apache.org/jira/browse/FELIX-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717645#action_12717645 ] David Bosschaert commented on FELIX-905: Hi Richard, Thanks for applying the patch. Something seems to have gone wrong with the following file though: http://svn.apache.org/repos/asf/felix/trunk/framework/src/test/java/org/apache/felix/framework/util/EventDispatcherTest.java It has a size of 0 (zero). The patch contains some modifications to this file, but not the intention to wipe it out :) > Felix needs an RFC 126 FindHook > --- > > Key: FELIX-905 > URL: https://issues.apache.org/jira/browse/FELIX-905 > Project: Felix > Issue Type: Bug > Components: Framework, Specification compliance >Reporter: David Bosschaert >Assignee: Richard S. Hall > Fix For: felix-2.0.0 > > Attachments: hooks_servicefactory.patch, > rfc126_eventhook_findhook.patch > > > RFC 126 defines a FindHook that Felix needs to implement. > For more information see: > http://www.osgi.org/download/osgi-4.2-early-draft2.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why does webconsole optionally imports org.osgi.service.http?
... and fixed in trunk. Thanks for pointing out. Regards Felix Stuart McCulloch schrieb: > 2009/6/9 Sahoo > >> It is interesting to note that webconsole has an optional dependency on >> org.osgi.service.http. How can is expected to work in the absence of this >> package? The activator of webconsole bundle gets NoClassDefFoundError as >> shown below when there is no such package. >> > > the webconsole pom currently sets all OSGi services as optional imports: > >org.osgi.service.*;resolution:=optional > > because most of the services it uses are in fact optional, so it's probably > just accidental that the HTTP service gets marked as optional along with > the rest > > adding an entry for org.osgi.service.http before the wildcard without any > optional setting seems to solve this: > > Index: pom.xml > === > --- pom.xml (revision 782897) > +++ pom.xml (working copy) > @@ -86,6 +86,7 @@ > org.apache.felix.webconsole.*, > > > +org.osgi.service.http, > org.apache.felix.scr; > org.apache.felix.shell; > org.osgi.service.*;resolution:=optional, > > >> INFO: Caused by: java.lang.NoClassDefFoundError: >> org/osgi/service/http/HttpContext >> Jun 9, 2009 1:55:52 PM INFO: at >> org.apache.felix.webconsole.internal.OsgiManagerActivator.start(OsgiManagerActivator.java:35) >> Jun 9, 2009 1:55:52 PM INFO: at >> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) >> Jun 9, 2009 1:55:52 PM INFO: at >> org.apache.felix.framework.Felix.startBundle(Felix.java:1458) >> >> Thanks, >> Sahoo >> >
Re: Why does webconsole optionally imports org.osgi.service.http?
2009/6/9 Sahoo > It is interesting to note that webconsole has an optional dependency on > org.osgi.service.http. How can is expected to work in the absence of this > package? The activator of webconsole bundle gets NoClassDefFoundError as > shown below when there is no such package. > the webconsole pom currently sets all OSGi services as optional imports: org.osgi.service.*;resolution:=optional because most of the services it uses are in fact optional, so it's probably just accidental that the HTTP service gets marked as optional along with the rest adding an entry for org.osgi.service.http before the wildcard without any optional setting seems to solve this: Index: pom.xml === --- pom.xml (revision 782897) +++ pom.xml (working copy) @@ -86,6 +86,7 @@ org.apache.felix.webconsole.*, +org.osgi.service.http, org.apache.felix.scr; org.apache.felix.shell; org.osgi.service.*;resolution:=optional, > INFO: Caused by: java.lang.NoClassDefFoundError: > org/osgi/service/http/HttpContext > Jun 9, 2009 1:55:52 PM INFO: at > org.apache.felix.webconsole.internal.OsgiManagerActivator.start(OsgiManagerActivator.java:35) > Jun 9, 2009 1:55:52 PM INFO: at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) > Jun 9, 2009 1:55:52 PM INFO: at > org.apache.felix.framework.Felix.startBundle(Felix.java:1458) > > Thanks, > Sahoo > -- Cheers, Stuart
Why does webconsole optionally imports org.osgi.service.http?
It is interesting to note that webconsole has an optional dependency on org.osgi.service.http. How can is expected to work in the absence of this package? The activator of webconsole bundle gets NoClassDefFoundError as shown below when there is no such package. INFO: Caused by: java.lang.NoClassDefFoundError: org/osgi/service/http/HttpContext Jun 9, 2009 1:55:52 PM INFO: at org.apache.felix.webconsole.internal.OsgiManagerActivator.start(OsgiManagerActivator.java:35) Jun 9, 2009 1:55:52 PM INFO: at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) Jun 9, 2009 1:55:52 PM INFO: at org.apache.felix.framework.Felix.startBundle(Felix.java:1458) Thanks, Sahoo
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 >> >
