[jira] Commented: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668774#action_12668774 ] Stuart McCulloch commented on FELIX-909: Whitespace _is_ allowed in manifest properties: http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Name-Value%20pairs%20and%20Sections Your patch would strip all formatting from descriptions and other such properties, which is completely wrong. BTW, I just tried a quick test with bundleplugin 1.4.3 and the (non-standard) metadata entry you mentioned: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle and while you will see whitespace between the 2 entries, the generated manifest is still valid and deploys correctly to an OSGi framework. Can you provide a sample testcase (ie. pom.xml, etc. that I can build and test) that clearly demonstrates the problem of an invalid manifest. Otherwise, it sounds more like you need to enhance your manifest parser to support whitespace White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-910) Framework may ignore framework startlevel on startup
Framework may ignore framework startlevel on startup
Key: FELIX-910
URL: https://issues.apache.org/jira/browse/FELIX-910
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: felix-1.6.0
Reporter: Felix Meschberger
Fix For: felix-1.6.0
When calling the Felix.start() method, a check is done, whether the init method
must be called. After that, the state is checked again to see whether it is
STARTING and hence the framework target startlevel should be set according to
the org.osgi.framework.startlevel property:
final int state = getState();
if ((state == Bundle.INSTALLED) || (state == Bundle.RESOLVED)) {
init();
}
if (state == Bundle.STARTING) {
Unfortunately this code is broken, since the state variable is still INSTALLED
or RESOLVED after the init() method has been called even though the actual
state really is STARTING.
A workaround for client code encountering this issue, is to call the init()
method itself as in :
Felix felix = new Felix(map);
felix.init();
felix.start();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-910) Framework may ignore framework startlevel on startup
[
https://issues.apache.org/jira/browse/FELIX-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-910:
Attachment: FELIX-910.patch
Proposed patch: The state variable is not final again and set to the actual
state after calling the init() method.
Framework may ignore framework startlevel on startup
Key: FELIX-910
URL: https://issues.apache.org/jira/browse/FELIX-910
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: felix-1.6.0
Reporter: Felix Meschberger
Fix For: felix-1.6.0
Attachments: FELIX-910.patch
When calling the Felix.start() method, a check is done, whether the init
method must be called. After that, the state is checked again to see whether
it is STARTING and hence the framework target startlevel should be set
according to the org.osgi.framework.startlevel property:
final int state = getState();
if ((state == Bundle.INSTALLED) || (state == Bundle.RESOLVED)) {
init();
}
if (state == Bundle.STARTING) {
Unfortunately this code is broken, since the state variable is still
INSTALLED or RESOLVED after the init() method has been called even though the
actual state really is STARTING.
A workaround for client code encountering this issue, is to call the init()
method itself as in :
Felix felix = new Felix(map);
felix.init();
felix.start();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668780#action_12668780 ] Boris Burgstaller commented on FELIX-909: - The thing is that the format of the Export-Package and Import-Package entries in the manifest are not the same as in the Import-Bundle. In the pom file they look similar, but they are not treated the same way during the generation of the Manifest White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668781#action_12668781 ] Boris Burgstaller commented on FELIX-909: - an Example, in th pom you have configuration instructions Export-Package com.bla.api, com.bla.impl /Export-Package Import-Bundle com.bla2.api, com.bla2.impl /Import-Bundle /instructions /configuration in the manifes you get: Manifest-Version: 1.0 Export-Package: com.bla.api,com.bla.impl Built-By: bburgstaller Tool: Bnd-0.0.255 Bundle-Name: bla_api Created-By: Apache Maven Bundle Plugin Import-Bundle: com.bla2.api, com.bla2.impl Bundle-Version: 1.0.0.SNAPSHOT Build-Jdk: 1.6.0_05 Bnd-LastModified: 1233305399966 Bundle-ManifestVersion: 2 Import-Package: com.bla.api,com.bla.impl Bundle-SymbolicName: com.bla.bla White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Burgstaller updated FELIX-909: Comment: was deleted White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: example.txt, patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[
https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668781#action_12668781
]
bburgstaller edited comment on FELIX-909 at 1/30/09 12:54 AM:
---
s
was (Author: bburgstaller):
an Example, in th pom you have
{code}
configuration
instructions
Export-Package
com.bla.api,
com.bla.impl
/Export-Package
Import-Bundle
com.bla2.api,
com.bla2.impl
/Import-Bundle
/instructions
/configuration
{code}
in the manifes you get:
{code}
Manifest-Version: 1.0
Export-Package: com.bla.api,com.bla.impl
Built-By: bburgstaller
Tool: Bnd-0.0.255
Bundle-Name: bla_api
Created-By: Apache Maven Bundle Plugin
Import-Bundle: com.bla2.api,
com.bla2.impl
Bundle-Version: 1.0.0.SNAPSHOT
Build-Jdk: 1.6.0_05
Bnd-LastModified: 1233305399966
Bundle-ManifestVersion: 2
Import-Package: com.bla.api,com.bla.impl
Bundle-SymbolicName: com.bla.bla
{code}
White spaces in the Import-Bundle of theManifest file
-
Key: FELIX-909
URL: https://issues.apache.org/jira/browse/FELIX-909
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-1.4.3
Reporter: Boris Burgstaller
Attachments: example.txt, patch.txt
We are using the Maven Bundle Plugin to generate our bundles and manifests.
We are using the Import-Bundle and we noticed that it does not remove the
white spaces coming from the xml if you format it like this:
Import-Bundle
com.bla.api,
com.bla.impl
/Import-Bundle
We deploy some bundles on a springsource dm server, and if the manifest
contains whitespaces and newlines, it falis to parse the file.
could you please remove the white spaces for this property?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Burgstaller updated FELIX-909: Attachment: example.txt White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: example.txt, patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668783#action_12668783 ] Stuart McCulloch commented on FELIX-909: Yes, that's because Export-Package and Import-Package are OSGi properties that are calculated by Bnd itself based on the given instructions, whereas Import-Bundle is a non-standard property that Bnd knows nothing about and simply copies it across unchanged from the XML content (including whitespace contained inside the string). Because it doesn't know anything about the structure of Import-Bundle it cannot remove this whitespace - for all Bnd knows that whitespace might be important. But regardless of this point, even if I create a hand-crafted manifest with spaces in the Export-Package / Import-Package properties it is _still_ valid and can be parsed by OSGi frameworks. So whatever parser you're using to read the Import-Bundle property should be made more robust to handle whitespace - because otherwise you're going to hit the same problem when a customer uses a bundle with a hand-written manifest that has spaces inside Import-Bundle. White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: example.txt, patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch resolved FELIX-909. Resolution: Won't Fix Your example creates a bundle that loads fine on both Felix and Equinox, so the manifest is valid from an OSGi perspective. What you're asking for is special handling for a certain property (Import-Bundle) that isn't part of the OSGi standard and appears to have restrictions on its content (no whitespace) purely due to the limitations of some code that's supposed to parse it. Rather than go round fixing all the tools that could conceivably create manifests, it is better to fix this particular parser - handling whitespace should be trivial and is supported by most parser generators. At the very least all you need to do is apply your suggested search-and-replace when reading this property from the bundle manifest, before you attempt to parse it. White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: example.txt, patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668785#action_12668785 ] Boris Burgstaller commented on FELIX-909: - Thanks for the comment, so i have to report this to the springsource guys, that they fix their Manifest Parser. White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: example.txt, patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- 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-806) changing the internal configuration of the archive plugin doesn't seem to be possible
[ https://issues.apache.org/jira/browse/FELIX-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-806 started by Stuart McCulloch. changing the internal configuration of the archive plugin doesn't seem to be possible - Key: FELIX-806 URL: https://issues.apache.org/jira/browse/FELIX-806 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Sylvain MARIE Assignee: Stuart McCulloch Fix For: maven-bundle-plugin-1.6.0 Hi, It does not seem to be possible to configure the maven-archive-plugin through configuration of the maven-bundle plugin. For example in order to remove the META-INF/maven dir in a resulting jar you can do the following conf of the maven-jar-plugin: pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive !--in order not to include the META-INF/maven directory-- addMavenDescriptorfalse/addMavenDescriptor /archive /configuration /plugin /plugins /pluginManagement This will result in the internal archive plugin being configured accordingly (i.e. without the META-INF/maven dir). However it is not possible to do the same with maven-bundle-plugin. Could this feature be integrated easily ? Thanks, Sylvain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-806) changing the internal configuration of the archive plugin doesn't seem to be possible
[ https://issues.apache.org/jira/browse/FELIX-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch resolved FELIX-806. Resolution: Fixed Fixed in trunk, but not yet deployed as a snapshot changing the internal configuration of the archive plugin doesn't seem to be possible - Key: FELIX-806 URL: https://issues.apache.org/jira/browse/FELIX-806 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Sylvain MARIE Assignee: Stuart McCulloch Fix For: maven-bundle-plugin-1.6.0 Hi, It does not seem to be possible to configure the maven-archive-plugin through configuration of the maven-bundle plugin. For example in order to remove the META-INF/maven dir in a resulting jar you can do the following conf of the maven-jar-plugin: pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive !--in order not to include the META-INF/maven directory-- addMavenDescriptorfalse/addMavenDescriptor /archive /configuration /plugin /plugins /pluginManagement This will result in the internal archive plugin being configured accordingly (i.e. without the META-INF/maven dir). However it is not possible to do the same with maven-bundle-plugin. Could this feature be integrated easily ? Thanks, Sylvain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-908) Unsynchronize access to bundle state inside BundleInfo by making the variable volatile
[
https://issues.apache.org/jira/browse/FELIX-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668798#action_12668798
]
Felix Meschberger commented on FELIX-908:
-
IIRC assignment of an int is an atomic operation (in contrast to long
assignment which is not atomic), so synchronization is not required at, either
the state field has the new or the old value, but never something in-between.
Also IIRC, the handling of volatile fields has changed with the Java 5 memory
model. So using a volatile field here might create an implicit dependency on
Java 5, right ?
I may be completely wrong here ;-)
Unsynchronize access to bundle state inside BundleInfo by making the variable
volatile
--
Key: FELIX-908
URL: https://issues.apache.org/jira/browse/FELIX-908
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: felix-1.2.1
Reporter: Anatoli Kazatchkov
Priority: Minor
Attachments: bundle_info.patch
Synchronized access to bundle state inside {{BundleInfo}} class creates an
unnecessary contention point in environments where {{bundle.getState()}} is
called a lot.
Declaring {{m_state}} variable volatile and removing synchronization from
{{setState()}} and {{getState()}} will do the trick.I will attach the patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-911) Potential deadlock between Bundle.stop() and BundleContext.registerService()
Potential deadlock between Bundle.stop() and BundleContext.registerService() Key: FELIX-911 URL: https://issues.apache.org/jira/browse/FELIX-911 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.4.1, felix-1.4.0, felix-1.2.2, felix-1.2.1 , felix-1.2.0, felix-1.0.4, felix-1.0.3, felix-1.0.1, felix-1.0.0, felix-1.6.0 Reporter: Felix Meschberger Fix For: felix-1.6.0 When a bundle tries to register a service (in thread T1) and the framework is at the same time stopping the bundle (in thread T2), it may be that thread T2 holds the bundle's lock. T1 trying to register the service is thus blocked since it cannot get the bundle lock. This may cause a deadlock in Felix SCR, which also works with synchronized instances: T1 may be SCR Actor thread starting a component and registering a service and thus holding a lock on the component instance. T2 may be the StartLevel service trying to stop the bundle, which causes the SCR to immediately stop the component. Since the component is locked by T1, T2 cannot acquire the lock. But since T2 already has the bundle lock, T1 cannot continue. The problem is, that in this concrete case it is the Component's activate() method which registers the service and not the SCR ComponentManager (the latter deadlock situation has been taken care of in FELIX-384). Looking at the code of Felix.registerService it looks like we could check for the bundle state before holding the bundle lock (and we could recheck after the lock just to be sure, if needed) and thus prevent the deadlock situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-908) Unsynchronize access to bundle state inside BundleInfo by making the variable volatile
[
https://issues.apache.org/jira/browse/FELIX-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668800#action_12668800
]
Stuart McCulloch commented on FELIX-908:
A plain int field is still different from a volatile int, because in the Java
Memory Model different threads could see different values in the same int field
because of caching, etc. (of course in reality this might never happen, it
depends on the actual architecture of the OS, etc.) Marking a field as volatile
implies a memory fence, and also stops the JIT from re-ordering statements,
which could also break assumptions about the field. So there is a difference,
but it's not always obvious.
Pre-Java 5 this was all a bit of a mess, and many JVMs didn't support volatile
longs properly - with Java 5 things are much better, and the semantics are
cleaner.
See http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html
for a nice overview and http://gee.cs.oswego.edu/dl/jmm/cookbook.html for the
gory details :)
Getting back to the issue, using volatile doesn't imply a dependency on Java 5
- unless you're relying on specific assumptions (like the double-checked
locking idiom). We already use volatile in other places in Felix that have high
contention, the question here is whether using volatile will break the bundle
state machine - will need to look more closely at this code to be sure. ie. if
only one thread is writing to the state and all other threads read it then
volatile is fine, the problem is if two or more threads need to both read and
write to it concurrently.
Unsynchronize access to bundle state inside BundleInfo by making the variable
volatile
--
Key: FELIX-908
URL: https://issues.apache.org/jira/browse/FELIX-908
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: felix-1.2.1
Reporter: Anatoli Kazatchkov
Priority: Minor
Attachments: bundle_info.patch
Synchronized access to bundle state inside {{BundleInfo}} class creates an
unnecessary contention point in environments where {{bundle.getState()}} is
called a lot.
Declaring {{m_state}} variable volatile and removing synchronization from
{{setState()}} and {{getState()}} will do the trick.I will attach the 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-911) Potential deadlock between Bundle.stop() and BundleContext.registerService()
[ https://issues.apache.org/jira/browse/FELIX-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-911: Attachment: FELIX-911.patch Proposed patch: Do the check before and after getting the bundle lock. Check before to fail early and check after to be sure, there was no bundle state change. Potential deadlock between Bundle.stop() and BundleContext.registerService() Key: FELIX-911 URL: https://issues.apache.org/jira/browse/FELIX-911 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.0.0, felix-1.0.1, felix-1.0.3, felix-1.0.4, felix-1.2.0, felix-1.2.1 , felix-1.2.2, felix-1.4.0, felix-1.4.1, felix-1.6.0 Reporter: Felix Meschberger Fix For: felix-1.6.0 Attachments: FELIX-911.patch When a bundle tries to register a service (in thread T1) and the framework is at the same time stopping the bundle (in thread T2), it may be that thread T2 holds the bundle's lock. T1 trying to register the service is thus blocked since it cannot get the bundle lock. This may cause a deadlock in Felix SCR, which also works with synchronized instances: T1 may be SCR Actor thread starting a component and registering a service and thus holding a lock on the component instance. T2 may be the StartLevel service trying to stop the bundle, which causes the SCR to immediately stop the component. Since the component is locked by T1, T2 cannot acquire the lock. But since T2 already has the bundle lock, T1 cannot continue. The problem is, that in this concrete case it is the Component's activate() method which registers the service and not the SCR ComponentManager (the latter deadlock situation has been taken care of in FELIX-384). Looking at the code of Felix.registerService it looks like we could check for the bundle state before holding the bundle lock (and we could recheck after the lock just to be sure, if needed) and thus prevent the deadlock situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-908) Unsynchronize access to bundle state inside BundleInfo by making the variable volatile
[
https://issues.apache.org/jira/browse/FELIX-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668803#action_12668803
]
Karl Pauls commented on FELIX-908:
--
Making the member volatile and removing the synchronization is fine in this
case (we only have on writer at a time).
Unsynchronize access to bundle state inside BundleInfo by making the variable
volatile
--
Key: FELIX-908
URL: https://issues.apache.org/jira/browse/FELIX-908
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: felix-1.2.1
Reporter: Anatoli Kazatchkov
Priority: Minor
Attachments: bundle_info.patch
Synchronized access to bundle state inside {{BundleInfo}} class creates an
unnecessary contention point in environments where {{bundle.getState()}} is
called a lot.
Declaring {{m_state}} variable volatile and removing synchronization from
{{setState()}} and {{getState()}} will do the trick.I will attach the patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-911) Potential deadlock between Bundle.stop() and BundleContext.registerService()
[ https://issues.apache.org/jira/browse/FELIX-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668804#action_12668804 ] karlpauls edited comment on FELIX-911 at 1/30/09 2:23 AM: --- We are currently reworking parts of the locking stuff around bundles in trunk. So perfect timing :-) I will discuss this with richard. I assume you tested your patch and it did make a difference, right? was (Author: karlpauls): We are currently reworking parts of the locking stuff around bundles in trunk. So perfect timing :-) I will discuss this with richard. I assume you tested your patch and i did make a difference, right? Potential deadlock between Bundle.stop() and BundleContext.registerService() Key: FELIX-911 URL: https://issues.apache.org/jira/browse/FELIX-911 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.0.0, felix-1.0.1, felix-1.0.3, felix-1.0.4, felix-1.2.0, felix-1.2.1 , felix-1.2.2, felix-1.4.0, felix-1.4.1, felix-1.6.0 Reporter: Felix Meschberger Fix For: felix-1.6.0 Attachments: FELIX-911.patch When a bundle tries to register a service (in thread T1) and the framework is at the same time stopping the bundle (in thread T2), it may be that thread T2 holds the bundle's lock. T1 trying to register the service is thus blocked since it cannot get the bundle lock. This may cause a deadlock in Felix SCR, which also works with synchronized instances: T1 may be SCR Actor thread starting a component and registering a service and thus holding a lock on the component instance. T2 may be the StartLevel service trying to stop the bundle, which causes the SCR to immediately stop the component. Since the component is locked by T1, T2 cannot acquire the lock. But since T2 already has the bundle lock, T1 cannot continue. The problem is, that in this concrete case it is the Component's activate() method which registers the service and not the SCR ComponentManager (the latter deadlock situation has been taken care of in FELIX-384). Looking at the code of Felix.registerService it looks like we could check for the bundle state before holding the bundle lock (and we could recheck after the lock just to be sure, if needed) and thus prevent the deadlock situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-911) Potential deadlock between Bundle.stop() and BundleContext.registerService()
[ https://issues.apache.org/jira/browse/FELIX-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668804#action_12668804 ] Karl Pauls commented on FELIX-911: -- We are currently reworking parts of the locking stuff around bundles in trunk. So perfect timing :-) I will discuss this with richard. I assume you tested your patch and i did make a difference, right? Potential deadlock between Bundle.stop() and BundleContext.registerService() Key: FELIX-911 URL: https://issues.apache.org/jira/browse/FELIX-911 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.0.0, felix-1.0.1, felix-1.0.3, felix-1.0.4, felix-1.2.0, felix-1.2.1 , felix-1.2.2, felix-1.4.0, felix-1.4.1, felix-1.6.0 Reporter: Felix Meschberger Fix For: felix-1.6.0 Attachments: FELIX-911.patch When a bundle tries to register a service (in thread T1) and the framework is at the same time stopping the bundle (in thread T2), it may be that thread T2 holds the bundle's lock. T1 trying to register the service is thus blocked since it cannot get the bundle lock. This may cause a deadlock in Felix SCR, which also works with synchronized instances: T1 may be SCR Actor thread starting a component and registering a service and thus holding a lock on the component instance. T2 may be the StartLevel service trying to stop the bundle, which causes the SCR to immediately stop the component. Since the component is locked by T1, T2 cannot acquire the lock. But since T2 already has the bundle lock, T1 cannot continue. The problem is, that in this concrete case it is the Component's activate() method which registers the service and not the SCR ComponentManager (the latter deadlock situation has been taken care of in FELIX-384). Looking at the code of Felix.registerService it looks like we could check for the bundle state before holding the bundle lock (and we could recheck after the lock just to be sure, if needed) and thus prevent the deadlock situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-909) White spaces in the Import-Bundle of theManifest file
[ https://issues.apache.org/jira/browse/FELIX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668819#action_12668819 ] Stuart McCulloch commented on FELIX-909: Yep - btw, as a workaround until they fix their parser you could either do this: Import-Bundle com.bla.api,com.bla.impl /Import-Bundle as whitespace is removed from the start and end (but never from the middle) ... or put your Import-Bundle list in another properties file and include it like so: _includesome.more.properties/_include where the some.more.properties file contains: Import-Bundle: com.bla.api,com.bla.impl but hopefully the dmServer parser will be fixed soon (though I'm surprised it doesn't handle whitespace) White spaces in the Import-Bundle of theManifest file - Key: FELIX-909 URL: https://issues.apache.org/jira/browse/FELIX-909 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-1.4.3 Reporter: Boris Burgstaller Attachments: example.txt, patch.txt We are using the Maven Bundle Plugin to generate our bundles and manifests. We are using the Import-Bundle and we noticed that it does not remove the white spaces coming from the xml if you format it like this: Import-Bundle com.bla.api, com.bla.impl /Import-Bundle We deploy some bundles on a springsource dm server, and if the manifest contains whitespaces and newlines, it falis to parse the file. could you please remove the white spaces for this property? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-869) SCR throws exception on invalidating a component with a reference to a service that was already unregistered
[ https://issues.apache.org/jira/browse/FELIX-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-869. --- Resolution: Duplicate Assignee: Felix Meschberger Closing this since it is a duplicate. SCR throws exception on invalidating a component with a reference to a service that was already unregistered Key: FELIX-869 URL: https://issues.apache.org/jira/browse/FELIX-869 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.4.0, felix-1.4.1 Environment: Felix 1.4.1, SCR 1.0.6 Reporter: Heiko Seeberger Assignee: Felix Meschberger Fix For: felix-1.6.0 Simple scenario: A component references (statically, 1:1, look-up strategy) a service. When the bundle providing that service is stopped and hence the reference no longer satisfied, stopping the bundle providing the component will result in the below exception. I checked with Equinox 3.4.1 and there everything is working fine. ERROR: net.eclipsetraining.backoffice.tplan.app.swing (9): [net.eclipsetraining.backoffice.tplan.ui.swing.internal.Component] BundleComponentActivator : Exception invalidating java.lang.IllegalStateException: The service registration is no longer valid. at org.apache.felix.framework.ServiceRegistrationImpl.getReference(ServiceRegistrationImpl.java:88) at org.apache.felix.framework.ServiceReferenceImpl.hashCode(ServiceReferenceImpl.java:87) at java.util.HashMap.removeEntryForKey(HashMap.java:548) at java.util.HashMap.remove(HashMap.java:538) at java.util.Collections$SynchronizedMap.remove(Collections.java:1982) at org.apache.felix.scr.impl.DependencyManager.ungetService(DependencyManager.java:578) at org.apache.felix.scr.impl.DependencyManager.close(DependencyManager.java:374) at org.apache.felix.scr.impl.AbstractComponentManager.disableInternal(AbstractComponentManager.java:589) at org.apache.felix.scr.impl.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:616) at org.apache.felix.scr.impl.AbstractComponentManager.dispose(AbstractComponentManager.java:272) at org.apache.felix.scr.impl.ImmediateComponentManager.dispose(ImmediateComponentManager.java:120) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:258) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:264) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:177) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:745) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:674) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:587) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3629) at org.apache.felix.framework.Felix._stopBundle(Felix.java:2076) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2034) at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:418) at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:405) at org.apache.felix.shell.impl.StopCommandImpl.execute(StopCommandImpl.java:70) at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276) at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167) at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-869) SCR throws exception on invalidating a component with a reference to a service that was already unregistered
[ https://issues.apache.org/jira/browse/FELIX-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-869: Component/s: (was: Declarative Services (SCR)) Framework Affects Version/s: (was: scr-1.0.6) felix-1.4.0 felix-1.4.1 Fix Version/s: felix-1.6.0 Reassign this issue to the framework component and mark it as happening with 1.4.0 and 1.4.1. Earlier versions are not succeptible to this issue, since these did not throw the IllegalStateException. SCR throws exception on invalidating a component with a reference to a service that was already unregistered Key: FELIX-869 URL: https://issues.apache.org/jira/browse/FELIX-869 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.4.0, felix-1.4.1 Environment: Felix 1.4.1, SCR 1.0.6 Reporter: Heiko Seeberger Fix For: felix-1.6.0 Simple scenario: A component references (statically, 1:1, look-up strategy) a service. When the bundle providing that service is stopped and hence the reference no longer satisfied, stopping the bundle providing the component will result in the below exception. I checked with Equinox 3.4.1 and there everything is working fine. ERROR: net.eclipsetraining.backoffice.tplan.app.swing (9): [net.eclipsetraining.backoffice.tplan.ui.swing.internal.Component] BundleComponentActivator : Exception invalidating java.lang.IllegalStateException: The service registration is no longer valid. at org.apache.felix.framework.ServiceRegistrationImpl.getReference(ServiceRegistrationImpl.java:88) at org.apache.felix.framework.ServiceReferenceImpl.hashCode(ServiceReferenceImpl.java:87) at java.util.HashMap.removeEntryForKey(HashMap.java:548) at java.util.HashMap.remove(HashMap.java:538) at java.util.Collections$SynchronizedMap.remove(Collections.java:1982) at org.apache.felix.scr.impl.DependencyManager.ungetService(DependencyManager.java:578) at org.apache.felix.scr.impl.DependencyManager.close(DependencyManager.java:374) at org.apache.felix.scr.impl.AbstractComponentManager.disableInternal(AbstractComponentManager.java:589) at org.apache.felix.scr.impl.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:616) at org.apache.felix.scr.impl.AbstractComponentManager.dispose(AbstractComponentManager.java:272) at org.apache.felix.scr.impl.ImmediateComponentManager.dispose(ImmediateComponentManager.java:120) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:258) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:264) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:177) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:745) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:674) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:587) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3629) at org.apache.felix.framework.Felix._stopBundle(Felix.java:2076) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2034) at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:418) at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:405) at org.apache.felix.shell.impl.StopCommandImpl.execute(StopCommandImpl.java:70) at org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276) at org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167) at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-911) Potential deadlock between Bundle.stop() and BundleContext.registerService()
[ https://issues.apache.org/jira/browse/FELIX-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668854#action_12668854 ] Felix Meschberger commented on FELIX-911: - Yes, I tested it and I get an IllegalStateException now, which is then handled in the component code, which tries to register. Next the component lock is released in SCR Actor Thread T1 and the StartLevel service can continue with the shutdown in T2. Potential deadlock between Bundle.stop() and BundleContext.registerService() Key: FELIX-911 URL: https://issues.apache.org/jira/browse/FELIX-911 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.0.0, felix-1.0.1, felix-1.0.3, felix-1.0.4, felix-1.2.0, felix-1.2.1 , felix-1.2.2, felix-1.4.0, felix-1.4.1, felix-1.6.0 Reporter: Felix Meschberger Fix For: felix-1.6.0 Attachments: FELIX-911.patch When a bundle tries to register a service (in thread T1) and the framework is at the same time stopping the bundle (in thread T2), it may be that thread T2 holds the bundle's lock. T1 trying to register the service is thus blocked since it cannot get the bundle lock. This may cause a deadlock in Felix SCR, which also works with synchronized instances: T1 may be SCR Actor thread starting a component and registering a service and thus holding a lock on the component instance. T2 may be the StartLevel service trying to stop the bundle, which causes the SCR to immediately stop the component. Since the component is locked by T1, T2 cannot acquire the lock. But since T2 already has the bundle lock, T1 cannot continue. The problem is, that in this concrete case it is the Component's activate() method which registers the service and not the SCR ComponentManager (the latter deadlock situation has been taken care of in FELIX-384). Looking at the code of Felix.registerService it looks like we could check for the bundle state before holding the bundle lock (and we could recheck after the lock just to be sure, if needed) and thus prevent the deadlock situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release dependencymanager 2.0.0
2009/1/29 Marcel Offermans marcel.offerm...@luminis.nl Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/http://people.apache.org/%7Emarrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. Hi Marcel, Where are the source tars and zips, etc..? Normally the release process generates these for you. I can see the release tagged in svn, but we have provide source distributions as well as binaries and therefore we need to vote on these as well. ( for example, see: http://people.apache.org/~fmeschbe/org.apache.felix.configadmin-1.0.10/ ) The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel -- Cheers, Stuart
Re: [VOTE] Release configadmin 1.0.10
2009/1/28 Felix Meschberger fmesc...@gmail.com Hi, I've compiled the release candidate for the Configuration Admin release 1.0.10 and put it up here: http://people.apache.org/~fmeschbe/org.apache.felix.configadmin-1.0.10/http://people.apache.org/%7Efmeschbe/org.apache.felix.configadmin-1.0.10/ The KEYS file for verifying the signature is also in this directory. md5 and sha1 files are maven generated and modified to include the name of the file to which they belong. This release contains fixes for the following bugs (B) and improvements (I) : [FELIX-889] - Arrays of primitives not supported by... (B) [FELIX-890] - Configuration.getProperty returns a Dictionary... (B) [FELIX-903] - Add functionality to limit log output in the... (I) This release so close to the previous release is needed because the 1.0.8 release introduced an implementation change (FELIX-879), which may break existing clients expecting Vector properties, where 1.0.8 would return Collection properties, which are not Vector instances. This also revealed to bigger problems which are fixed by FELIX-889 and FELIX-890. So, please check the release and cast your votes - the vote will be open for 72 hours. +1 Regards Felix -- Cheers, Stuart
Re: [VOTE] Release configadmin 1.0.10
+1 Regards, Clement On 30.01.2009, at 15:34, Stuart McCulloch wrote: 2009/1/28 Felix Meschberger fmesc...@gmail.com Hi, I've compiled the release candidate for the Configuration Admin release 1.0.10 and put it up here: http://people.apache.org/~fmeschbe/org.apache.felix.configadmin-1.0.10/ http://people.apache.org/%7Efmeschbe/org.apache.felix.configadmin-1.0.10/ The KEYS file for verifying the signature is also in this directory. md5 and sha1 files are maven generated and modified to include the name of the file to which they belong. This release contains fixes for the following bugs (B) and improvements (I) : [FELIX-889] - Arrays of primitives not supported by... (B) [FELIX-890] - Configuration.getProperty returns a Dictionary... (B) [FELIX-903] - Add functionality to limit log output in the... (I) This release so close to the previous release is needed because the 1.0.8 release introduced an implementation change (FELIX-879), which may break existing clients expecting Vector properties, where 1.0.8 would return Collection properties, which are not Vector instances. This also revealed to bigger problems which are fixed by FELIX-889 and FELIX-890. So, please check the release and cast your votes - the vote will be open for 72 hours. +1 Regards Felix -- Cheers, Stuart
[Vote] Release iPOJO 1.2.0 - Step 2
Hi all, As we're in the release/voting season, I cut the second step of the iPOJO framework release (composite + external handlers). Six artifacts compose this second step. The RCs are available here: http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ MD5 and SHA1 files are maven generated (and beautified). So please check the releases and cast your votes - the vote will be open until the end of the next week (as there are several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because Thanks and Regards Clement
Re: [VOTE] Release configadmin 1.0.10
+1 regards, Karl On Wed, Jan 28, 2009 at 4:37 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, I've compiled the release candidate for the Configuration Admin release 1.0.10 and put it up here: http://people.apache.org/~fmeschbe/org.apache.felix.configadmin-1.0.10/ The KEYS file for verifying the signature is also in this directory. md5 and sha1 files are maven generated and modified to include the name of the file to which they belong. This release contains fixes for the following bugs (B) and improvements (I) : [FELIX-889] - Arrays of primitives not supported by... (B) [FELIX-890] - Configuration.getProperty returns a Dictionary... (B) [FELIX-903] - Add functionality to limit log output in the... (I) This release so close to the previous release is needed because the 1.0.8 release introduced an implementation change (FELIX-879), which may break existing clients expecting Vector properties, where 1.0.8 would return Collection properties, which are not Vector instances. This also revealed to bigger problems which are fixed by FELIX-889 and FELIX-890. So, please check the release and cast your votes - the vote will be open for 72 hours. Regards Felix -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release dependencymanager 2.0.0
Hi, -1 (on procedural ground) Since Apache is about open source, all releases are primarily source releases. And it is in fact the source release, which is to be voted upon. The binary packages are just convenience (though I admit that these days, I only care marginally for the source releases, generally). Regards Felix Marcel Offermans schrieb: Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
Re: [VOTE] Release dependencymanager 2.0.0
Procecurally, should I cut a 2.0.1 release candidate now, or can I just add those missing packages (which I just did not copy to my home directory, but I already have them)? Greetings, Marcel On Jan 30, 2009, at 16:01 , Felix Meschberger wrote: Hi, -1 (on procedural ground) Since Apache is about open source, all releases are primarily source releases. And it is in fact the source release, which is to be voted upon. The binary packages are just convenience (though I admit that these days, I only care marginally for the source releases, generally). Regards Felix Marcel Offermans schrieb: Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
Re: [VOTE] Release dependencymanager 2.0.0
2009/1/30 Marcel Offermans marcel.offerm...@luminis.nl Procecurally, should I cut a 2.0.1 release candidate now, or can I just add those missing packages (which I just did not copy to my home directory, but I already have them)? personally I'm ok with continuing the vote once they've been uploaded (as it's already been tagged and I can cross-check the sources, etc.) but I don't know the official procedure... Greetings, Marcel On Jan 30, 2009, at 16:01 , Felix Meschberger wrote: Hi, -1 (on procedural ground) Since Apache is about open source, all releases are primarily source releases. And it is in fact the source release, which is to be voted upon. The binary packages are just convenience (though I admit that these days, I only care marginally for the source releases, generally). Regards Felix Marcel Offermans schrieb: Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/http://people.apache.org/%7Emarrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel -- Cheers, Stuart
Re: [VOTE] Release dependencymanager 2.0.0
Hi, Marcel Offermans schrieb: Procecurally, should I cut a 2.0.1 release candidate now, or can I just add those missing packages (which I just did not copy to my home directory, but I already have them)? Good question. I would say, that in this case, it might be ok to just also upload the missing packages. Regards Felix Greetings, Marcel On Jan 30, 2009, at 16:01 , Felix Meschberger wrote: Hi, -1 (on procedural ground) Since Apache is about open source, all releases are primarily source releases. And it is in fact the source release, which is to be voted upon. The binary packages are just convenience (though I admit that these days, I only care marginally for the source releases, generally). Regards Felix Marcel Offermans schrieb: Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
Re: [Vote] Release iPOJO 1.2.0 - Step 2
2009/1/30 Clement Escoffier clement.escoff...@gmail.com Hi all, As we're in the release/voting season, I cut the second step of the iPOJO framework release (composite + external handlers). Six artifacts compose this second step. The RCs are available here: http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ MD5 and SHA1 files are maven generated (and beautified). So please check the releases and cast your votes - the vote will be open until the end of the next week (as there are several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because +1 ... all the checksums and signatures pass, project archives pass RAT Thanks and Regards Clement -- Cheers, Stuart
Re: [VOTE] Release dependencymanager 2.0.0
On Fri, Jan 30, 2009 at 4:33 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Marcel Offermans schrieb: Procecurally, should I cut a 2.0.1 release candidate now, or can I just add those missing packages (which I just did not copy to my home directory, but I already have them)? Good question. I would say, that in this case, it might be ok to just also upload the missing packages. Sounds ok to me assuming we reset the vote (i.e., votes cast already are not counted) as they can not actually have verified the release... regards, Karl Regards Felix Greetings, Marcel On Jan 30, 2009, at 16:01 , Felix Meschberger wrote: Hi, -1 (on procedural ground) Since Apache is about open source, all releases are primarily source releases. And it is in fact the source release, which is to be voted upon. The binary packages are just convenience (though I admit that these days, I only care marginally for the source releases, generally). Regards Felix Marcel Offermans schrieb: Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release dependencymanager 2.0.0
2009/1/30 Karl Pauls karlpa...@gmail.com On Fri, Jan 30, 2009 at 4:33 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Marcel Offermans schrieb: Procecurally, should I cut a 2.0.1 release candidate now, or can I just add those missing packages (which I just did not copy to my home directory, but I already have them)? Good question. I would say, that in this case, it might be ok to just also upload the missing packages. Sounds ok to me assuming we reset the vote (i.e., votes cast already are not counted) as they can not actually have verified the release... agree - I think canceling this vote thread and starting a new one when the sources are there should be enough regards, Karl Regards Felix Greetings, Marcel On Jan 30, 2009, at 16:01 , Felix Meschberger wrote: Hi, -1 (on procedural ground) Since Apache is about open source, all releases are primarily source releases. And it is in fact the source release, which is to be voted upon. The binary packages are just convenience (though I admit that these days, I only care marginally for the source releases, generally). Regards Felix Marcel Offermans schrieb: Hello all, This is the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/http://people.apache.org/%7Emarrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel -- Karl Pauls karlpa...@gmail.com -- Cheers, Stuart
Re: [Vote] Release iPOJO 1.2.0 - Step 2
+1 Just a question: Is there a license attributed with the ga.js files ? if so, we should make sure, that it is properly listed in the NOTICE file. Regards Felix Clement Escoffier schrieb: Hi all, As we're in the release/voting season, I cut the second step of the iPOJO framework release (composite + external handlers). Six artifacts compose this second step. The RCs are available here: http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ MD5 and SHA1 files are maven generated (and beautified). So please check the releases and cast your votes - the vote will be open until the end of the next week (as there are several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because Thanks and Regards Clement
Re: [Vote] Release iPOJO 1.2.0 - Step 2
2009/1/31 Felix Meschberger fmesc...@gmail.com +1 Just a question: Is there a license attributed with the ga.js files ? if so, we should make sure, that it is properly listed in the NOTICE file. afaik those are from the online docs on the website - if you do a save page as... complete from firefox then it contains a ga.js file, so I guess this might count as a generated artifact given that it is produced via the wiki? if so then IMHO it doesn't need a listing in the notice (it's not needed to run the release, isn't part of the source) Regards Felix Clement Escoffier schrieb: Hi all, As we're in the release/voting season, I cut the second step of the iPOJO framework release (composite + external handlers). Six artifacts compose this second step. The RCs are available here: http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ MD5 and SHA1 files are maven generated (and beautified). So please check the releases and cast your votes - the vote will be open until the end of the next week (as there are several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because Thanks and Regards Clement -- Cheers, Stuart
Re: [VOTE] Release configadmin 1.0.10
+1 I noticed in the source releases there is an extraneous configadmin directory in the root of the project directory. I don't know why it is there, but I bet it wasn't intended. - richard Felix Meschberger wrote: Hi, I've compiled the release candidate for the Configuration Admin release 1.0.10 and put it up here: http://people.apache.org/~fmeschbe/org.apache.felix.configadmin-1.0.10/ The KEYS file for verifying the signature is also in this directory. md5 and sha1 files are maven generated and modified to include the name of the file to which they belong. This release contains fixes for the following bugs (B) and improvements (I) : [FELIX-889] - Arrays of primitives not supported by... (B) [FELIX-890] - Configuration.getProperty returns a Dictionary... (B) [FELIX-903] - Add functionality to limit log output in the... (I) This release so close to the previous release is needed because the 1.0.8 release introduced an implementation change (FELIX-879), which may break existing clients expecting Vector properties, where 1.0.8 would return Collection properties, which are not Vector instances. This also revealed to bigger problems which are fixed by FELIX-889 and FELIX-890. So, please check the release and cast your votes - the vote will be open for 72 hours. Regards Felix
[jira] Created: (FELIX-912) Improve default Export-Package / Private-Package settings by scanning the project source
Improve default Export-Package / Private-Package settings by scanning the project source Key: FELIX-912 URL: https://issues.apache.org/jira/browse/FELIX-912 Project: Felix Issue Type: New Feature Components: Maven Bundle Plugin Reporter: Stuart McCulloch Assignee: Stuart McCulloch Priority: Minor Fix For: maven-bundle-plugin-1.6.0 The current bundleplugin default for Export-Package is based on the bundle symbolic name, which in turn is based on the Maven groupId and artifactId. While this works for a lot of projects that use the primary package as the bundle symbolic name (or for the Maven metadata) it isn't perfect. I'm thinking of enhancing the bundleplugin to look at the project source to find the main packages in the project, which could be used as the default Export-Package (or possibly Private-Package too). The overall goal is to allow people to take a Maven project, change the packaging from jar to bundle and they'll get the same content. At the moment, because the bundle content is derived from the Export-Package / Private-Package / Include-Resource instructions this may not be the case. We already do this sort of thing for Maven resources - Include-Resource, so there is a precedent... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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 updated FELIX-905: --- Attachment: rfc126_eventhook_findhook.patch Attached is a patch that implements the FindHook and EventHook (the new name for the PublishHook). I also wrote some unit tests for the more complex parts, but no unit tests for the really simple bits are included yet. If the unit tests are going to be committed, I'll be more than happy to provide additional tests for the rest of the changes. BTW I verified the behaviour of these hooks with the implementation in the Equinox trunk: the behaviour is consitent. 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 Attachments: 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-906) Felix needs an RFC 126 EventHook
[ https://issues.apache.org/jira/browse/FELIX-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668928#action_12668928 ] David Bosschaert commented on FELIX-906: Patch for the EventHook (and FindHook) attached to FELIX-905. 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 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.
[CANCELLED] [VOTE] Release dependencymanager 2.0.0
Due to the fact that I forgot to include the source artifacts, as Stuart pointed out, I'm cancelling the current vote for the release. I'll be posting a new vote, as recommended, in a minute. Greetings, Marcel
Re: [Vote] Release iPOJO 1.2.0 - Step 2
Hi Sent from my iPhone On 30.01.2009, at 17:13, Stuart McCulloch mccu...@gmail.com wrote: 2009/1/31 Felix Meschberger fmesc...@gmail.com +1 Just a question: Is there a license attributed with the ga.js files ? if so, we should make sure, that it is properly listed in the NOTICE file. afaik those are from the online docs on the website - if you do a save page as... complete from firefox then it contains a ga.js file, so I guess this might count as a generated artifact given that it is produced via the wiki? if so then IMHO it doesn't need a listing in the notice (it's not needed to run the release, isn't part of the source) Exactly, I just save the web page with Firefox, and to be honest I never deeply analyze the result. I agree with Stuart. As the file is not related to the source, IMHO, it has not to be listed in the notice file. If it has to be listed, we have to update the release management page, as several projects get their doc by just saving the page. Regards, Clement Regards Felix Clement Escoffier schrieb: Hi all, As we're in the release/voting season, I cut the second step of the iPOJO framework release (composite + external handlers). Six artifacts compose this second step. The RCs are available here: http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ MD5 and SHA1 files are maven generated (and beautified). So please check the releases and cast your votes - the vote will be open until the end of the next week (as there are several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because Thanks and Regards Clement -- Cheers, Stuart
[VOTE] Release of the dependencymanager 2.0.0
Hello all, I'm opening a new vote for the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
Re: [VOTE] Release of the dependencymanager 2.0.0
Thanks for restarting the vote. Here is my +1 Two files (SerialExecutor, State) of the dependencymanager bundle have missing license headers, this should be fixed for future releases. Regards Felix Marcel Offermans schrieb: Hello all, I'm opening a new vote for the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
Re: [VOTE] Release of the dependencymanager 2.0.0
+1 /pierre Marcel Offermans wrote: Hello all, I'm opening a new vote for the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
Re: [jira] Created: (FELIX-826) Enable the remote shell to bind to an IP and make 127.0.0.1 the default
I am willing to patch it. I am not too concerned with the backwards compatibility issue, since it is easy to resolve. If no one objects, I will patch it next week. However, in my mind I consider Felix the owner of this, so I would rather have him do it. :-D - richard Sahoo wrote: Is anyone going to apply this patch? Thanks, Sahoo Peter wrote: Hi all, In my personal opinion, although backward compatibility is important in this case I would do it for two main reasons: 1) In most cases this will be the desired behaviour. 2) In the cases where it is not, it still does not break the application, but only the administration of the application, so the impact of the change is not very big. Also the change is pretty easy to detect and if this is documented on the webpage very fast to correct. Regards Peter Felix Meschberger schrieb: Hi all, Thanks Peter for providing this patch. I think the proposed patch is perfectly valid and good idea to start with. My worries are with existing setups: in a backwards compatibility scenario, I would bind to 0.0.0.0 by default instead of just localhost. In a security-by-default scenario I would agree with Peter, that remote.shell should bind to localhost only. Any opinions on what scenario -- compatible binding 0.0.0.0 or security binding 127.0.0.1 -- going forward ? Regards and Thanks Felix Peter Triller (JIRA) schrieb: Enable the remote shell to bind to an IP and make 127.0.0.1 the default --- Key: FELIX-826 URL: https://issues.apache.org/jira/browse/FELIX-826 Project: Felix Issue Type: New Feature Components: Remote Shell Affects Versions: shell.remote-1.0.2 Reporter: Peter Triller
Re: [Vote] Release iPOJO 1.2.0 - Step 2
+1 Regarding the ga.js I'd say its generated and wouldn't add it to the notice. regards, Karl On Fri, Jan 30, 2009 at 7:41 PM, Clement Escoffier clement.escoff...@gmail.com wrote: Hi Sent from my iPhone On 30.01.2009, at 17:13, Stuart McCulloch mccu...@gmail.com wrote: 2009/1/31 Felix Meschberger fmesc...@gmail.com +1 Just a question: Is there a license attributed with the ga.js files ? if so, we should make sure, that it is properly listed in the NOTICE file. afaik those are from the online docs on the website - if you do a save page as... complete from firefox then it contains a ga.js file, so I guess this might count as a generated artifact given that it is produced via the wiki? if so then IMHO it doesn't need a listing in the notice (it's not needed to run the release, isn't part of the source) Exactly, I just save the web page with Firefox, and to be honest I never deeply analyze the result. I agree with Stuart. As the file is not related to the source, IMHO, it has not to be listed in the notice file. If it has to be listed, we have to update the release management page, as several projects get their doc by just saving the page. Regards, Clement Regards Felix Clement Escoffier schrieb: Hi all, As we're in the release/voting season, I cut the second step of the iPOJO framework release (composite + external handlers). Six artifacts compose this second step. The RCs are available here: http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.composite/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.eventadmin/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.jmx/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.temporal/1.2.0/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/http://people.apache.org/%7Eclement/releases/org/apache/felix/org.apache.felix.ipojo.handler.whiteboard/1.2.0/ MD5 and SHA1 files are maven generated (and beautified). So please check the releases and cast your votes - the vote will be open until the end of the next week (as there are several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because Thanks and Regards Clement -- Cheers, Stuart -- Karl Pauls karlpa...@gmail.com
[jira] Commented: (FELIX-826) Enable the remote shell to bind to an IP and make 127.0.0.1 the default
[ https://issues.apache.org/jira/browse/FELIX-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669064#action_12669064 ] Felix Meschberger commented on FELIX-826: - I have applied the patch in Rev. 739440. Enable the remote shell to bind to an IP and make 127.0.0.1 the default --- Key: FELIX-826 URL: https://issues.apache.org/jira/browse/FELIX-826 Project: Felix Issue Type: New Feature Components: Remote Shell Affects Versions: shell.remote-1.0.2 Reporter: Peter Triller Assignee: Felix Meschberger Attachments: ip-bind.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-826) Enable the remote shell to bind to an IP and make 127.0.0.1 the default
[ https://issues.apache.org/jira/browse/FELIX-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-826: --- Assignee: Felix Meschberger Enable the remote shell to bind to an IP and make 127.0.0.1 the default --- Key: FELIX-826 URL: https://issues.apache.org/jira/browse/FELIX-826 Project: Felix Issue Type: New Feature Components: Remote Shell Affects Versions: shell.remote-1.0.2 Reporter: Peter Triller Assignee: Felix Meschberger Attachments: ip-bind.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release configadmin 1.0.10
Hi Richard, Richard S. Hall schrieb: +1 I noticed in the source releases there is an extraneous configadmin directory in the root of the project directory. I don't know why it is there, but I bet it wasn't intended. This must have been an oops in Rev. 735651, cannot remember how this came to live. Removing it from the repository so it will not be in the next source release. Regards Felix - richard Felix Meschberger wrote: Hi, I've compiled the release candidate for the Configuration Admin release 1.0.10 and put it up here: http://people.apache.org/~fmeschbe/org.apache.felix.configadmin-1.0.10/ The KEYS file for verifying the signature is also in this directory. md5 and sha1 files are maven generated and modified to include the name of the file to which they belong. This release contains fixes for the following bugs (B) and improvements (I) : [FELIX-889] - Arrays of primitives not supported by... (B) [FELIX-890] - Configuration.getProperty returns a Dictionary... (B) [FELIX-903] - Add functionality to limit log output in the... (I) This release so close to the previous release is needed because the 1.0.8 release introduced an implementation change (FELIX-879), which may break existing clients expecting Vector properties, where 1.0.8 would return Collection properties, which are not Vector instances. This also revealed to bigger problems which are fixed by FELIX-889 and FELIX-890. So, please check the release and cast your votes - the vote will be open for 72 hours. Regards Felix
[jira] Commented: (FELIX-826) Enable the remote shell to bind to an IP and make 127.0.0.1 the default
[ https://issues.apache.org/jira/browse/FELIX-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669068#action_12669068 ] Felix Meschberger commented on FELIX-826: - Deployed SNAPSHOT version 1.0.3-20090130.225318-1 to the snapshot repository and updated the Remote Shell Documentation page at [1] [1] http://felix.apache.org/site/apache-felix-remote-shell.html Enable the remote shell to bind to an IP and make 127.0.0.1 the default --- Key: FELIX-826 URL: https://issues.apache.org/jira/browse/FELIX-826 Project: Felix Issue Type: New Feature Components: Remote Shell Affects Versions: shell.remote-1.0.2 Reporter: Peter Triller Assignee: Felix Meschberger Attachments: ip-bind.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-826) Enable the remote shell to bind to an IP and make 127.0.0.1 the default
[ https://issues.apache.org/jira/browse/FELIX-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-826: Fix Version/s: shell.remote-1.0.4 Enable the remote shell to bind to an IP and make 127.0.0.1 the default --- Key: FELIX-826 URL: https://issues.apache.org/jira/browse/FELIX-826 Project: Felix Issue Type: New Feature Components: Remote Shell Affects Versions: shell.remote-1.0.2 Reporter: Peter Triller Assignee: Felix Meschberger Fix For: shell.remote-1.0.4 Attachments: ip-bind.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of the dependencymanager 2.0.0
+1 (non binding vote) On Fri, Jan 30, 2009 at 8:42 PM, Pierre De Rop pierre.de_...@alcatel-lucent.fr wrote: +1 /pierre Marcel Offermans wrote: Hello all, I'm opening a new vote for the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel -- Toni Menzel Software Developer t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
Re: [jira] Created: (FELIX-826) Enable the remote shell to bind to an IP and make 127.0.0.1 the default
Felix Meschberger wrote: Hi, Richard S. Hall schrieb: I am willing to patch it. I am not too concerned with the backwards compatibility issue, since it is easy to resolve. If no one objects, I will patch it next week. However, in my mind I consider Felix the owner of this, so I would rather have him do it. :-D Done. Will also update the doc page. Wow, that actually worked. I will have to do that more often... ;-) - richard Regards Felix - richard Sahoo wrote: Is anyone going to apply this patch? Thanks, Sahoo Peter wrote: Hi all, In my personal opinion, although backward compatibility is important in this case I would do it for two main reasons: 1) In most cases this will be the desired behaviour. 2) In the cases where it is not, it still does not break the application, but only the administration of the application, so the impact of the change is not very big. Also the change is pretty easy to detect and if this is documented on the webpage very fast to correct. Regards Peter Felix Meschberger schrieb: Hi all, Thanks Peter for providing this patch. I think the proposed patch is perfectly valid and good idea to start with. My worries are with existing setups: in a backwards compatibility scenario, I would bind to 0.0.0.0 by default instead of just localhost. In a security-by-default scenario I would agree with Peter, that remote.shell should bind to localhost only. Any opinions on what scenario -- compatible binding 0.0.0.0 or security binding 127.0.0.1 -- going forward ? Regards and Thanks Felix Peter Triller (JIRA) schrieb: Enable the remote shell to bind to an IP and make 127.0.0.1 the default --- Key: FELIX-826 URL: https://issues.apache.org/jira/browse/FELIX-826 Project: Felix Issue Type: New Feature Components: Remote Shell Affects Versions: shell.remote-1.0.2 Reporter: Peter Triller
Re: [VOTE] Release of the dependencymanager 2.0.0
-1 None of the artifacts (.jar, -project, -bin) contain any LICENSE nor NOTICE files. Furthermore, as mentioned by Felix Meschberger at least two files have missing license headers (which I consider a blocker as well). regards, Karl p.s.: Additionally, I don't think the key that was used for signing is in the KEYS file. On Fri, Jan 30, 2009 at 7:42 PM, Marcel Offermans marcel.offerm...@luminis.nl wrote: Hello all, I'm opening a new vote for the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release of the dependencymanager 2.0.0
Yes, I +1 the -1... I know the release process is a pain, but we need to re-do this one. Luckily, the fixes are easy. - richard Karl Pauls wrote: -1 None of the artifacts (.jar, -project, -bin) contain any LICENSE nor NOTICE files. Furthermore, as mentioned by Felix Meschberger at least two files have missing license headers (which I consider a blocker as well). regards, Karl p.s.: Additionally, I don't think the key that was used for signing is in the KEYS file. On Fri, Jan 30, 2009 at 7:42 PM, Marcel Offermans marcel.offerm...@luminis.nl wrote: Hello all, I'm opening a new vote for the first release candidate for the dependency manager and its optional shell command bundle. I've compiled everything and put it up for testing and checking here: http://people.apache.org/~marrs/dependencymanager-2.0.0/ The KEYS file for verifying the signature is also in this directory and the checksum files should have the correct format. The main reason for naming this release 2.0.0 is that there have been many 1.x versions and snapshots out there, so to avoid any confusion I'm starting with 2.0.0. Please check the release and cast your votes, the vote will be open for at least 72 hours: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Greetings, Marcel
[jira] Resolved: (FELIX-910) Framework may ignore framework startlevel on startup
[
https://issues.apache.org/jira/browse/FELIX-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-910.
---
Resolution: Fixed
Assignee: Richard S. Hall
I committed a variant of your patch. There was no need to play around with
getting the value since we were holding the lock the entire time, so I just
changed the patch to just use method calls. I think this was just a refactoring
omission.
Framework may ignore framework startlevel on startup
Key: FELIX-910
URL: https://issues.apache.org/jira/browse/FELIX-910
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: felix-1.6.0
Reporter: Felix Meschberger
Assignee: Richard S. Hall
Fix For: felix-1.6.0
Attachments: FELIX-910.patch
When calling the Felix.start() method, a check is done, whether the init
method must be called. After that, the state is checked again to see whether
it is STARTING and hence the framework target startlevel should be set
according to the org.osgi.framework.startlevel property:
final int state = getState();
if ((state == Bundle.INSTALLED) || (state == Bundle.RESOLVED)) {
init();
}
if (state == Bundle.STARTING) {
Unfortunately this code is broken, since the state variable is still
INSTALLED or RESOLVED after the init() method has been called even though the
actual state really is STARTING.
A workaround for client code encountering this issue, is to call the init()
method itself as in :
Felix felix = new Felix(map);
felix.init();
felix.start();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-908) Unsynchronize access to bundle state inside BundleInfo by making the variable volatile
[
https://issues.apache.org/jira/browse/FELIX-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669121#action_12669121
]
Richard S. Hall commented on FELIX-908:
---
Out of curiosity, what scenario is causing Bundle.getState() to get invoked so
often?
Unsynchronize access to bundle state inside BundleInfo by making the variable
volatile
--
Key: FELIX-908
URL: https://issues.apache.org/jira/browse/FELIX-908
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: felix-1.2.1
Reporter: Anatoli Kazatchkov
Priority: Minor
Attachments: bundle_info.patch
Synchronized access to bundle state inside {{BundleInfo}} class creates an
unnecessary contention point in environments where {{bundle.getState()}} is
called a lot.
Declaring {{m_state}} variable volatile and removing synchronization from
{{setState()}} and {{getState()}} will do the trick.I will attach the patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-913) IllegalStateException thrown on startup due to OsgiManager trying to unregister a not yet registered resource
IllegalStateException thrown on startup due to OsgiManager trying to unregister
a not yet registered resource
-
Key: FELIX-913
URL: https://issues.apache.org/jira/browse/FELIX-913
Project: Felix
Issue Type: Bug
Components: Web Console
Affects Versions: webconsole-1.2.2
Environment: org.eclipse.osgi_3.4.2.R34x_v20080826-1230
org.eclipse.equinox.cm_1.0.0.v20080509-1800
org.ops4j.pax.web.service_0.5.1
org.apache.felix.webconsole_1.2.2
Reporter: Dieter Wimberger
Priority: Blocker
ERROR root -
ResourceModel{id=org.ops4j.pax.web.service.internal.model.ResourceModel-3,urlPatterns=[/system/console/res/*],alias=/system/console/res,servlet=org.ops4j.pax.web.service.internal.resourceserv...@1bcb7c74,initParams={},context=ContextModel{,id=org.ops4j.pax.web.service.internal.model.ContextModel-1,name=,httpcontext=org.apache.felix.webconsole.internal.servlet.osgimanagerhttpcont...@1d489e0e,contextParams={}}}
was not found
java.lang.IllegalStateException:
ResourceModel{id=org.ops4j.pax.web.service.internal.model.ResourceModel-3,urlPatterns=[/system/console/res/*],alias=/system/console/res,servlet=org.ops4j.pax.web.service.internal.resourceserv...@1bcb7c74,initParams={},context=ContextModel{,id=org.ops4j.pax.web.service.internal.model.ContextModel-1,name=,httpcontext=org.apache.felix.webconsole.internal.servlet.osgimanagerhttpcont...@1d489e0e,contextParams={}}}
was not found
at
org.ops4j.pax.web.service.internal.JettyServerImpl.removeServlet(JettyServerImpl.java:217)
at
org.ops4j.pax.web.service.internal.ServerControllerImpl$Started.removeServlet(ServerControllerImpl.java:219)
at
org.ops4j.pax.web.service.internal.ServerControllerImpl.removeServlet(ServerControllerImpl.java:95)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted.unregister(HttpServiceStarted.java:230)
at
org.ops4j.pax.web.service.internal.HttpServiceProxy.unregister(HttpServiceProxy.java:69)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.unbindHttpService(OsgiManager.java:594)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.updateConfiguration(OsgiManager.java:720)
at
org.apache.felix.webconsole.internal.servlet.ConfigurationListener.updated(ConfigurationListener.java:57)
Thrown on a clean startup; subsequently the webconsole is completely broken.
Probably the environment plays a role in this issue, nonetheless, the
OsgiManager should probably never try to unregister something it didn't
register in first place.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-908) Unsynchronize access to bundle state inside BundleInfo by making the variable volatile
[
https://issues.apache.org/jira/browse/FELIX-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669133#action_12669133
]
Don Brown commented on FELIX-908:
-
The cause is how our plugin system interacts with OSGi, not so much as a
technical requirement but legacy design decision. There are a number of
situations where the plugin system will iterate through every plugin (which may
or may not be an OSGi bundle) looking for something, with the first call going
to isEnabled(), where the bundle state check happens for OSGi plugins.
Unsynchronize access to bundle state inside BundleInfo by making the variable
volatile
--
Key: FELIX-908
URL: https://issues.apache.org/jira/browse/FELIX-908
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: felix-1.2.1
Reporter: Anatoli Kazatchkov
Priority: Minor
Attachments: bundle_info.patch
Synchronized access to bundle state inside {{BundleInfo}} class creates an
unnecessary contention point in environments where {{bundle.getState()}} is
called a lot.
Declaring {{m_state}} variable volatile and removing synchronization from
{{setState()}} and {{getState()}} will do the trick.I will attach the patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
