[jira] [Created] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy
Christian Schneider created ARIES-847: - Summary: Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy Key: ARIES-847 URL: https://issues.apache.org/jira/browse/ARIES-847 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Christian Schneider Fix For: 0.4 If the blueprint file contains an error the obj given to destroy may be null. Currently this is not handled. The big problem in this case is that the user does not get a good error message about his error in the context. I will add a patch with the check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy
[ https://issues.apache.org/jira/browse/ARIES-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated ARIES-847: -- Attachment: aries-847-1.patch Added Patch with check for null and also instanceof Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy Key: ARIES-847 URL: https://issues.apache.org/jira/browse/ARIES-847 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Christian Schneider Fix For: 0.4 Attachments: aries-847-1.patch If the blueprint file contains an error the obj given to destroy may be null. Currently this is not handled. The big problem in this case is that the user does not get a good error message about his error in the context. I will add a patch with the check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Blueprint schema blocks nested static class names
Hi Jeremy Hi, The blueprint.xsd is defined by the OSGi Alliance, so this would need to be changed in the spec. The Blueprint spec doesn't mention inner classes so there's nothing AFAICT in the spec that excludes the use of them - so arguably you could open a bug at the OSGi Alliance [1]. It's worth discussing first on the developers list [2]. I can not post to the Alliance dev list, I've received a failure report saying I'm not allowed to post. Does one have to represent an Alliance member to post to that list ? [1] www.osgi.org/bugzilla [2] http://www.osgi.org/MailLists/HomePage Cheers, Jeremy P.S Here is copy of the rejected post, perhaps you can forward it to that list ? Hello All, I've recently reported an issue at the Apache Aries dev list [1] to do with the Blueprint schema blocking the nested static class names and I'm moving the discussion to this list as recommended by Jeremy Hughes. The fix proposed at [1] is to relax the schema for Java (or I guess other language VMs) to validate the class names as opposed to restricting the names at the higher level in Blueprint schema. We came across the issue while working on migrating the application including many code-generated nested classes to Blueprint. Any objections to me opening a bug at [2] ? Thanks, Sergey [1] http://mail-archives.apache.org/mod_mbox/aries-dev/201204.mbox/ajax/%3C4F7A03DE.4060603%40gmail.com%3E [2] https://www.osgi.org/bugzilla/
Re: Plans for release of aries blueprint 0.4.1?
What would people think of changing the groupId of the 0.3 maintenance branch to something like org.apache.aries.m03 so that we don't have any clash between the 0.3.1 release coming from that branch ? On Fri, Apr 13, 2012 at 20:30, Guillaume Nodet gno...@gmail.com wrote: On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes hugh...@apache.org wrote: On 12 April 2012 17:10, Guillaume Nodet gno...@gmail.com wrote: Fwiw, I have a local fork of the 0.3.x aries maintenance branch which we could use as a basis for releasing our own version of the code if we need. I think that would be beneficial for the Karaf 2.x branches where we could get a bunch a bug fixes that we can't otherwise access. I know Geronimo has already released forked Aries code, (I suppose because of the exact same issue) so I don't think that's a real problem: http://repo1.maven.org/maven2/org/apache/geronimo/ext/aries/blueprint/org.apache.aries.blueprint/ I'm not sure where the source for that is, since they don't have svn elements in their pom. I'd *much* prefer to release Aries from the Aries project. Creating forks in Karaf and Geronimo won't help keep the Aries community together. After all, where does a user go to discuss that Geronimo release of Aries? The Geronimo list or the Aries list. As a fork it splits the community. It does, and I don't think that's ideal. However I don't see how to do a maintenance release of 0.3.x branch given some 0.3.1 bundles have already been released from trunk. The only solution I have in mind is to rename the groupId. If you have a better solution, I'd be happy to hear it. So I'm +1 for doing Aries maintenance releases, but -1 for doing them outside Aries. Thoughts ? On Thu, Apr 12, 2012 at 17:18, Holly Cummins holly.k.cumm...@googlemail.com wrote: Hi, Unless it's based on a branch from an older blueprint level, I'm fairly sure that releasing blueprint 0.4.1 isn't much less work than releasing 1.0.0. The reason is that the new blueprint code will only resolve against a new version of the util bundle. No existing bundles will resolve against the new util bundle, so any bundles with a util dependency will also need to be re-released. This is pretty wretched, but such issues should go away once we're using version numbers above 1. I'm going slightly slower with the 1.0.0 work than I could because I'm making sure that all the 1.0.0 bundles work together; at the moment I'm unpicking a problem with the application deployment tests and recent testsupport bundles, for example. This could be deferred until after the first 1.0.0 bundles roll off the assembly line, depending how urgently Karaf need a new release. I think it's neater to do things as I am, but pragmatism and neatness aren't always friends. In either case, a new release hasn't been forgotten, and I am working away at it. :) Holly On 11 Apr 2012, at 19:33, Yonker, Jonathan jonathan.yon...@lmco.com wrote: Hello, From reading through the mailing list, it appears that I'm not the only one with this question, but I still have to ask. Is there currently any timeline for the 0.4.1 release? It appears that all issues in JIRA were resolved quite a while ago, so it appears that the only problem are the release problems that I've been reading about on the mailing list. The project that I'm working on runs on Karaf and we're eagerly awaiting some of the bugfixes from the 0.4.x branch, but Karaf is waiting for 0.4.1 before they upgrade from 0.3.1 ( https://issues.apache.org/** jira/browse/KARAF-988 https://issues.apache.org/jira/browse/KARAF-988). Does anyone have a good guess on the feasibility of releasing 0.4.1 rather than just going right to 1.0? Thanks for any updates you can provide! Thanks, Jon -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Plans for release of aries blueprint 0.4.1?
(and sending again from my apache id so the lists will accept it. Sorry for the dup) On Friday, May 04, 2012 08:44:45 PM Guillaume Nodet wrote: What would people think of changing the groupId of the 0.3 maintenance branch to something like org.apache.aries.m03 so that we don't have any clash between the 0.3.1 release coming from that branch ? I chatted a bit with Guillaume on IRC. I'd much prefer trying to move forward with patching the individual bundles that require patching and releasing them individually if at all possible. For blueprint, I think we can get away with: 1) create a branch to release a blueprint-core-0.3.2 from the appropriate part of the 0.3.1 tag which contains the fixes required. Release that. 2) create a branch for the blueprint-0.3.2 for the bundle from the 0.3.1 tag. Build it using the 0.3.1 tagged versions of everything other than the new core. We MAY be able to grab the 0.3.2 versions for the annotation things as those changes are minor. However, we cannot grab the 0.3.2 version of .cm as that requires bp 0.4. (I really think the cm release is bogus due to this. How can 0.3.2 be a patch when it REQUIRES a minor update to a dep?) Dan On Fri, Apr 13, 2012 at 20:30, Guillaume Nodet gno...@gmail.com wrote: On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes hugh...@apache.org wrote: On 12 April 2012 17:10, Guillaume Nodet gno...@gmail.com wrote: Fwiw, I have a local fork of the 0.3.x aries maintenance branch which we could use as a basis for releasing our own version of the code if we need. I think that would be beneficial for the Karaf 2.x branches where we could get a bunch a bug fixes that we can't otherwise access. I know Geronimo has already released forked Aries code, (I suppose because of the exact same issue) so I don't think that's a real problem: http://repo1.maven.org/maven2/org/apache/geronimo/ext/aries/blueprint/o rg.apache.aries.blueprint/ I'm not sure where the source for that is, since they don't have svn elements in their pom. I'd *much* prefer to release Aries from the Aries project. Creating forks in Karaf and Geronimo won't help keep the Aries community together. After all, where does a user go to discuss that Geronimo release of Aries? The Geronimo list or the Aries list. As a fork it splits the community. It does, and I don't think that's ideal. However I don't see how to do a maintenance release of 0.3.x branch given some 0.3.1 bundles have already been released from trunk. The only solution I have in mind is to rename the groupId. If you have a better solution, I'd be happy to hear it. So I'm +1 for doing Aries maintenance releases, but -1 for doing them outside Aries. Thoughts ? On Thu, Apr 12, 2012 at 17:18, Holly Cummins holly.k.cumm...@googlemail.com wrote: Hi, Unless it's based on a branch from an older blueprint level, I'm fairly sure that releasing blueprint 0.4.1 isn't much less work than releasing 1.0.0. The reason is that the new blueprint code will only resolve against a new version of the util bundle. No existing bundles will resolve against the new util bundle, so any bundles with a util dependency will also need to be re-released. This is pretty wretched, but such issues should go away once we're using version numbers above 1. I'm going slightly slower with the 1.0.0 work than I could because I'm making sure that all the 1.0.0 bundles work together; at the moment I'm unpicking a problem with the application deployment tests and recent testsupport bundles, for example. This could be deferred until after the first 1.0.0 bundles roll off the assembly line, depending how urgently Karaf need a new release. I think it's neater to do things as I am, but pragmatism and neatness aren't always friends. In either case, a new release hasn't been forgotten, and I am working away at it. :) Holly On 11 Apr 2012, at 19:33, Yonker, Jonathan jonathan.yon...@lmco.com wrote: Hello, From reading through the mailing list, it appears that I'm not the only one with this question, but I still have to ask. Is there currently any timeline for the 0.4.1 release? It appears that all issues in JIRA were resolved quite a while ago, so it appears that the only problem are the release problems that I've been reading about on the mailing list. The project that I'm working on runs on Karaf and we're eagerly awaiting some of the bugfixes from the 0.4.x branch, but Karaf is waiting for 0.4.1 before they upgrade from 0.3.1 ( https://issues.apache.org/** jira/browse/KARAF-988 https://issues.apache.org/jira/browse/KARAF-988). Does anyone have a good guess
