[jira] Commented: (FELIX-1703) SCR Plugin not always recognizes correctly to switch into DS 1.1 descriptor mode
[
https://issues.apache.org/jira/browse/FELIX-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762539#action_12762539
]
Felix Meschberger commented on FELIX-1703:
--
Added support to explicitly request the descriptor version on a component level
in Rev. 822151.
The @scr.component tag now takes a specVersion attribute naming the DS
specification version against which the component is written. Supported values
are 1.0 (the default if the attribute is missing) for DS 1.0 and 1.1 for DS
1.1 (OSGi R4.2).
SCR Plugin not always recognizes correctly to switch into DS 1.1 descriptor
mode
Key: FELIX-1703
URL: https://issues.apache.org/jira/browse/FELIX-1703
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.4.0
Reporter: Felix Meschberger
Fix For: maven-scr-plugin-1.4.1
Given a simple component like this:
/**
* @scr.component activate=newActivate deactivate=newDeactivate
* @scr.property name=sample value=Sample Value
*/
public class SampleComponent {
private final Logger log = LoggerFactory.getLogger(getClass());
protected void activate(Map?, ? config) {
log.info(Component {} starting, config.get(component.name));
}
protected void deactivate(Map?, ? config, int reason) {
log.info(Component {} stopping, reason: {},
config.get(component.name), reason);
}
}
The Maven SCR plugin in this case does not accept the signatures of the
activate and deactivate methods to require a DS 1.1 descriptor.
Maybe, for backwards compatibility with existing source, it is also better to
not switch into a DS 1.1 descriptor: There might be code where methods with
signatures newly supported by DS 1.1 should not be used. In this case it
would be good to be able to explicitly declare the component to be a DS 1.1
compliant component.
Currently it is not possible to specify this on a per-component level. It is
only possible per plugin configuration or by having the plugin detect a DS
1.1 feature, such as the activate or deactivate attribute to the
@scr.component tag.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1703) SCR Plugin not always recognizes correctly to switch into DS 1.1 descriptor mode
[
https://issues.apache.org/jira/browse/FELIX-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762545#action_12762545
]
Felix Meschberger commented on FELIX-1703:
--
Added support for the specVersion attribte in the @Component annotation in Rev.
822155 and 822156
As for the @scr.component tag the default value is 1.0 and supported values are
1.0 and 1.1
SCR Plugin not always recognizes correctly to switch into DS 1.1 descriptor
mode
Key: FELIX-1703
URL: https://issues.apache.org/jira/browse/FELIX-1703
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.4.0
Reporter: Felix Meschberger
Fix For: maven-scr-plugin-1.4.1
Given a simple component like this:
/**
* @scr.component activate=newActivate deactivate=newDeactivate
* @scr.property name=sample value=Sample Value
*/
public class SampleComponent {
private final Logger log = LoggerFactory.getLogger(getClass());
protected void activate(Map?, ? config) {
log.info(Component {} starting, config.get(component.name));
}
protected void deactivate(Map?, ? config, int reason) {
log.info(Component {} stopping, reason: {},
config.get(component.name), reason);
}
}
The Maven SCR plugin in this case does not accept the signatures of the
activate and deactivate methods to require a DS 1.1 descriptor.
Maybe, for backwards compatibility with existing source, it is also better to
not switch into a DS 1.1 descriptor: There might be code where methods with
signatures newly supported by DS 1.1 should not be used. In this case it
would be good to be able to explicitly declare the component to be a DS 1.1
compliant component.
Currently it is not possible to specify this on a per-component level. It is
only possible per plugin configuration or by having the plugin detect a DS
1.1 feature, such as the activate or deactivate attribute to the
@scr.component tag.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (FELIX-1708) Improve error reporting
[ https://issues.apache.org/jira/browse/FELIX-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-1708 started by Felix Meschberger. Improve error reporting --- Key: FELIX-1708 URL: https://issues.apache.org/jira/browse/FELIX-1708 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.4.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: maven-scr-plugin-1.4.1 Currently error reporting in the Maven SCR Plugin is rather straightforward supporting only string messages. Now, that the SCR Plugin can be used outside of the Maven scope where more functionality may be provided, a more detailed error reporting mechanism might make sense. Specifically, support for providing three part messages (source, line number, message) would be very helpfull in certain situations and would also allow for a more standardized log formatting in the maven case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1708) Improve error reporting
Improve error reporting --- Key: FELIX-1708 URL: https://issues.apache.org/jira/browse/FELIX-1708 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.4.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: maven-scr-plugin-1.4.1 Currently error reporting in the Maven SCR Plugin is rather straightforward supporting only string messages. Now, that the SCR Plugin can be used outside of the Maven scope where more functionality may be provided, a more detailed error reporting mechanism might make sense. Specifically, support for providing three part messages (source, line number, message) would be very helpfull in certain situations and would also allow for a more standardized log formatting in the maven case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1709) Bring back the maven archetype for creating commands
Bring back the maven archetype for creating commands Key: FELIX-1709 URL: https://issues.apache.org/jira/browse/FELIX-1709 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf-1.0.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Karaf features + Sigil launch
Hi there, I'm currently looking into how to set up a launch configuration for Sigil development in the IDE and one idea that seems quite attractive is to reuse the Karaf features format to list the bundles that the user wishes to install in the framework. The use case I'm looking to solve is initial boot of an OSGi framework from the IDE with a pre configured set of bundles. Once the framework is running it will be possible to install and uninstall individual bundles via the IDE to allow for update of classes during debug. But this initial step allows us to boot a framework into a known state. Some areas that I'm a little hazy about... * Editor support for features files - is there any available plugins for Eclipse in this area? * Extensions to the karaf format to support sigil projects (ivy dependencies?) * Support for Karaf features from a remote process - how tied is the org/apache/felix/karaf/features/*.java code to a local framework? I think it makes sense drive this from an external process vs installing Karaf in the framework as this would allow us to debug Karaf. This would involve having a Karaf driver in the IDE that understands the Karaf features file format and uses it to make install and start commands into the external framework process. The other idea that sprang to mind was the pax runner profile format. Can anyone comment on the relative pros and cons of each format? Regards, Dave
Re: Karaf features + Sigil launch
I do not want to compare the two formats so here fact about the profile format: * profile format is the format that can be scanned by a composite scanner (scan-composite:). Here is some more documentation: http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning * it can include any other provisioning specs so you can scan from karaf features, simple text files containing bundles urls, maven poms, directories containing bundles, zips containing jars, any bundle referenced by url. * it can include references to another composite scanners. * there are a bunch of such files in Pax Runner repository: http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list ( https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/ ) * the whole functionality about using this scanners is extracted out of pax runner into pax scanner project Now related to the part where you launch an osgi framework you may want to take a look at pax runner eclipse plugin that allows you to start any OSS framework / any version and we can discuss about any features you may need. About install/update/uninstall bundles in the external running framework you may want to look at Pax Exam RBC (remote bundle context) that we use it to allow the install/uninstall of bundles from outside of the process (RMI) + allows to make calls to services in the remote process. Again, if any special needs, let me know. About ivy is just a matter (I think) of implementing an url handler as we did for maven. Actually we have an issue there to support it but yet there was not requested. HTH On Tue, Oct 6, 2009 at 11:20 AM, David Savage david.sav...@paremus.comwrote: Hi there, I'm currently looking into how to set up a launch configuration for Sigil development in the IDE and one idea that seems quite attractive is to reuse the Karaf features format to list the bundles that the user wishes to install in the framework. The use case I'm looking to solve is initial boot of an OSGi framework from the IDE with a pre configured set of bundles. Once the framework is running it will be possible to install and uninstall individual bundles via the IDE to allow for update of classes during debug. But this initial step allows us to boot a framework into a known state. Some areas that I'm a little hazy about... * Editor support for features files - is there any available plugins for Eclipse in this area? * Extensions to the karaf format to support sigil projects (ivy dependencies?) * Support for Karaf features from a remote process - how tied is the org/apache/felix/karaf/features/*.java code to a local framework? I think it makes sense drive this from an external process vs installing Karaf in the framework as this would allow us to debug Karaf. This would involve having a Karaf driver in the IDE that understands the Karaf features file format and uses it to make install and start commands into the external framework process. The other idea that sprang to mind was the pax runner profile format. Can anyone comment on the relative pros and cons of each format? Regards, Dave -- Alin Dreghiciu Software Developer My profile: http://www.linkedin.com/in/alindreghiciu My blog: http://adreghiciu.blogspot.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: Karaf features + Sigil launch
On Tue, Oct 6, 2009 at 10:27 AM, Alin Dreghiciu adreghi...@gmail.com wrote: I do not want to compare the two formats so here fact about the profile Fair enough, yep I realized just after I sent my mail this could be asking for trouble - that is not my intention just to figure out what is the best way to achieve this. format: * profile format is the format that can be scanned by a composite scanner (scan-composite:). Here is some more documentation: http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning * it can include any other provisioning specs so you can scan from karaf features, simple text files containing bundles urls, maven poms, directories containing bundles, zips containing jars, any bundle referenced by url. * it can include references to another composite scanners. * there are a bunch of such files in Pax Runner repository: http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list ( https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/ ) * the whole functionality about using this scanners is extracted out of pax runner into pax scanner project Does the scanner run in the framework process? I think for isolation reasons it make sense to make the framework a very thin client with very few dependencies installed, this ensures that when you debug you're actually debugging your code and not some accidental collision with pre resolved bundles in the framework. Consider the case where you'd want to debug pax scanner for example? Or more likely some other application that happens to share dependencies with pax-scanner and you want to ensure you're debugging precisely your set of bundle dependencies. Now related to the part where you launch an osgi framework you may want to take a look at pax runner eclipse plugin that allows you to start any OSS framework / any version and we can discuss about any features you may need. I'll take a look, that's basically what I'm trying to write a gui for at the moment - but I would love not to have to reinvent this particular wheel as it involves a lot of GUI code that I can do but always feels a little like pulling teeth ;) About install/update/uninstall bundles in the external running framework you may want to look at Pax Exam RBC (remote bundle context) that we use it to allow the install/uninstall of bundles from outside of the process (RMI) + allows to make calls to services in the remote process. Again, if any special needs, let me know. That sounds similar to something I've started here too i.e. a launcher for Sigil that uses a socket based approach to control the framework remotely: http://svn.apache.org/viewvc/felix/trunk/sigil/common/runtime/src/org/apache/felix/sigil/common/runtime/Client.java?view=markup The point about using sockets was to again reduce the dependencies on the framework to a minimum. This does seem to have some overlap with the pax exam functionality. Maybe there's some mileage in coming up with a common model for this? About ivy is just a matter (I think) of implementing an url handler as we did for maven. Actually we have an issue there to support it but yet there was not requested. As per other comments - does this imply the url handler is installed in the remote framework? Thx for the info. Regards, Dave HTH On Tue, Oct 6, 2009 at 11:20 AM, David Savage david.sav...@paremus.comwrote: Hi there, I'm currently looking into how to set up a launch configuration for Sigil development in the IDE and one idea that seems quite attractive is to reuse the Karaf features format to list the bundles that the user wishes to install in the framework. The use case I'm looking to solve is initial boot of an OSGi framework from the IDE with a pre configured set of bundles. Once the framework is running it will be possible to install and uninstall individual bundles via the IDE to allow for update of classes during debug. But this initial step allows us to boot a framework into a known state. Some areas that I'm a little hazy about... * Editor support for features files - is there any available plugins for Eclipse in this area? * Extensions to the karaf format to support sigil projects (ivy dependencies?) * Support for Karaf features from a remote process - how tied is the org/apache/felix/karaf/features/*.java code to a local framework? I think it makes sense drive this from an external process vs installing Karaf in the framework as this would allow us to debug Karaf. This would involve having a Karaf driver in the IDE that understands the Karaf features file format and uses it to make install and start commands into the external framework process. The other idea that sprang to mind was the pax runner profile format. Can anyone comment on the relative pros and cons of each format? Regards, Dave -- Alin Dreghiciu Software Developer My profile: http://www.linkedin.com/in/alindreghiciu My blog:
[jira] Created: (FELIX-1710) Resolver still does not always discard partial results when a cyclically dependency fails
Resolver still does not always discard partial results when a cyclically dependency fails - Key: FELIX-1710 URL: https://issues.apache.org/jira/browse/FELIX-1710 Project: Felix Issue Type: Bug Components: Framework, Specification compliance Affects Versions: felix-2.0.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-2.2.0 There are still situations were failed cyclical dependencies are not completely cleaned up, which leads to bundles being considered to be resolved when in fact they are not. The previous fix for this did not go far enough since it only cleaned immediately cyclical dependencies. Instead, it must removed failed candidates from any modules using them as a potential candidate, which could also cause those modules to fail to resolve if that was the only potential candidate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1710) Resolver still does not discard all partial results when a cyclical dependency fails
[ https://issues.apache.org/jira/browse/FELIX-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1710: --- Summary: Resolver still does not discard all partial results when a cyclical dependency fails (was: Resolver still does not discard all partial results when a cyclically dependency fails) Resolver still does not discard all partial results when a cyclical dependency fails Key: FELIX-1710 URL: https://issues.apache.org/jira/browse/FELIX-1710 Project: Felix Issue Type: Bug Components: Framework, Specification compliance Affects Versions: felix-2.0.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-2.2.0 There are still situations were failed cyclical dependencies are not completely cleaned up, which leads to bundles being considered to be resolved when in fact they are not. The previous fix for this did not go far enough since it only cleaned immediately cyclical dependencies. Instead, it must removed failed candidates from any modules using them as a potential candidate, which could also cause those modules to fail to resolve if that was the only potential candidate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1710) Resolver still does not discard all partial results when a cyclically dependency fails
[ https://issues.apache.org/jira/browse/FELIX-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1710: --- Summary: Resolver still does not discard all partial results when a cyclically dependency fails (was: Resolver still does not always discard partial results when a cyclically dependency fails) Resolver still does not discard all partial results when a cyclically dependency fails -- Key: FELIX-1710 URL: https://issues.apache.org/jira/browse/FELIX-1710 Project: Felix Issue Type: Bug Components: Framework, Specification compliance Affects Versions: felix-2.0.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: felix-2.2.0 There are still situations were failed cyclical dependencies are not completely cleaned up, which leads to bundles being considered to be resolved when in fact they are not. The previous fix for this did not go far enough since it only cleaned immediately cyclical dependencies. Instead, it must removed failed candidates from any modules using them as a potential candidate, which could also cause those modules to fail to resolve if that was the only potential candidate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Apache Felix/OSGi Meetup at ApacheCon US
Hi, the next ApacheCon US is just weeks away. (http://www.apachecon.com) I've reserved a room for an Apache Felix/OSGi meetup on tuesday evening http://wiki.apache.org/apachecon/ApacheMeetupsUs09 In contrast to a BOF a meetup usually includes short presentations where everyone is invited to present something - interesting :) - about Apache Felix/OSGi. I guess the best way of organizing this event is to collect ideas/proposals and put them on the wiki. So your input is welcome :) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Resolved: (FELIX-1708) Improve error reporting
[ https://issues.apache.org/jira/browse/FELIX-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1708. -- Resolution: Fixed Implemented the improved logging in Rev. 822249: * SCRDescriptorException supports source location and line number information * Log interface has error and warn signatures taking source location and line number information * JavaTag adds method to return line number information (if available) Plus added source location information for logging and SCRDescrptorException throwing in almost all places (where applicable) Improve error reporting --- Key: FELIX-1708 URL: https://issues.apache.org/jira/browse/FELIX-1708 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.4.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: maven-scr-plugin-1.4.1 Currently error reporting in the Maven SCR Plugin is rather straightforward supporting only string messages. Now, that the SCR Plugin can be used outside of the Maven scope where more functionality may be provided, a more detailed error reporting mechanism might make sense. Specifically, support for providing three part messages (source, line number, message) would be very helpfull in certain situations and would also allow for a more standardized log formatting in the maven case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1703) SCR Plugin not always recognizes correctly to switch into DS 1.1 descriptor mode
[
https://issues.apache.org/jira/browse/FELIX-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-1703.
--
Resolution: Fixed
Deployed SNAPSHOTs containing this fix:
org.apache.felix.scr.annotations 1.0.1-20091006.125040-2
maven-scr-plugin 1.4.1-20091006.125108-2 (also containing FELIX-1708)
SCR Plugin not always recognizes correctly to switch into DS 1.1 descriptor
mode
Key: FELIX-1703
URL: https://issues.apache.org/jira/browse/FELIX-1703
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.4.0
Reporter: Felix Meschberger
Fix For: maven-scr-plugin-1.4.1
Given a simple component like this:
/**
* @scr.component activate=newActivate deactivate=newDeactivate
* @scr.property name=sample value=Sample Value
*/
public class SampleComponent {
private final Logger log = LoggerFactory.getLogger(getClass());
protected void activate(Map?, ? config) {
log.info(Component {} starting, config.get(component.name));
}
protected void deactivate(Map?, ? config, int reason) {
log.info(Component {} stopping, reason: {},
config.get(component.name), reason);
}
}
The Maven SCR plugin in this case does not accept the signatures of the
activate and deactivate methods to require a DS 1.1 descriptor.
Maybe, for backwards compatibility with existing source, it is also better to
not switch into a DS 1.1 descriptor: There might be code where methods with
signatures newly supported by DS 1.1 should not be used. In this case it
would be good to be able to explicitly declare the component to be a DS 1.1
compliant component.
Currently it is not possible to specify this on a per-component level. It is
only possible per plugin configuration or by having the plugin detect a DS
1.1 feature, such as the activate or deactivate attribute to the
@scr.component tag.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-198) Build of trunk fails
[ https://issues.apache.org/jira/browse/FELIX-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762627#action_12762627 ] Sahoo commented on FELIX-198: - The related maven bug has been fixed in mvn 2.2.1. Should we think of removing the work around from our pom.xml? Build of trunk fails Key: FELIX-198 URL: https://issues.apache.org/jira/browse/FELIX-198 Project: Felix Issue Type: Bug Affects Versions: felix-1.0.0 Environment: java version 1.5.0_06 Reporter: John Conlon Assignee: Richard S. Hall Priority: Critical Fix For: felix-1.0.0 Attachments: mychanges.patch, pom-bug.xml, pom-old-pluginA.xml, pom.xml Encountering maven bug http://jira.codehaus.org/browse/MNG-1682 when building the trunk with pom-old-plugin.xml called from the ant build.xml. This bug occurs when more than two packaging types are used in a multiproject build. In this case ipojo does a packagingipojo-bundle/packaging which triggers the bug for all subsequent module builds. These module builds will only occur when running with a jdk1.5, as this will trigger the mosgi module builds. profiles profile idjdk1.5/id activation jdk1.5/jdk /activation modules modulemosgi.console.xxx... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Odd implementation detail of native libs and bundle cache
Hi, I just discovered a very odd and - at least for my use case very unhelpful - change in behaviour of felix from 1.8 to 2.0 concerning native libraries. You might know about the difficulties of managing libraries with dependencies. For my project I had pursued the approach of handling Linux platforms by temporarily copying dependencies to /tmp, loading them by making the originally loaded JNI library have an RPATH of /tmp, and then clean up. This is ugly, error-prone, insecure (symlink attack) etc. but *worked* across all runtimes. In order to improve this rather ugly hack I now tried to use an RPATH of $ORIGIN. This special value will make shared libaries look in the location of the originating dependency, which is _exactly_ what I want for bundles. And it works great! There is a slight catch that not all runtimes unpack bundle libraries eagerly, so the libs have to be referenced in order to show up in the bundle cache. Works fine too...except on felix 2.0. For some reason a bundle's libraries are unpacked with any path given in the NativeCode header (correct and good) but _into another subdirectory_. This means that three libraries platform/a.so, platform/b.so, platform/c.so will not end up in a common directory platform/ but rather in directories platform/0/, platform/1/, platform/2/ and so on - which totally breaks the great $ORIGIN hack. :( Is there a good reason why felix would need to do this? Older versions did not, and neither does equinox (at least not 3.5). I fully realize that the layout of the bundle cache is hands off and an implementation detail, but at this level I _must_ have some deterministic way of interacting with the platform. IMHO it is wrong that resources or libraries with common path prefixes do not actually end up in a common directory - not technically, but in the principle of least surprise way. Ideas or comments? I can help fix this if necessary. thanks Holger
[jira] Commented: (FELIX-1660) karaf should not hardcode the system location of its maven-like repository
[ https://issues.apache.org/jira/browse/FELIX-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762631#action_12762631 ] richard stone commented on FELIX-1660: -- I believe this fix was not fully completed: 1. The config.properties to be modified should be assembly/src/main/filtered-resources/etc/config.properties, not main/src/main/resources/config.properties (which is outdated and should be removed) 2. assembly/src/main/distribution/text/etc/org.ops4j.pax.url.mvn.cfg should also be modified accordingly. A 1660-more.patch is attached. karaf should not hardcode the system location of its maven-like repository Key: FELIX-1660 URL: https://issues.apache.org/jira/browse/FELIX-1660 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: David Jencks Assignee: Guillaume Nodet Fix For: karaf-1.0.2 Attachments: 1660-more.patch, FELIX-1660.diff A lot of stuff in the karaf setup is configurable, but the directory in which the maven-like bundle repo is located is not. For geronimo integration we'd like to not surprise our users and use repository instead of system. I'm attaching a minimal patch to enable configuring this, I'll refine it if the idea meets with approval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1660) karaf should not hardcode the system location of its maven-like repository
[ https://issues.apache.org/jira/browse/FELIX-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] richard stone updated FELIX-1660: - Attachment: 1660-more.patch karaf should not hardcode the system location of its maven-like repository Key: FELIX-1660 URL: https://issues.apache.org/jira/browse/FELIX-1660 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: David Jencks Assignee: Guillaume Nodet Fix For: karaf-1.0.2 Attachments: 1660-more.patch, FELIX-1660.diff A lot of stuff in the karaf setup is configurable, but the directory in which the maven-like bundle repo is located is not. For geronimo integration we'd like to not surprise our users and use repository instead of system. I'm attaching a minimal patch to enable configuring this, I'll refine it if the idea meets with approval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
reactor pom has a fixed version
In the top level pom (i.e., the reactor pom), I see the following comment, but strangely the version has never been updated; it is still at version 1! !-- We just increase the version each time the list of modules changes -- version1/version Just because this artifact is never published, we are fine I guess. Thanks, Sahoo
[jira] Commented: (FELIX-1681) Bundles of webconsole feature are not assembled into distribution packages
[ https://issues.apache.org/jira/browse/FELIX-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762645#action_12762645 ] richard stone commented on FELIX-1681: -- Guillaume, fine. However may I know the purpose? Or could you give me a pointer to the reason?:) Bundles of webconsole feature are not assembled into distribution packages -- Key: FELIX-1681 URL: https://issues.apache.org/jira/browse/FELIX-1681 Project: Felix Issue Type: Bug Components: Karaf Reporter: richard stone Priority: Minor Fix For: karaf-1.2.0 Attachments: webconsole_assembly.patch Start Karaf 1.1.0 snapshot, type features:install webconsole, it will throw an exception can not get org.apache.felix.karaf.webconsole.admin-1.1.0-SNAPSHOT.jar, this is because the related bundles are not in default local system/ and other remote repositories. One straightforward solution is to assemble them into distribution packages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FELIX-1660) karaf should not hardcode the system location of its maven-like repository
[ https://issues.apache.org/jira/browse/FELIX-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened FELIX-1660: karaf should not hardcode the system location of its maven-like repository Key: FELIX-1660 URL: https://issues.apache.org/jira/browse/FELIX-1660 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: David Jencks Assignee: Guillaume Nodet Fix For: karaf-1.0.2 Attachments: 1660-more.patch, FELIX-1660.diff A lot of stuff in the karaf setup is configurable, but the directory in which the maven-like bundle repo is located is not. For geronimo integration we'd like to not surprise our users and use repository instead of system. I'm attaching a minimal patch to enable configuring this, I'll refine it if the idea meets with approval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Odd implementation detail of native libs and bundle cache
These changes came about because of support for native libraries in fragments. Since fragments can attach to multiple hosts in R4.2, the framework needs to be able to extract multiple copies, one for each host. The debate was where/how to do this. We could extract into the host cache directory, which would make it easier to do what you want (i.e., all in one directory), but it would complicate cleaning up after fragments since once it was uninstalled you'd need to remove it from all current and past host cache directories. Instead, I decided to extract it into the fragment's cache directory because when the fragment is uninstalled, everything is cleaned up in one swoop. Of course, doing so requires the framework to extract into separate locations to avoid collisions. Currently, I don't remember the exact details of why we extract the way we do. If you want to open an issue on this, I will look into it. No promises about finding a solution, though. - richard On 10/6/09 16:08, Holger Hoffstätte wrote: Hi, I just discovered a very odd and - at least for my use case very unhelpful - change in behaviour of felix from 1.8 to 2.0 concerning native libraries. You might know about the difficulties of managing libraries with dependencies. For my project I had pursued the approach of handling Linux platforms by temporarily copying dependencies to /tmp, loading them by making the originally loaded JNI library have an RPATH of /tmp, and then clean up. This is ugly, error-prone, insecure (symlink attack) etc. but *worked* across all runtimes. In order to improve this rather ugly hack I now tried to use an RPATH of $ORIGIN. This special value will make shared libaries look in the location of the originating dependency, which is _exactly_ what I want for bundles. And it works great! There is a slight catch that not all runtimes unpack bundle libraries eagerly, so the libs have to be referenced in order to show up in the bundle cache. Works fine too...except on felix 2.0. For some reason a bundle's libraries are unpacked with any path given in the NativeCode header (correct and good) but _into another subdirectory_. This means that three libraries platform/a.so, platform/b.so, platform/c.so will not end up in a common directory platform/ but rather in directories platform/0/, platform/1/, platform/2/ and so on - which totally breaks the great $ORIGIN hack. :( Is there a good reason why felix would need to do this? Older versions did not, and neither does equinox (at least not 3.5). I fully realize that the layout of the bundle cache is hands off and an implementation detail, but at this level I _must_ have some deterministic way of interacting with the platform. IMHO it is wrong that resources or libraries with common path prefixes do not actually end up in a common directory - not technically, but in the principle of least surprise way. Ideas or comments? I can help fix this if necessary. thanks Holger
Re: Sigil launcher
On Thu, Aug 20, 2009 at 8:38 PM, David Savage dave.sav...@paremus.com wrote: On Thu, Aug 20, 2009 at 8:34 PM, Richard S. Hallhe...@ungoverned.org wrote: On 8/20/09 15:17, David Savage wrote: Sure like the felix launcher with the bundles dir which is like a simple version of fileinstall - this is a lowest common denominator type approach for remote control of an OSGi runtime. As you say I /could/ use the directory based bundle launch mechanism to start the server as a bundle - but what if that's the behaviour we wanted to debug via the ide - separating it out stuck me as cleaner as long as it remains light weight. From the IDE perspective I want to be able to bring the OSGi runtime up with as few dependencies as possible - as then what ever you debug is out of band of the IDE interaction. Still, we could potentially accomplish this via a wrapper approach. For example, we could modify our Main.java launcher to have a Main.getFramework() method. Then in the wrapper, you could invoke Main.main() to start the framework, call Main.getFramework() to get the created instance, open your socket and go to town. This would involve minimal dependencies too, but would avoid duplicating launcher code. Ok yep, that makes sense. Well, let's see what other people think. Sorry for the multiple emails on this but I'm going around the houses on this launch support and I think I've come back to this idea. I like the idea of using karaf or pax profiles but having taken the time to have a look around they both have quite a few (useful) added extras that unfortunately make them complex to use out side of their own domains. For karaf the support for configs is a dependency that would be difficult to replicate from a standalone launcher and for both pax and karaf the support for urls in mvn format whilst useful is difficult to replicate outside of this context. So I'm thinking that the simplest option is for the sigil launch config to specify a felix config.properties which lists the bundles that should be automatically booted into the framework. This allows you to boot a framework into a known state and then use the socket based API to do the later tweeking. To launch an eclipse install via the felix launcher the config.properties could look something like: felix.auto.deploy.dir=/opt/eclipse/plugins I just tried this myself on a felix 2.0.0 install using the following command line: java -cp /opt/eclipse-SDK-3.5.1/plugins/org.eclipse.osgi_3.5.1.R35x_v20090827.jar:bin/felix.jar org.apache.felix.main.Main and promptly ran into a bunch of resolution failures but this at least proves it's trying to launch it... I just had a quick look at the framework issues in jira and I don't think this (Main.getFramework()) feature has been raised? I'm happy to do this and take a stab at supplying a patch if this all sounds ok? Regards, Dave Indeed. Regards, Dave - richard
Re: Karaf features + Sigil launch
Dave, If you like we can get into a discussion on what you need and the reasons behind. I have that feeling that Pax Runner infrastructure can satisfy your requirements. For example, Pax Runner can be started in such a way that it will give you back all you need to start a traget framework such as the framework jar, configuration file that include all the necessary properties to start up the framework + the bundles to be installed / started, setup class path, java vm startup options and so on. Think about. You can start any framework, any version. And also, I can make Pax Runner a separated eclipse plugin that can be shared between Pax Runner Eclipse Plugin and Sigil. Did you had the time to look at pax runner eclipse plugin? More if you do not need the whole pax runner infra we can work on a setup where you can use Pax Scanner outside the targeted framework process. lets get into a chat session and figure out what you will need ;) On Tue, Oct 6, 2009 at 1:31 PM, David Savage david.sav...@paremus.comwrote: On Tue, Oct 6, 2009 at 10:27 AM, Alin Dreghiciu adreghi...@gmail.com wrote: I do not want to compare the two formats so here fact about the profile Fair enough, yep I realized just after I sent my mail this could be asking for trouble - that is not my intention just to figure out what is the best way to achieve this. format: * profile format is the format that can be scanned by a composite scanner (scan-composite:). Here is some more documentation: http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning * it can include any other provisioning specs so you can scan from karaf features, simple text files containing bundles urls, maven poms, directories containing bundles, zips containing jars, any bundle referenced by url. * it can include references to another composite scanners. * there are a bunch of such files in Pax Runner repository: http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list ( https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/ ) * the whole functionality about using this scanners is extracted out of pax runner into pax scanner project Does the scanner run in the framework process? I think for isolation reasons it make sense to make the framework a very thin client with very few dependencies installed, this ensures that when you debug you're actually debugging your code and not some accidental collision with pre resolved bundles in the framework. Consider the case where you'd want to debug pax scanner for example? Or more likely some other application that happens to share dependencies with pax-scanner and you want to ensure you're debugging precisely your set of bundle dependencies. Now related to the part where you launch an osgi framework you may want to take a look at pax runner eclipse plugin that allows you to start any OSS framework / any version and we can discuss about any features you may need. I'll take a look, that's basically what I'm trying to write a gui for at the moment - but I would love not to have to reinvent this particular wheel as it involves a lot of GUI code that I can do but always feels a little like pulling teeth ;) About install/update/uninstall bundles in the external running framework you may want to look at Pax Exam RBC (remote bundle context) that we use it to allow the install/uninstall of bundles from outside of the process (RMI) + allows to make calls to services in the remote process. Again, if any special needs, let me know. That sounds similar to something I've started here too i.e. a launcher for Sigil that uses a socket based approach to control the framework remotely: http://svn.apache.org/viewvc/felix/trunk/sigil/common/runtime/src/org/apache/felix/sigil/common/runtime/Client.java?view=markup The point about using sockets was to again reduce the dependencies on the framework to a minimum. This does seem to have some overlap with the pax exam functionality. Maybe there's some mileage in coming up with a common model for this? About ivy is just a matter (I think) of implementing an url handler as we did for maven. Actually we have an issue there to support it but yet there was not requested. As per other comments - does this imply the url handler is installed in the remote framework? Thx for the info. Regards, Dave HTH On Tue, Oct 6, 2009 at 11:20 AM, David Savage david.sav...@paremus.com wrote: Hi there, I'm currently looking into how to set up a launch configuration for Sigil development in the IDE and one idea that seems quite attractive is to reuse the Karaf features format to list the bundles that the user wishes to install in the framework. The use case I'm looking to solve is initial boot of an OSGi framework from the IDE with a pre configured set of bundles. Once the framework is running it will be possible to install and uninstall
[jira] Resolved: (FELIX-1712) CLONE -Support for port as service properties
[ https://issues.apache.org/jira/browse/FELIX-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] andre payne resolved FELIX-1712. Resolution: Incomplete Fix Version/s: (was: http-2.0.4) maven-scr-plugin-1.4.1 CLONE -Support for port as service properties - Key: FELIX-1712 URL: https://issues.apache.org/jira/browse/FELIX-1712 Project: Felix Issue Type: Improvement Components: Installer Affects Versions: dependencymanager.shell-2.0.1 Reporter: andre payne Assignee: Sten Roger Sandvik Fix For: maven-scr-plugin-1.4.1 Support assigned port in Jetty as service property. Both secure and non secure. Use the same logic as in old Jetty http service 1.0.1. * org.apache.felix.http.svcprop.port * org.apache.felix.http.svcprop.port.secure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1712) CLONE -Support for port as service properties
[ https://issues.apache.org/jira/browse/FELIX-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762758#action_12762758 ] Sten Roger Sandvik commented on FELIX-1712: --- Not sure why this is affecting dependencymanager-shell? CLONE -Support for port as service properties - Key: FELIX-1712 URL: https://issues.apache.org/jira/browse/FELIX-1712 Project: Felix Issue Type: Improvement Components: Installer Affects Versions: dependencymanager.shell-2.0.1 Reporter: andre payne Assignee: Sten Roger Sandvik Fix For: maven-bundle-plugin-2.1.0 Support assigned port in Jetty as service property. Both secure and non secure. Use the same logic as in old Jetty http service 1.0.1. * org.apache.felix.http.svcprop.port * org.apache.felix.http.svcprop.port.secure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
[ https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sten Roger Sandvik reassigned FELIX-1713: - Assignee: Sten Roger Sandvik getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Assignee: Sten Roger Sandvik Fix For: http-2.0.4 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
[ https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762781#action_12762781 ] Sten Roger Sandvik commented on FELIX-1713: --- Added fix for this in trunk. Need a little more testing, but I am pretty sure this will fix getPathinfo() problem. getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Assignee: Sten Roger Sandvik Fix For: http-2.0.4 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
[ https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-1713 started by Sten Roger Sandvik. getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Assignee: Sten Roger Sandvik Fix For: http-2.0.4 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
[ https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sten Roger Sandvik closed FELIX-1713. - Resolution: Fixed Verified with my local installation. Fix is ok. getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Assignee: Sten Roger Sandvik Fix For: http-2.0.4 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
[ https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sten Roger Sandvik reopened FELIX-1713: --- Actually. Need to check this a little bit more. getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Assignee: Sten Roger Sandvik Fix For: http-2.0.4 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid
[ https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sten Roger Sandvik closed FELIX-1713. - Resolution: Fixed Now it seems to be fixed in trunk. Request attributes on URI is not longer returned in getPathInfo(). getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid - Key: FELIX-1713 URL: https://issues.apache.org/jira/browse/FELIX-1713 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Sid Fischer Assignee: Sten Roger Sandvik Fix For: http-2.0.4 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 calling HttpServletRequest.getPathInfo() not only returns the raw path but additionally the semicolon-separated attributes, like ;jsessionid. Example (version 1.0.1): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo Example (version 2.0.2): getRequestURI(): /test/foo;bar=baz getPathInfo(): /foo;bar=baz Looks like in org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the original HttpServletRequest is wrapped and getPathInfo() is overwritten using the String retrieved from getRequestURI() including the attributes. This behaviour will break a lot of applications which rely on urlrewriting-based session handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1714) typo in scr command
typo in scr command --- Key: FELIX-1714 URL: https://issues.apache.org/jira/browse/FELIX-1714 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Reporter: Davanum Srinivas Priority: Trivial Please note the typo Componnent, should be Component ./scr/src/main/java/org/apache/felix/scr/impl/ScrCommand.java: out.println( Componnent + component.getName() + disabled ); thanks, dims -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
