[jira] [Commented] (FELIX-3542) Incorrect rendering of default property values with backslashes in property editor
[ https://issues.apache.org/jira/browse/FELIX-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621245#comment-13621245 ] Tobias Bocanegra commented on FELIX-3542: - yes it is a problem. the properties passed in the 'activate' method are identical to the ones specified in the annotation. so no double escaping needed. as ankur mentioned above: > The component gets the correct initial value. But things fail when you open > the property editor and save without making any changes > Incorrect rendering of default property values with backslashes in property > editor > -- > > Key: FELIX-3542 > URL: https://issues.apache.org/jira/browse/FELIX-3542 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Ankur Pathela >Assignee: Felix Meschberger >Priority: Minor > > For a component property defined as below: > > static private final String DEFAULT_FILE_PATTERN = "(?i)index\\.html"; > @Property(value=DEFAULT_FILE_PATTERN) > static private final String PN_FILE_PATTERN = "file.pattern"; > > The backslash gets eaten up in the felix web console. The default value > should appear as (?i)index\.html but ends up looking like (?i)index.html. > This regex has a different meaning than the one intended. > The component gets the correct initial value. But things fail when you open > the property editor and save without making any changes(because the editor > loaded up with an incorrect default value). Note that the property values > when saved from the property editor render correctly the next time the editor > loads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] Apache Felix Resolver 1.0.0
I'd like to call a vote on the initial release of the Apache Felix Resolver. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-061/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 061 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
[jira] [Comment Edited] (FELIX-3239) PackageAdmin#getExportedPackages does not work on packages exported by attached fragments
[
https://issues.apache.org/jira/browse/FELIX-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619840#comment-13619840
]
Bertrand Delacretaz edited comment on FELIX-3239 at 4/3/13 2:02 PM:
This used to work in 3.x versions (tested with 3.0.8 and 3.2.2) but does not in
4.0.1 or 4.0.2.
I have created a test at https://github.com/bdelacretaz/felix-fragment-tests -
running "mvn clean test -Dfelix.version=4.0.2" at the top of that causes
FragmentsTest.testPackageFromFragment to fail.
The test is really simple, just calls
getExportedPackage("ch.x42.felix.fragmenttests.fragment") where the
ch.x42.felix.fragmenttests.fragment package is provided by the test's
fragment-bundle which is attached to the test's host-bundle.
I haven't found a place in the Felix codebase to add such a test, that requires
two test bundles.
was (Author: bdelacretaz):
This used to work in 3.x versions (tested with 3.0.8 and 3.2.2) but does
not in 4.0.1 or 4.0.2.
I have created a test at https://github.com/bdelacretaz/felix-fragment-tests,
running "mvn clean test -Dfelix.version=4.0.2" at the top of that causes
FragmentsTest.testPackageFromFragment to fail.
The test is really simple, just calls
getExportedPackage("ch.x42.felix.fragmenttests.fragment") where the
ch.x42.felix.fragmenttests.fragment package is provided by the test's
fragment-bundle which is attached to the test's host-bundle.
I haven't found a place in the Felix codebase to add such a test, that requires
two test bundles.
> PackageAdmin#getExportedPackages does not work on packages exported by
> attached fragments
> -
>
> Key: FELIX-3239
> URL: https://issues.apache.org/jira/browse/FELIX-3239
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-4.0.1
>Reporter: Guillaume Nodet
> Fix For: framework-4.4.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4013) Incorrect usage of ServiceTracker.size() in UPnP Plugin
[ https://issues.apache.org/jira/browse/FELIX-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-4013. - Resolution: Fixed fixed in rev.1464014 > Incorrect usage of ServiceTracker.size() in UPnP Plugin > --- > > Key: FELIX-4013 > URL: https://issues.apache.org/jira/browse/FELIX-4013 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-upnp-plugin-1.0.2 >Reporter: Valentin Valchev >Assignee: Valentin Valchev > Fix For: webconsole-upnp-plugin-1.0.4 > > > There seems to be a small problem with the tracking code especially with the > following line (Activator.java): > if (tracker.size() <= 1 && plugin != null) > ... > ServiceTrackerCustomizer.removedService() is supposed to be called AFTER the > service is no longer tracked. So in that method the size must be already > decremented. The code above will unregister the plugin if only one UPnP > device left in the system and it wouldn't be accessible through the web > console. > The correct code is: > if (tracker.size() == 0 && plugin != null) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4012) Sometimes the UPnP plugin fails to start due to device being removed from network
[
https://issues.apache.org/jira/browse/FELIX-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Valchev resolved FELIX-4012.
-
Resolution: Fixed
fixed in rev.1464003
> Sometimes the UPnP plugin fails to start due to device being removed from
> network
> -
>
> Key: FELIX-4012
> URL: https://issues.apache.org/jira/browse/FELIX-4012
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-upnp-plugin-1.0.2
>Reporter: Valentin Valchev
>Assignee: Valentin Valchev
> Fix For: webconsole-upnp-plugin-1.0.4
>
>
> Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
> IllegalStateException if you keep reference to device that has been removed
> from the network.
> During startup the ServiceTracker will notify the plugin for all previously
> registered UPnP devices. While processing them, a device can be removed and
> the reference becomes obsolete. Then the getIcons() method will throw
> exception which is not caught and will cause the BundleActivator.start() to
> fail. So the bundle stays in resolved state.
> Here is stack trace of the problem:
> {code}
> java.lang.IllegalStateException: The UPnP Device was removed from the
> network. Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
> at
> com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
> at
> com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316)
> at
> org.apache.felix.webconsole.plugins.upnp.internal.ControlServlet.addingService(ControlServlet.java:543)
> at
> org.apache.felix.webconsole.plugins.upnp.internal.Activator.addingService(Activator.java:88)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:909)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
> at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:349)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283)
> at
> org.apache.felix.webconsole.plugins.upnp.internal.Activator.start(Activator.java:48)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4013) Incorrect usage of ServiceTracker.size() in UPnP Plugin
Valentin Valchev created FELIX-4013: --- Summary: Incorrect usage of ServiceTracker.size() in UPnP Plugin Key: FELIX-4013 URL: https://issues.apache.org/jira/browse/FELIX-4013 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-upnp-plugin-1.0.2 Reporter: Valentin Valchev Assignee: Valentin Valchev Fix For: webconsole-upnp-plugin-1.0.4 There seems to be a small problem with the tracking code especially with the following line (Activator.java): if (tracker.size() <= 1 && plugin != null) ... ServiceTrackerCustomizer.removedService() is supposed to be called AFTER the service is no longer tracked. So in that method the size must be already decremented. The code above will unregister the plugin if only one UPnP device left in the system and it wouldn't be accessible through the web console. The correct code is: if (tracker.size() == 0 && plugin != null) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4012) Sometimes the UPnP plugin fails to start due to device being removed from network
[
https://issues.apache.org/jira/browse/FELIX-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Valchev updated FELIX-4012:
Description:
Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
IllegalStateException if you keep reference to device that has been removed
from the network.
During startup the ServiceTracker will notify the plugin for all previously
registered UPnP devices. While processing them, a device can be removed and the
reference becomes obsolete. Then the getIcons() method will throw exception
which is not caught and will cause the BundleActivator.start() to fail. So the
bundle stays in resolved state.
Here is stack trace of the problem:
{code}
java.lang.IllegalStateException: The UPnP Device was removed from the network.
Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316)
at
org.apache.felix.webconsole.plugins.upnp.internal.ControlServlet.addingService(ControlServlet.java:543)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.addingService(Activator.java:88)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:909)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:349)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.start(Activator.java:48)
{code}
was:
Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
IllegalStateException if you keep reference to device that has been removed
from the network.
During startup the ServiceTracker will notify the plugin for all previously
registered UPnP devices. While processing them, a device can be removed and the
reference becomes obsolete. Then the getIcons() method will throw exception
which is not caught and will cause the BundleActivator.start() to fail. So the
bundle stays in resolved state.
Here is stack trace of the problem:
{code}
java.lang.IllegalStateException: The UPnP Device was removed from the network.
Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316)
at
org.apache.felix.webconsole.plugins.upnp.internal.ControlServlet.addingService(ControlServlet.java:543)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.addingService(Activator.java:88)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:909)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:349)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.start(Activator.java:48)
{/code}
> Sometimes the UPnP plugin fails to start due to device being removed from
> network
> -
>
> Key: FELIX-4012
> URL: https://issues.apache.org/jira/browse/FELIX-4012
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-upnp-plugin-1.0.2
>Reporter: Valentin Valchev
>Assignee: Valentin Valchev
> Fix For: webconsole-upnp-plugin-1.0.4
>
>
> Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
> IllegalStateException if you keep reference to device that has been removed
> from the network.
> During startup the ServiceTracker will notify the plugin for all previously
> registered UPnP devices. While processing them, a device can be removed and
> the reference becomes obsolete. Then the getIcons() method will throw
> exception which is not caught and will cause the BundleActivator.start() to
> fail. So the bundle stays in resolved state.
> Here is stack trace of the problem:
> {code}
> java.lang.IllegalStateException: The UPnP Device was removed from the
> network. Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
> at
> com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
> at
> com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl
[jira] [Created] (FELIX-4012) Sometimes the UPnP plugin fails to start due to device being removed from network
Valentin Valchev created FELIX-4012: --- Summary: Sometimes the UPnP plugin fails to start due to device being removed from network Key: FELIX-4012 URL: https://issues.apache.org/jira/browse/FELIX-4012 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-upnp-plugin-1.0.2 Reporter: Valentin Valchev Assignee: Valentin Valchev Fix For: webconsole-upnp-plugin-1.0.4 Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw IllegalStateException if you keep reference to device that has been removed from the network. During startup the ServiceTracker will notify the plugin for all previously registered UPnP devices. While processing them, a device can be removed and the reference becomes obsolete. Then the getIcons() method will throw exception which is not caught and will cause the BundleActivator.start() to fail. So the bundle stays in resolved state. Here is stack trace of the problem: java.lang.IllegalStateException: The UPnP Device was removed from the network. Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050 at com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477) at com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316) at org.apache.felix.webconsole.plugins.upnp.internal.ControlServlet.addingService(ControlServlet.java:543) at org.apache.felix.webconsole.plugins.upnp.internal.Activator.addingService(Activator.java:88) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:909) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:349) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283) at org.apache.felix.webconsole.plugins.upnp.internal.Activator.start(Activator.java:48) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4012) Sometimes the UPnP plugin fails to start due to device being removed from network
[
https://issues.apache.org/jira/browse/FELIX-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Valchev updated FELIX-4012:
Description:
Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
IllegalStateException if you keep reference to device that has been removed
from the network.
During startup the ServiceTracker will notify the plugin for all previously
registered UPnP devices. While processing them, a device can be removed and the
reference becomes obsolete. Then the getIcons() method will throw exception
which is not caught and will cause the BundleActivator.start() to fail. So the
bundle stays in resolved state.
Here is stack trace of the problem:
{code}
java.lang.IllegalStateException: The UPnP Device was removed from the network.
Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316)
at
org.apache.felix.webconsole.plugins.upnp.internal.ControlServlet.addingService(ControlServlet.java:543)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.addingService(Activator.java:88)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:909)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:349)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.start(Activator.java:48)
{/code}
was:
Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
IllegalStateException if you keep reference to device that has been removed
from the network.
During startup the ServiceTracker will notify the plugin for all previously
registered UPnP devices. While processing them, a device can be removed and the
reference becomes obsolete. Then the getIcons() method will throw exception
which is not caught and will cause the BundleActivator.start() to fail. So the
bundle stays in resolved state.
Here is stack trace of the problem:
java.lang.IllegalStateException: The UPnP Device was removed from the network.
Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
at
com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316)
at
org.apache.felix.webconsole.plugins.upnp.internal.ControlServlet.addingService(ControlServlet.java:543)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.addingService(Activator.java:88)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:909)
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
at
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:349)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:283)
at
org.apache.felix.webconsole.plugins.upnp.internal.Activator.start(Activator.java:48)
> Sometimes the UPnP plugin fails to start due to device being removed from
> network
> -
>
> Key: FELIX-4012
> URL: https://issues.apache.org/jira/browse/FELIX-4012
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-upnp-plugin-1.0.2
>Reporter: Valentin Valchev
>Assignee: Valentin Valchev
> Fix For: webconsole-upnp-plugin-1.0.4
>
>
> Since OSGi r4.3 it he methdod UPnPDevice.getIcons() may throw
> IllegalStateException if you keep reference to device that has been removed
> from the network.
> During startup the ServiceTracker will notify the plugin for all previously
> registered UPnP devices. While processing them, a device can be removed and
> the reference becomes obsolete. Then the getIcons() method will throw
> exception which is not caught and will cause the BundleActivator.start() to
> fail. So the bundle stays in resolved state.
> Here is stack trace of the problem:
> {code}
> java.lang.IllegalStateException: The UPnP Device was removed from the
> network. Device UDN: uuid:e516cbe4-35fd-4cf9-a862-886969e13050
> at
> com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.checkState(UPnPDeviceImpl.java:477)
> at
> com.prosyst.mbs.impl.services.upnp.cp.api.UPnPDeviceImpl.getIcons(UPnPDeviceImpl.java:316)
>
[jira] [Commented] (FELIX-3951) Let users able to specify the directory used to temporarily store uploaded files
[ https://issues.apache.org/jira/browse/FELIX-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620873#comment-13620873 ] Felix Meschberger commented on FELIX-3951: -- Sounds reasonable -- after all, in retrospect, this utility method is probably not a good one ;-) > Let users able to specify the directory used to temporarily store uploaded > files > > > Key: FELIX-3951 > URL: https://issues.apache.org/jira/browse/FELIX-3951 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-4.0.0 >Reporter: Simone Tripodi > Fix For: webconsole-4.0.2 > > Attachments: FELIX-3951.patch, Screen Shot 2013-03-05 at 2.36.05 > PM.pdf > > > As per subject, users should be able to dynamically switch the directory used > to temporarily store files, it would be good, for example, to set it to a > non-publicly writeable location, for security reasons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3951) Let users able to specify the directory used to temporarily store uploaded files
[ https://issues.apache.org/jira/browse/FELIX-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620870#comment-13620870 ] Valentin Valchev commented on FELIX-3951: - IMHO it should be better if everybody that uses the WebConsoleUtil to provide it's own BundleContext or temporary folder. Its very easy to implement simple resource monitoring, incl. how much data files a bundle is using. If we move everything to the Web Console, there could be a malicious plugin that exploits the Util class, to generate a lot of temporary files storage in the Web Console bundle. > Let users able to specify the directory used to temporarily store uploaded > files > > > Key: FELIX-3951 > URL: https://issues.apache.org/jira/browse/FELIX-3951 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-4.0.0 >Reporter: Simone Tripodi > Fix For: webconsole-4.0.2 > > Attachments: FELIX-3951.patch, Screen Shot 2013-03-05 at 2.36.05 > PM.pdf > > > As per subject, users should be able to dynamically switch the directory used > to temporarily store files, it would be good, for example, to set it to a > non-publicly writeable location, for security reasons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3542) Incorrect rendering of default property values with backslashes in property editor
[ https://issues.apache.org/jira/browse/FELIX-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3542. -- Resolution: Not A Problem Assignee: Felix Meschberger The problem is, that we need double escaping: Once for Java and once for the Metatype attribute's default value. So the actual property definition in your case must be: static private final String DEFAULT_FILE_PATTERN = "(?i)index.html"; with 4 (four) backslash characters in Java to actually get 2 (two) characters in the XML file and thus finally get the single backslash in the default value from the Metatype service. Metatype service escaping is described in the JavaDoc of the AttributeDefinition.validate(String) method (or section 105.13.3.21 of the OSGi Enterprise R5 specification): Commas ( ‘,’ \u002C) and spaces (‘ ‘ \u0020) and backslashes (‘\’ \u005C) can be escaped with another backslash. Escaped spaces must not be trimmed. For example: value=” a\,b,b\,c,\ c\\,d “ => [ “a,b”, “b,c”, “ c\”, “d” ] Hence resolving this as not being a problem. > Incorrect rendering of default property values with backslashes in property > editor > -- > > Key: FELIX-3542 > URL: https://issues.apache.org/jira/browse/FELIX-3542 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Ankur Pathela >Assignee: Felix Meschberger >Priority: Minor > > For a component property defined as below: > > static private final String DEFAULT_FILE_PATTERN = "(?i)index\\.html"; > @Property(value=DEFAULT_FILE_PATTERN) > static private final String PN_FILE_PATTERN = "file.pattern"; > > The backslash gets eaten up in the felix web console. The default value > should appear as (?i)index\.html but ends up looking like (?i)index.html. > This regex has a different meaning than the one intended. > The component gets the correct initial value. But things fail when you open > the property editor and save without making any changes(because the editor > loaded up with an incorrect default value). Note that the property values > when saved from the property editor render correctly the next time the editor > loads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3951) Let users able to specify the directory used to temporarily store uploaded files
[ https://issues.apache.org/jira/browse/FELIX-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620694#comment-13620694 ] Felix Meschberger commented on FELIX-3951: -- I agree with [~v_valchev]: There is no need for configuration and the tmp files should be in the bundle's context data. Maybe the console servlet could prime the WebConsoleUtil class with the data ? E.g. a setter method which can only be called once ? > Let users able to specify the directory used to temporarily store uploaded > files > > > Key: FELIX-3951 > URL: https://issues.apache.org/jira/browse/FELIX-3951 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-4.0.0 >Reporter: Simone Tripodi > Fix For: webconsole-4.0.2 > > Attachments: FELIX-3951.patch, Screen Shot 2013-03-05 at 2.36.05 > PM.pdf > > > As per subject, users should be able to dynamically switch the directory used > to temporarily store files, it would be good, for example, to set it to a > non-publicly writeable location, for security reasons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3951) Let users able to specify the directory used to temporarily store uploaded files
[
https://issues.apache.org/jira/browse/FELIX-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620688#comment-13620688
]
Valentin Valchev commented on FELIX-3951:
-
That method will fail if you run the framework with security. In order to make
it run correctly, you also need to setup the correct permissions. However, the
OSGi specification says that the bundle always has permissions to access it's
own bundle storage area.
Therefore a code like that would be more appropriate:
[code]
File baseDir =
FrameworkUtil.getBundle(WebConsoleUtil.class).getBundleContext().getDataFile("");
//$NON-NLS-1$
DiskFileItemFactory factory = new DiskFileItemFactory(256000,
baseDir);
[/code]
Unfortunately that would make web console dependent on OSGi r4 API. To fix
that, we should add the BundleContext or directly the File object to the method
signature. But this might break some other plugins that may use the method.
> Let users able to specify the directory used to temporarily store uploaded
> files
>
>
> Key: FELIX-3951
> URL: https://issues.apache.org/jira/browse/FELIX-3951
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: webconsole-4.0.0
>Reporter: Simone Tripodi
> Fix For: webconsole-4.0.2
>
> Attachments: FELIX-3951.patch, Screen Shot 2013-03-05 at 2.36.05
> PM.pdf
>
>
> As per subject, users should be able to dynamically switch the directory used
> to temporarily store files, it would be good, for example, to set it to a
> non-publicly writeable location, for security reasons.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
