Re: Release Process Issue : Bad GPG signature of pom files
2009/8/26 Clement Escoffier clement.escoff...@gmail.com Hi, I'm cutting a release of a couple of artifacts. Everything was fine until I checked the release signatures. I realized that POM GPG (pom.asc files) signatures are not correct. All my pom files have bad signatures... I tried to re-perform one release to check if it happens every times, and yes, it is ! More strangely, the local signature is correct (in target/checkout/target/). So it seems that the issue occurs during the upload of the files on Nexus. Does anybody know how to fix it ? Regards, Clement PS: I use Maven 2.1.0 on Mac ^ I believe using Maven 2.1.0 is the cause: http://jira.codehaus.org/browse/MGPG-14 just looked at the Maven release docs and they also say not to use 2.1.0 for this reason... http://maven.apache.org/developers/release/releasing.html I'll add this to our local release docs -- Cheers, Stuart
Re: Release Process Issue : Bad GPG signature of pom files
Thanks, I will re-try with the 2.2.1 version of Maven. Regards, Clement On 26.08.2009, at 09:59, Stuart McCulloch wrote: 2009/8/26 Clement Escoffier clement.escoff...@gmail.com Hi, I'm cutting a release of a couple of artifacts. Everything was fine until I checked the release signatures. I realized that POM GPG (pom.asc files) signatures are not correct. All my pom files have bad signatures... I tried to re-perform one release to check if it happens every times, and yes, it is ! More strangely, the local signature is correct (in target/checkout/target/). So it seems that the issue occurs during the upload of the files on Nexus. Does anybody know how to fix it ? Regards, Clement PS: I use Maven 2.1.0 on Mac ^ I believe using Maven 2.1.0 is the cause: http://jira.codehaus.org/browse/MGPG-14 just looked at the Maven release docs and they also say not to use 2.1.0 for this reason... http://maven.apache.org/developers/release/releasing.html I'll add this to our local release docs -- Cheers, Stuart
Releasing Karaf
I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * Framework 1.9.0-SNAPSHOT * Osgi core 1.3.0-SNAPSHOT * Gogo 0.9.0-SNAPSHOT * WebConsole 1.2.11-SNAPSHOT I think we don't plan to release the osgi core bundle, so we'd use the one from the OSGi alliance once 4.2 is out. For the framework, I think we are also waiting for 4.2 to be out, but is there any other reason not to publish it once 4.2 is public ? How compliant are we with the tck ? For gogo, there's a lot of ongoing discussion, but that does not mean gogo is not already usable, so I don't see why not releasing a first version of it. For the web console, not sure what the status is ... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Releasing Karaf
We are planning to have a framework release soonish (next couple of weeks). regards, Karl On Wed, Aug 26, 2009 at 11:30 AM, Guillaume Nodetgno...@gmail.com wrote: I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * Framework 1.9.0-SNAPSHOT * Osgi core 1.3.0-SNAPSHOT * Gogo 0.9.0-SNAPSHOT * WebConsole 1.2.11-SNAPSHOT I think we don't plan to release the osgi core bundle, so we'd use the one from the OSGi alliance once 4.2 is out. For the framework, I think we are also waiting for 4.2 to be out, but is there any other reason not to publish it once 4.2 is public ? How compliant are we with the tck ? For gogo, there's a lot of ongoing discussion, but that does not mean gogo is not already usable, so I don't see why not releasing a first version of it. For the web console, not sure what the status is ... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Karl Pauls karlpa...@gmail.com
Re: Releasing Karaf
On Wed, Aug 26, 2009 at 11:30 AM, Guillaume Nodetgno...@gmail.com wrote: I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * Framework 1.9.0-SNAPSHOT * Osgi core 1.3.0-SNAPSHOT * Gogo 0.9.0-SNAPSHOT * WebConsole 1.2.11-SNAPSHOT Guillaume, is there a dependency on Blueprint? What's it status? -- Filippo Diotalevi
[jira] Updated: (FELIX-1473) [gogo] The syntax does not provide a way to call methods on a string
[ https://issues.apache.org/jira/browse/FELIX-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-1473: -- Attachment: FELIX-1473.patch gogo command or method execution depends on the type of the command object, as described in Closure.execute(): // Now there are the following cases // string '=' statement // complex assignment // string statement // cmd call // object // value of object // object statement // method call FELIX-1473.patch adds an experimental '.' operator to force the command to be treated as a reflective method call. This allows methods to be called on String objects: % x = hello world hello world % $x . startsWith hello true % $x . equals hello false % $x . matches h.*d true % $x . split ' ' hello world % $x . length 11 This experimental . operator is also useful for chaining method invocations: % pwd = new java.io.File . . % $pwd . touri . resolve bin . resolve ../etc file:/Users/derek/devl/Zebedee/etc % $pwd touri resolve bin resolve ../etc file:/Users/derek/devl/Zebedee/etc The first example (using .) is easier to type and read than the one using [gogo] The syntax does not provide a way to call methods on a string Key: FELIX-1473 URL: https://issues.apache.org/jira/browse/FELIX-1473 Project: Felix Issue Type: Bug Components: Gogo Reporter: Guillaume Nodet Attachments: FELIX-1473.patch When the first argument is a string, gogo considers it to be a command. The problem is that it leads to unpredictible behavior when using variables $a length Depending on the type of $a, it will either try to call a command named by the value of $a, or call the length method on the $a object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
New release of pax exam
hey guys, i know there has been some trouble with the pax exam version you are using in some integration tests. Today, we released version 1.1 which has some improvements in that area. So i would strongly encourage to update ;) (http://wiki.ops4j.org/display/paxexam/Pax+Exam+-+1.1.0) cheers, Toni -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com t...@okidokiteam.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
Re: Releasing Karaf
I'd like to have it released as soon as the spec is published and it passes the TCK. On Wed, Aug 26, 2009 at 11:53, Filippo Diotalevi filippo.diotal...@gmail.com wrote: On Wed, Aug 26, 2009 at 11:30 AM, Guillaume Nodetgno...@gmail.com wrote: I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * Framework 1.9.0-SNAPSHOT * Osgi core 1.3.0-SNAPSHOT * Gogo 0.9.0-SNAPSHOT * WebConsole 1.2.11-SNAPSHOT Guillaume, is there a dependency on Blueprint? What's it status? -- Filippo Diotalevi -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Releasing Karaf
Hi Guillaume, Guillaume Nodet schrieb: I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * WebConsole 1.2.11-SNAPSHOT For the web console, not sure what the status is ... I have one or two patches in my local workspace, which I would like to commit before cutting a release. Otherwise, we could give it a shot towards the end of the week. Would that be ok ? Regards Felix
Re: Releasing Karaf
On Wed, Aug 26, 2009 at 14:46, Felix Meschbergerfmesc...@gmail.com wrote: Hi Guillaume, Guillaume Nodet schrieb: I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * WebConsole 1.2.11-SNAPSHOT For the web console, not sure what the status is ... I have one or two patches in my local workspace, which I would like to commit before cutting a release. Otherwise, we could give it a shot towards the end of the week. Would that be ok ? Sure, that would be awesome. Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
RE: Releasing Karaf
Can we work FELIX-1221 before releasing webconsole? Tim Moloney The reasonable man adapts himself to MRSLthe world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man.George Bernard Shaw -Original Message- From: Guillaume Nodet [mailto:gno...@gmail.com] Sent: Wednesday, August 26, 2009 08:59 To: dev@felix.apache.org Subject: Re: Releasing Karaf On Wed, Aug 26, 2009 at 14:46, Felix Meschbergerfmesc...@gmail.com wrote: Hi Guillaume, Guillaume Nodet schrieb: I think it's time to think about releasing Karaf. However, Karaf depends on a number of other Felix subprojects: * WebConsole 1.2.11-SNAPSHOT For the web console, not sure what the status is ... I have one or two patches in my local workspace, which I would like to commit before cutting a release. Otherwise, we could give it a shot towards the end of the week. Would that be ok ? Sure, that would be awesome. Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Updated: (FELIX-712) Ability to disable automatic parent classloader delegation
[ https://issues.apache.org/jira/browse/FELIX-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-712: -- Fix Version/s: felix-2.0.0 Ability to disable automatic parent classloader delegation -- Key: FELIX-712 URL: https://issues.apache.org/jira/browse/FELIX-712 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: felix-1.2.0 Reporter: Don Brown Assignee: Karl Pauls Fix For: felix-2.0.0 Attachments: delegate.patch In debugging a strange issue why a certain test was passing in IDEA, but failing in Maven, we discovered that under certain conditions, Felix will delegate to the parent classloader if it detects another class in the stack who's classloader differs from the classloader of Felix. Specifically, in org.apache.felix.framework.searchpolicy.R4SearchPolicyCore starting in line 541, there is the problematic code block that has this comment: // At this point, the class/resource could not be found by the bundle's // static or dynamic imports, nor its own content. Before we throw // an exception, we will try to determine if the instigator of the // class/resource load was a class from a bundle or not. This is necessary // because the specification mandates that classes on the class path // should be hidden (except for java.*), but it does allow for these // classes/resources to be exposed by the system bundle as an export. // However, in some situations classes on the class path make the faulty // assumption that they can access everything on the class path from // every other class loader that they come in contact with. This is // not true if the class loader in question is from a bundle. Thus, // this code tries to detect that situation. If the class // instigating the load request was NOT from a bundle, then we will // make the assumption that the caller actually wanted to use the // parent class loader and we will delegate to it. If the class was // from a bundle, then we will enforce strict class loading rules // for the bundle and throw an exception. What that means is if if you call Bundle.loadClass() from a non-bundle class and you happen to have a class in your stack, which was loaded from a different classloader than Felix, Felix will try to fix your problem by allowing parent classloader delegation. This was the cause of the breakage for us because Maven's Surefire plugin uses its own classloader to load several of its classes and Felix found those in the call stack and decided to enable parent delegation. In IDEA, all the classes were loaded by the same classloader, so our tests passed. Specifically, we have code that sits outside Felix and tries to load classes from installed bundles. Felix sees that the call, by examining the stack, is by code outside a bundle, so it enters this routine that may or may not, depending on the execution environment, delegate the class loading to Felix's class loader. This ticket asks for a configuration setting to be able to disable this bit of code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1158) Strange NoClassDefFoundError in WebLogic 9.2 when creating URLStreamHandlersProxyFactory
[ https://issues.apache.org/jira/browse/FELIX-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1158. -- Resolution: Fixed Reported as fixed: Yep, this looks good. I didn't yet test it with WebLogic, but I looked through the code and it looks like it'll do the trick. Strange NoClassDefFoundError in WebLogic 9.2 when creating URLStreamHandlersProxyFactory Key: FELIX-1158 URL: https://issues.apache.org/jira/browse/FELIX-1158 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.2.1 Reporter: Don Brown Assignee: Karl Pauls Attachments: FELIX-1158.diff This bug really makes no sense, and the fix makes even less, but here it goes: In WebLogic 9.2, in some cases, the URLHandlers class is unable to create a URLStreamHandlersProxyFactory due to a NoClassDefFoundError. The really weird bit is you can load the class using the class's classloader just fine via loadClass(). Attached is the hack that implements this workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1158) Strange NoClassDefFoundError in WebLogic 9.2 when creating URLStreamHandlersProxyFactory
[ https://issues.apache.org/jira/browse/FELIX-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-1158: --- Fix Version/s: felix-1.8.0 Strange NoClassDefFoundError in WebLogic 9.2 when creating URLStreamHandlersProxyFactory Key: FELIX-1158 URL: https://issues.apache.org/jira/browse/FELIX-1158 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.2.1 Reporter: Don Brown Assignee: Karl Pauls Fix For: felix-1.8.0 Attachments: FELIX-1158.diff This bug really makes no sense, and the fix makes even less, but here it goes: In WebLogic 9.2, in some cases, the URLHandlers class is unable to create a URLStreamHandlersProxyFactory due to a NoClassDefFoundError. The really weird bit is you can load the class using the class's classloader just fine via loadClass(). Attached is the hack that implements this workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1517) Manually deleting an instance breaks admin:list
[ https://issues.apache.org/jira/browse/FELIX-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1517. Resolution: Fixed Fix Version/s: karaf-1.0.0 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?rev=808019view=rev Log: FELIX-1517 and FELIX-1528: use a defined location for the storage of the list of managed instances and avoid an exception if one instance has been deleted Modified: felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/AdminServiceMBean.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/Instance.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/internal/AdminServiceImpl.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/internal/AdminServiceMBeanImpl.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/internal/InstanceImpl.java felix/trunk/karaf/gshell/gshell-admin/src/main/resources/OSGI-INF/blueprint/gshell-admin.xml Manually deleting an instance breaks admin:list --- Key: FELIX-1517 URL: https://issues.apache.org/jira/browse/FELIX-1517 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.0 Reporter: David Bosschaert Assignee: Guillaume Nodet Fix For: karaf-1.0.0 When I delete an instance manually, by simply deleting the subdirectory from the instances directory, it breaks the admin:list command. When I run that command afterwards I get this: ka...@root admin:list Port State Pid Name pipe: java.io.FileNotFoundException: K:\assembly\target\apache-felix-karaf-1.2.0 -SNAPSHOT\instances\too\etc\org.apache.felix.karaf.shell.cfg (The system cannot find the path specified) java.io.FileNotFoundException: K:\assembly\target\apache-felix-karaf-1.2.0-SNAPS HOT\instances\too\etc\org.apache.felix.karaf.shell.cfg (The system cannot find t he path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.felix.karaf.gshell.admin.internal.InstanceImpl.getPort(InstanceImpl.java:76) at org.apache.felix.karaf.gshell.admin.internal.commands.ListCommand.doExecute(ListCommand.java:42) at org.apache.felix.karaf.gshell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41) at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:34) at org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:45) at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:208) at org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:147) at org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:91) at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:78) at org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71) at org.apache.felix.karaf.gshell.console.jline.Console.run(Console.java:115) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1528) [karaf] Use a defined location for storing the list of managed instances create by the admin service
[ https://issues.apache.org/jira/browse/FELIX-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1528. Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=808019view=rev Log: FELIX-1517 and FELIX-1528: use a defined location for the storage of the list of managed instances and avoid an exception if one instance has been deleted Modified: felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/AdminServiceMBean.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/Instance.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/internal/AdminServiceImpl.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/internal/AdminServiceMBeanImpl.java felix/trunk/karaf/gshell/gshell-admin/src/main/java/org/apache/felix/karaf/gshell/admin/internal/InstanceImpl.java felix/trunk/karaf/gshell/gshell-admin/src/main/resources/OSGI-INF/blueprint/gshell-admin.xml [karaf] Use a defined location for storing the list of managed instances create by the admin service Key: FELIX-1528 URL: https://issues.apache.org/jira/browse/FELIX-1528 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf-1.0.0 This would allow a much easier management of instances, especially offline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1095) Investigate the integration of Pax VFS, as VFS is already used in GShell
[ https://issues.apache.org/jira/browse/FELIX-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed FELIX-1095. -- Resolution: Won't Fix We don't use gshell anymore, so there's not much value in putting back commons-vfs, especially with all the problem it causes to the cat command. Investigate the integration of Pax VFS, as VFS is already used in GShell Key: FELIX-1095 URL: https://issues.apache.org/jira/browse/FELIX-1095 Project: Felix Issue Type: Task Components: Karaf Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1529) The console does not work anymore when connecting to another karaf instance
The console does not work anymore when connecting to another karaf instance --- Key: FELIX-1529 URL: https://issues.apache.org/jira/browse/FELIX-1529 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet Using: admin:create k1 admin:start k1 admin:connect k1 It seems keystrokes are eaten by another thread -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1478) Add shutdown hook to launcher to cleanly shutdown the framework if the process is killed
[ https://issues.apache.org/jira/browse/FELIX-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747949#action_12747949 ] Richard S. Hall commented on FELIX-1478: Yes, definitely to the launcher. Add shutdown hook to launcher to cleanly shutdown the framework if the process is killed Key: FELIX-1478 URL: https://issues.apache.org/jira/browse/FELIX-1478 Project: Felix Issue Type: New Feature Components: Main Affects Versions: felix-1.8.1 Reporter: Richard S. Hall Assignee: Richard S. Hall Priority: Minor Fix For: felix-2.0.0 As it stands currently (and dating back to the Oscar days), if someone does a control-C, then the framework process just dies and there is no attempt to shutdown cleanly. If we add a shutdown hook, then we can cleanly shutdown the framework. I am not sure if this would necessarily impact anyone who directly uses our launcher to launch the framework. I imagine there could possibly be an issue if someone uses our launcher, but registers their own shutdown hook. We also have the potential issue of a deadlock or some situation where we cannot exit, which could prevent the VM from exiting. Any one have any thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1528) [karaf] Use a defined location for storing the list of managed instances create by the admin service
[karaf] Use a defined location for storing the list of managed instances create by the admin service Key: FELIX-1528 URL: https://issues.apache.org/jira/browse/FELIX-1528 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf-1.0.0 This would allow a much easier management of instances, especially offline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1170) MemoryLeak when stopping and restarting Felix
[ https://issues.apache.org/jira/browse/FELIX-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1170. -- MemoryLeak when stopping and restarting Felix - Key: FELIX-1170 URL: https://issues.apache.org/jira/browse/FELIX-1170 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.2.1 Environment: Atlassian JIRA Reporter: Jed Wesley-Smith Assignee: Karl Pauls Fix For: felix-2.0.0 Attachments: BundleProtectionDomain.java.FELIX-1170.patch There is a memory leak caused by a strong reference from the BundleProtectionDomain to a bundle and Felix. The problem is that a URLClassLoader gets its AccessControlContext from the stack - AccessController.getContext() calls AccessController.getStackAccessControlContext() which is basically arbitrary at the time. In our case we have a ServletFilter plugin that is being loaded by Felix. When a JasperLoader (a URLClassLoader) is created to load a JSP it inherits the BundleProtectionDomain as part of its AccessControlContext. If we later shut down Felix, it cannot be GC'd due to this reference. For our purposes we have tested making the m_felix and m_bundle weak references and have verified that it does indeed fix the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-765) Invalid occasional OSGi filter toString() value
[
https://issues.apache.org/jira/browse/FELIX-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-765.
-
Invalid occasional OSGi filter toString() value
---
Key: FELIX-765
URL: https://issues.apache.org/jira/browse/FELIX-765
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: felix-1.2.2
Reporter: Don Brown
Assignee: Karl Pauls
Fix For: felix-1.4.0
Attachments: ldap.patch
Rather frequently, under the right conditions, FilterImpl.toString() will
generate an invalid filter string. In my case, this happens when Spring DM
loads two bundles on two different threads simultaneously when processing a
number of OSGi service imports. The actual stracktrace isn't very useful
since what Spring DM does internally is get a filter's string, pass that
around a bit, then try to give that to Felix, which causes an exception. I
narrowed the problem down to the toString() method:
java.lang.RuntimeException: Invalid filter
string:(some49((bean-name=some49)(plugins-host=true)))
at
org.apache.felix.framework.FilterImpl.checkFilter(FilterImpl.java:330)
at org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:244)
at java.lang.String.valueOf(String.java:2615)
at java.lang.StringBuffer.append(StringBuffer.java:220)
at
org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:53)
at
org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:253)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:173)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:741)
at java.lang.Thread.run(Thread.java:613)
This checkFilter() method simply looks for invalid strings where the ''
character isn't followed by a '(' character:
public static void checkFilter(String filter)
{
if (filter != null)
{
boolean andFound = false;
for (int x=0; xfilter.length(); x++)
{
char c = filter.charAt(x);
if (c == '') {
andFound = true;
} else if (andFound c != '(') {
throw new RuntimeException(Invalid filter
string:+filter);
} else
andFound = false;
}
}
}
Deeper in the code, I put this check in Parser to find out when this invalid
filter String was being created (line 594):
for (int x=0; xtmp.length; x++) {
if (tmp[x] instanceof ConstOperator) {
System.out.println(Invalid tree
constructed:+tmp[x]);
}
}
This detected when the const operator was incorrectly listed as a child of
the AND operator, but I also saw the PUSH operator a direct child as well.
Therefore, this issue seems related to FELIX-721, although I was unable to
find a direct fix. For now, I'm commenting out the program cache in
FilterImpl line 64, which fixes the issue and has a negligible impact on
performance from my testing. Since we are seeing this exception between 10%
and 80% of the time, a slower Felix is preferable to a frequently broken
startup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1530) Extend the SCR introspection API to reflect the new DS 1.1 features
Extend the SCR introspection API to reflect the new DS 1.1 features --- Key: FELIX-1530 URL: https://issues.apache.org/jira/browse/FELIX-1530 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.0.8 Reporter: Felix Meschberger Fix For: scr-1.2.0 The current SCR introspection API in org.apache.felix.scr does not currently reflect the SCR 1.1 changes targeted for OSGi Compendium 4.2. Namely the reflection of the configuration-policy, activate, deactivate and modify attributes of the component element are missing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1478) Add shutdown hook to launcher to cleanly shutdown the framework if the process is killed
[ https://issues.apache.org/jira/browse/FELIX-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1478. -- Resolution: Fixed Added shutdown hook to launcher which can be turned off with felix.shutdown.hook=false. Add shutdown hook to launcher to cleanly shutdown the framework if the process is killed Key: FELIX-1478 URL: https://issues.apache.org/jira/browse/FELIX-1478 Project: Felix Issue Type: New Feature Components: Main Affects Versions: felix-1.8.1 Reporter: Richard S. Hall Assignee: Richard S. Hall Priority: Minor Fix For: felix-2.0.0 As it stands currently (and dating back to the Oscar days), if someone does a control-C, then the framework process just dies and there is no attempt to shutdown cleanly. If we add a shutdown hook, then we can cleanly shutdown the framework. I am not sure if this would necessarily impact anyone who directly uses our launcher to launch the framework. I imagine there could possibly be an issue if someone uses our launcher, but registers their own shutdown hook. We also have the potential issue of a deadlock or some situation where we cannot exit, which could prevent the VM from exiting. Any one have any thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-712) Ability to disable automatic parent classloader delegation
[ https://issues.apache.org/jira/browse/FELIX-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reassigned FELIX-712: - Assignee: Richard S. Hall (was: Karl Pauls) Ability to disable automatic parent classloader delegation -- Key: FELIX-712 URL: https://issues.apache.org/jira/browse/FELIX-712 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: felix-1.2.0 Reporter: Don Brown Assignee: Richard S. Hall Fix For: felix-2.0.0 Attachments: delegate.patch In debugging a strange issue why a certain test was passing in IDEA, but failing in Maven, we discovered that under certain conditions, Felix will delegate to the parent classloader if it detects another class in the stack who's classloader differs from the classloader of Felix. Specifically, in org.apache.felix.framework.searchpolicy.R4SearchPolicyCore starting in line 541, there is the problematic code block that has this comment: // At this point, the class/resource could not be found by the bundle's // static or dynamic imports, nor its own content. Before we throw // an exception, we will try to determine if the instigator of the // class/resource load was a class from a bundle or not. This is necessary // because the specification mandates that classes on the class path // should be hidden (except for java.*), but it does allow for these // classes/resources to be exposed by the system bundle as an export. // However, in some situations classes on the class path make the faulty // assumption that they can access everything on the class path from // every other class loader that they come in contact with. This is // not true if the class loader in question is from a bundle. Thus, // this code tries to detect that situation. If the class // instigating the load request was NOT from a bundle, then we will // make the assumption that the caller actually wanted to use the // parent class loader and we will delegate to it. If the class was // from a bundle, then we will enforce strict class loading rules // for the bundle and throw an exception. What that means is if if you call Bundle.loadClass() from a non-bundle class and you happen to have a class in your stack, which was loaded from a different classloader than Felix, Felix will try to fix your problem by allowing parent classloader delegation. This was the cause of the breakage for us because Maven's Surefire plugin uses its own classloader to load several of its classes and Felix found those in the call stack and decided to enable parent delegation. In IDEA, all the classes were loaded by the same classloader, so our tests passed. Specifically, we have code that sits outside Felix and tries to load classes from installed bundles. Felix sees that the call, by examining the stack, is by code outside a bundle, so it enters this routine that may or may not, depending on the execution environment, delegate the class loading to Felix's class loader. This ticket asks for a configuration setting to be able to disable this bit of code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1531) Mandatory directive is ignored on the Export-Package when it comes to resolve the bundles
[ https://issues.apache.org/jira/browse/FELIX-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748230#action_12748230 ] Richard S. Hall commented on FELIX-1531: You are talking about resolving with OBR, not Felix, correct? The Felix framework should resolve this correctly, but OBR will not since handling directives is not fully supported. Mandatory directive is ignored on the Export-Package when it comes to resolve the bundles - Key: FELIX-1531 URL: https://issues.apache.org/jira/browse/FELIX-1531 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: felix-1.6.0 Environment: not applicable Reporter: hehe ji When I try to resolve a bundle (bundleFooImport.jar) with the following manifest: Import-Package: a.b.c;company=foo In the bundle repository, I have a bundle (bundleFoo.jar) with the following manifest: Export-Package:a.b.c;version=3;company=foo;security=true;mandatory:=company,security The repository.xml for the bundleFoo.jar capability name='package' p n='company' v='foo'/ p n='mandatory:' t='set' v='company,security'/ p n='package' v='a.b.c'/ p n='security' v='true'/ p n='version' t='version' v='3.0.0'/ /capability For some reason, the felix resolve resolves the bundleFooImport.jar with bundle bundleFoo.jar, which is wrong. According to the osgi specification, bundleFoo.jar bundle insists the bundle imports specifying company and security attributes, which was not the case of bundleFooImport.jar. Clearly, the felix implementation of the mandatory directive is NOT correct. Please let me know if you need any more details. Thanks Hehe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
