Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml
On Tue, May 22, 2012 at 9:16 AM, Siano, Stephan stephan.si...@sap.com wrote: I actually do not understand your argument. The class space compatibility mentioned in 121.3.1 of the compendium spec is actually fulfilled better if the blueprint apis are imported and exported by the extender bundle. In this case the class loader of the extender and the class loader of the blueprint bundle actually reference to the same class, whereas if the packages are not imported but only exported by the extender bundle this class space compatibility will break as soon as the blueprint bundle is wired with any other bundle exporting the api is present. Section 121.3.1 did not make any explicit references to multiple extenders because there was an RFC going on at that time to address this issue, but that was the main use case for writing such a section. The spec also says that blueprint bundles should import the blueprint package (which does not make sense on its own unless the package is actually needed), and that's for the same reason. Your problem is due to the fact that you deploy compendium. That's a really bad thing to do anyway as it breaks the modularity of all osgi services implementations. You can always use the fine grained bundles if you prefer and that will solve your problem. Sure: with your model you can have two different blueprint extender bundles active at the at the same time and the blueprint bundle is extended by whichever blueprint bundle it is wired to (if both implement the same blueprint version this is random usually depending on the start order of the bundles), but I actually do not really see a use case for that. That's really the use case that we had in mind when the spec was discussed and written. For example, karaf rely on Aries Blueprint (because of the namespace handlers), but some users want to be able to deploy spring-dm (to leverage some spring specific features). The only way to handle such a use case is to really split the class space. Why would you need additional bundles to deploy? Importing a bundle you do also provide does not require you to have another bundle present that exports the packages, it just means that you don't have these class space compatibility issues if another bundle is present that is exporting the same API (e.g. and API bundle containing the compendium or enterprise APIs). This is a *bug fix* release. So you should be able to upgrade blueprint-bundle should work. Forcing an import is a no go. -Original Message- From: Guillaume Nodet [mailto:gno...@gmail.com] Sent: Dienstag, 22. Mai 2012 08:42 To: dev@aries.apache.org Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml The rule you mentioned is the general rule, and I agree with it in most of the cases for API packages. However, as I mentioned, for blueprint, things are a bit different. You can see that by checking 121.3.1 which specifically talks about class space compatibility, and there's a reason for that as I explained (I can go though it with more details if necessary). The overall goal is to actually split the class space into separate portions. So first, that's would be incompatible with 0.3 because it would needs an additional bundle to deploy (that will the case in 1.0 anyway with the small bundles, so please can we try to at least keep one version clean ?). Second, it would lead to serious problems when trying to have multiple blueprint extenders in the same container, which is supposed to work to some degree. And last, the only benefit of sharing API is that you should be able to update the extender without having to refresh the blueprint bundles. However, in real cases, that's rarely the case and the all the blueprint beans have to be recreated anyway, so the benefit is very low. On Tue, May 22, 2012 at 7:52 AM, Siano, Stephan stephan.si...@sap.com wrote: AFAIK the OSGi spec proposes to do the import and export in such cases (section 3.5.6 of the 4.3 core spec). Personally I find it much more probable that the compendium or enterprise bundles are present, than having two different blueprint implementations on the same stack. I also do not see any issues with the different blueprint implementation importing the same org.osgi.blueprint APIs. They are specified in the spec and should always be the same wherever they come from. So I essentially do think that it's a good idea to import the osgi api. -Original Message- From: Guillaume Nodet [mailto:gno...@gmail.com] Sent: Dienstag, 22. Mai 2012 00:44 To: dev@aries.apache.org Subject: Re: svn commit: r1340184 - /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml I don't think that's a good idea to import the osgi api. It may lead to problems if multiple blueprint implementations are deployed for some reason. To support such a case, the blueprint bundles are supposed to import
[jira] [Updated] (ARIES-851) Multiple IllegalStateException when deploying a new PersistenceUnit
[
https://issues.apache.org/jira/browse/ARIES-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Gritschenberger updated ARIES-851:
Component/s: Util
Multiple IllegalStateException when deploying a new PersistenceUnit
---
Key: ARIES-851
URL: https://issues.apache.org/jira/browse/ARIES-851
Project: Aries
Issue Type: Bug
Components: JPA, Util
Environment: Linux-3.0.0, Karaf-3.0.0-SNAPSHOT with Felix, openjdk-6
Reporter: Christoph Gritschenberger
Attachments: ARIES-851-stacktrace.TXT,
BundleHookBundleTracker-solution1.patch,
BundleHookBundleTracker-solution2.patch, jpa-test-bundle-src.zip,
persistence-feature.xml, test.jpa.bundle-0.1.0-SNAPSHOT.jar
Steps to reproduce
* Compile or get a karaf-3.0.0-SNAPSHOT and unpack it
* Install openjpa-2.2.0 (using the attached feature-file)
* Deploy a bundle containing a persistence-unit (attached jar for example)
get the following Exception 4 times:
{code}
ERROR: Bundle org.apache.aries.jpa.container [78] EventDispatcher: Error
during dispatch. (java.lang.IllegalStateException: Unable to create
persistence units for the bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as
previous persistence units already exist.)
java.lang.IllegalStateException: Unable to create persistence units for the
bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as previous persistence units
already exist.
{code}
See attachment for full stacktrace
In subsequent startups the Exception is still thrown but the stacktrace does
not show in the console or the log.
Also when using equinox the Stacktrace does not appear in either the console
or the log ever, but it's still thrown.
The problem is that the PersistenceBundleManager#addingBundle is called
multiple times for the newly installed bundle.
The PersistenceBundleManager is passed as a BundleTrackerCustomizer to a
BundleHookBundleTracker.
The BundleHookBundleTracker stores it in it's own private attribute and also
passes it to it's super-constructor.
So the customizer is stored in the instance twice.
It's called by both BundleTracker$Tracked.customizerAdding and
BundleHookBundleTracker$Tracked.customizerAdding.
Both Tracked recognize the bundle as untracked and call the
addingBundle-method.
--
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] [Created] (ARIES-854) NullpointerException in TransactionManager when felix configAdmin is used
Balazs Zsoldos created ARIES-854: Summary: NullpointerException in TransactionManager when felix configAdmin is used Key: ARIES-854 URL: https://issues.apache.org/jira/browse/ARIES-854 Project: Aries Issue Type: Bug Components: Transaction Environment: Equinox, org.apache.felix.configadmin-1.2.8, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT Reporter: Balazs Zsoldos When the felix configadmin is in the OSGI container the following exception occurs: java.lang.NullPointerException at org.apache.aries.transaction.TransactionManagerService.getInt(TransactionManagerService.java:181) at org.apache.aries.transaction.TransactionManagerService.init(TransactionManagerService.java:82) at org.apache.aries.transaction.Activator.updated(Activator.java:55) at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) This has to do something with a patch applied to ARIES-809 -- 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-854) NullpointerException in TransactionManager when felix configAdmin is used
[ https://issues.apache.org/jira/browse/ARIES-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-854: - Priority: Critical (was: Major) NullpointerException in TransactionManager when felix configAdmin is used - Key: ARIES-854 URL: https://issues.apache.org/jira/browse/ARIES-854 Project: Aries Issue Type: Bug Components: Transaction Environment: Equinox, org.apache.felix.configadmin-1.2.8, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT Reporter: Balazs Zsoldos Priority: Critical Attachments: TransactionManagerService.java.patch When the felix configadmin is in the OSGI container the following exception occurs: java.lang.NullPointerException at org.apache.aries.transaction.TransactionManagerService.getInt(TransactionManagerService.java:181) at org.apache.aries.transaction.TransactionManagerService.init(TransactionManagerService.java:82) at org.apache.aries.transaction.Activator.updated(Activator.java:55) at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) This has to do something with a patch applied to ARIES-809 -- 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] [Commented] (ARIES-851) BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times for the same event.
[
https://issues.apache.org/jira/browse/ARIES-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280847#comment-13280847
]
Andreas Pieber commented on ARIES-851:
--
I get nagged on by exactly the same problem. I can confirm that both of the
attached patches fix the problem for me (although I think solution2 is the way
to go). Can any commiter pls give this problem a shot? Maybe before the 1.0.0
release? :-)
many thanks in advance and kind regards
BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times
for the same event.
---
Key: ARIES-851
URL: https://issues.apache.org/jira/browse/ARIES-851
Project: Aries
Issue Type: Bug
Components: JPA, Util
Environment: Linux-3.0.0, Karaf-3.0.0-SNAPSHOT with Felix, openjdk-6
Reporter: Christoph Gritschenberger
Attachments: ARIES-851-stacktrace.TXT,
BundleHookBundleTracker-solution1.patch,
BundleHookBundleTracker-solution2.patch, jpa-test-bundle-src.zip,
persistence-feature.xml, test.jpa.bundle-0.1.0-SNAPSHOT.jar
Steps to reproduce
* Compile or get a karaf-3.0.0-SNAPSHOT and unpack it
* Install openjpa-2.2.0 (using the attached feature-file)
* Deploy a bundle containing a persistence-unit (attached jar for example)
get the following Exception 4 times:
{code}
ERROR: Bundle org.apache.aries.jpa.container [78] EventDispatcher: Error
during dispatch. (java.lang.IllegalStateException: Unable to create
persistence units for the bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as
previous persistence units already exist.)
java.lang.IllegalStateException: Unable to create persistence units for the
bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as previous persistence units
already exist.
{code}
See attachment for full stacktrace
In subsequent startups the Exception is still thrown but the stacktrace does
not show in the console or the log.
Also when using equinox the Stacktrace does not appear in either the console
or the log ever, but it's still thrown.
The problem is that the PersistenceBundleManager#addingBundle is called
multiple times for the newly installed bundle.
The PersistenceBundleManager is passed as a BundleTrackerCustomizer to a
BundleHookBundleTracker.
The BundleHookBundleTracker stores it in it's own private attribute and also
passes it to it's super-constructor.
So the customizer is stored in the instance twice.
It's called by both BundleTracker$Tracked.customizerAdding and
BundleHookBundleTracker$Tracked.customizerAdding.
Both Tracked recognize the bundle as untracked and call the
addingBundle-method.
--
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: [VOTE] Apache Aries release candidate parent-1.0.0
+1 On Saturday, May 12, 2012, Holly Cummins wrote: I've staged a release candidate for the Aries 1.0.0 parent module. The module is staged and tagged in https://svn.apache.org/repos/asf/aries/tags/parent-1.0.0/. The artifacts are in one staged repo, https://repository.apache.org/content/repositories/orgapachearies-113/. Links to the *.zip files for each module are provided below. The only module staged is the parent module: https://repository.apache.org/content/repositories/orgapachearies-079/org/apache/aries/parent/1.0.0/parent-1.0.0-source-release.zip The RAT and IANAL build checks passed. The vote will be open for 72 hours. [ ] +1 [ ] 0 [ ] -1 Holly -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
[jira] [Updated] (ARIES-854) NullpointerException in TransactionManager when felix configAdmin is used
[ https://issues.apache.org/jira/browse/ARIES-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated ARIES-854: - Environment: Equinox, org.apache.felix.configadmin-1.0.4, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT (was: Equinox, org.apache.felix.configadmin-1.2.8, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT) NullpointerException in TransactionManager when felix configAdmin is used - Key: ARIES-854 URL: https://issues.apache.org/jira/browse/ARIES-854 Project: Aries Issue Type: Bug Components: Transaction Environment: Equinox, org.apache.felix.configadmin-1.0.4, org.apache.aries.transactionmanager-1.0.0-SNAPSHOT Reporter: Balazs Zsoldos Priority: Critical Attachments: TransactionManagerService.java.patch When the felix configadmin is in the OSGI container the following exception occurs: java.lang.NullPointerException at org.apache.aries.transaction.TransactionManagerService.getInt(TransactionManagerService.java:181) at org.apache.aries.transaction.TransactionManagerService.init(TransactionManagerService.java:82) at org.apache.aries.transaction.Activator.updated(Activator.java:55) at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) This has to do something with a patch applied to ARIES-809 -- 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
Blueprint 0.3.2 version on JIRA
Hi All, We're looking at updating Karaf 2.3.x and 2.2.x lines to pick up Blueprint 0.3.2 and were looking to review the change log, however there doesn't appear to be a 0.3.2 version tag in the project JIRA. Could one be created so that we can review the changes before proceeding? Blueprint 0.3.2 branch: https://svn.apache.org/repos/asf/aries/branches/blueprint-0.3.2-fixes Aries Versions: https://issues.apache.org/jira/browse/ARIES#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel Cheers, Jamie
Re: Blueprint 0.3.2 version on JIRA
The change log isn't uptodate because the versions do not exist in the JIRA atm, so I suggest you look at https://github.com/apache/aries/commits/blueprint-0.3.2-fixes GIven the release is per-bundle, it makes reviewing quite impossible anyway, so the above is the way to go. On Tue, May 22, 2012 at 1:39 PM, Jamie G. jamie.goody...@gmail.com wrote: Hi All, We're looking at updating Karaf 2.3.x and 2.2.x lines to pick up Blueprint 0.3.2 and were looking to review the change log, however there doesn't appear to be a 0.3.2 version tag in the project JIRA. Could one be created so that we can review the changes before proceeding? Blueprint 0.3.2 branch: https://svn.apache.org/repos/asf/aries/branches/blueprint-0.3.2-fixes Aries Versions: https://issues.apache.org/jira/browse/ARIES#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel Cheers, Jamie -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Blueprint 0.3.2 version on JIRA
Thanks Guillaume, I'll have a look at the link :) Cheers, Jamie On Tue, May 22, 2012 at 9:22 AM, Guillaume Nodet gno...@gmail.com wrote: The change log isn't uptodate because the versions do not exist in the JIRA atm, so I suggest you look at https://github.com/apache/aries/commits/blueprint-0.3.2-fixes GIven the release is per-bundle, it makes reviewing quite impossible anyway, so the above is the way to go. On Tue, May 22, 2012 at 1:39 PM, Jamie G. jamie.goody...@gmail.com wrote: Hi All, We're looking at updating Karaf 2.3.x and 2.2.x lines to pick up Blueprint 0.3.2 and were looking to review the change log, however there doesn't appear to be a 0.3.2 version tag in the project JIRA. Could one be created so that we can review the changes before proceeding? Blueprint 0.3.2 branch: https://svn.apache.org/repos/asf/aries/branches/blueprint-0.3.2-fixes Aries Versions: https://issues.apache.org/jira/browse/ARIES#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel Cheers, Jamie -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
[jira] [Resolved] (ARIES-626) Aries blueprint namaspace handler schema with includes
[ https://issues.apache.org/jira/browse/ARIES-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-626. --- Resolution: Fixed Fix Version/s: 1.0 blueprint-core-0.3.2 Aries blueprint namaspace handler schema with includes -- Key: ARIES-626 URL: https://issues.apache.org/jira/browse/ARIES-626 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Edstrom Johan Assignee: Daniel Kulp Fix For: blueprint-core-0.3.2, 1.0 Attachments: relpath-patch2-fixed.txt, relpath-patch2.txt If you have a NamespaceHandler implementation where the schema contains xsd:includes, the schema will fail to resolve if you do not have connectivity. There is also no way to attach a CatalogResolver or xml-resolver. -- 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-777) AriesFrameworkUtil FelixWorker doesn't work on r4.3 felixes
[
https://issues.apache.org/jira/browse/ARIES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated ARIES-777:
--
Fix Version/s: 1.0
util-0.3.1
AriesFrameworkUtil FelixWorker doesn't work on r4.3 felixes
---
Key: ARIES-777
URL: https://issues.apache.org/jira/browse/ARIES-777
Project: Aries
Issue Type: Bug
Components: Util
Affects Versions: util-0.4
Reporter: David Jencks
Assignee: David Jencks
Fix For: util-0.3.1, 1.0
The felix-specific way to get a bundle's classloader has changed to something
like
ListBundleRevision revisions =
b.adapt(BundleRevisions.class).getRevisions();
if (!revisions.isEmpty()) {
BundleRevision revision = revisions.get(0);
return
((BundleRevisionImpl)revision).getProtectionDomain().getClassLoader();
}
--
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-663) ConfigurationAdminMBean registered twice
[
https://issues.apache.org/jira/browse/ARIES-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated ARIES-663:
--
Fix Version/s: 1.0
jmx-core-0.3.1
ConfigurationAdminMBean registered twice
Key: ARIES-663
URL: https://issues.apache.org/jira/browse/ARIES-663
Project: Aries
Issue Type: Bug
Affects Versions: 0.3
Reporter: Thomas Diesler
Assignee: Guillaume Nodet
Fix For: jmx-core-0.3.1, 1.0
Attachments: ARIES-663.patch
{code}
18:00:12,965 INFO [jmx] Starting JMX OSGi agent
18:00:12,982 INFO [jmx] Registering MBean with ObjectName
[osgi.compendium:service=cm,version=1.3] for service with service.id [12]
18:00:12,990 INFO [HostBundleState] Bundle started:
org.apache.aries.jmx:0.3.0
18:00:12,993 INFO [HostBundleState] Bundle started:
org.apache.aries.util:0.3.0
18:00:12,994 INFO [jmx] Registering
org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
com.sun.jmx.mbeanserver.JmxMBeanServer@5d5bdc50 with name
osgi.compendium:service=cm,version=1.3
18:00:13,003 INFO [jmx] Registering org.osgi.jmx.framework.BundleStateMBean
to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@5d5bdc50 with name
osgi.core:type=bundleState,version=1.5
18:00:13,005 INFO [jmx] Registering org.osgi.jmx.framework.PackageStateMBean
to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@5d5bdc50 with name
osgi.core:type=packageState,version=1.5
18:00:13,006 INFO [jmx] Registering org.osgi.jmx.framework.ServiceStateMBean
to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@5d5bdc50 with name
osgi.core:type=serviceState,version=1.5
18:00:13,007 INFO [jmx] Registering
org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
com.sun.jmx.mbeanserver.JmxMBeanServer@5d5bdc50 with name
osgi.compendium:service=cm,version=1.3
18:00:13,009 ERROR [jmx] MBean is already registered
org.apache.felix.log.LogException:
javax.management.InstanceAlreadyExistsException:
osgi.compendium:service=cm,version=1.3
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.aries.jmx.agent.JMXAgentImpl.registerMBeans(JMXAgentImpl.java:129)
at
org.apache.aries.jmx.agent.JMXAgentContext.registerMBeans(JMXAgentContext.java:58)
at
org.apache.aries.jmx.MBeanServiceTracker$1.run(MBeanServiceTracker.java:61)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
18:00:13,010 INFO [jmx] Registering org.osgi.jmx.framework.FrameworkMBean to
MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@5d5bdc50 with name
osgi.core:type=framework,version=1.5
{code}
--
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-846) The Aries transaction manager does not recover transactions correctly
[ https://issues.apache.org/jira/browse/ARIES-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-846: -- Fix Version/s: 1.0 transaction-manager-0.3.1 The Aries transaction manager does not recover transactions correctly - Key: ARIES-846 URL: https://issues.apache.org/jira/browse/ARIES-846 Project: Aries Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Priority: Critical Fix For: transaction-manager-0.3.1, 1.0 Attachments: ARIES-846.patch -- 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-809) Not possible to configure transaction timeout
[
https://issues.apache.org/jira/browse/ARIES-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated ARIES-809:
--
Fix Version/s: 1.0
transaction-manager-0.3.1
Not possible to configure transaction timeout
-
Key: ARIES-809
URL: https://issues.apache.org/jira/browse/ARIES-809
Project: Aries
Issue Type: Bug
Components: Transaction
Affects Versions: 0.3
Environment: Windows XP, Karaf 2.2.5
Reporter: Bengt Rodehav
Assignee: Guillaume Nodet
Fix For: transaction-manager-0.3.1, 1.0
Attachments: ARIES-809.patch
There seems to be a flaw regarding configuration of the transaction manager.
It should be possible to configure the transaction manager using the PID
org.apache.aries.transaction but but this doesn't work. Even if this PID is
bound to the transaction manager it doesn't pick up the new configuration but
uses the default values anyway.
I have tested configuration of the transaction timeout (which doesn't work)
but I suspect that the transaction manager doesn't pick up any configuration.
I know that ServiceMix sets the logFileDir property to
${karaf.data}/txlog/ which I suspect doesn't work either.
This has been discussed on the Aries user list at:
http://mail-archives.apache.org/mod_mbox/aries-user/201112.mbox/%3CCAJ0TPGLo=u=bf+ep0hg2djjzatfokv8kbmn5hflkswfw8-j...@mail.gmail.com%3E
--
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-838) ClassCircularityError in BlueprintContainerImpl when using a security manager
[ https://issues.apache.org/jira/browse/ARIES-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-838: -- Fix Version/s: 1.0 blueprint-core-0.3.2 ClassCircularityError in BlueprintContainerImpl when using a security manager - Key: ARIES-838 URL: https://issues.apache.org/jira/browse/ARIES-838 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: blueprint-core-0.3.2, 1.0 Attachments: ARIES-838.patch -- 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-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
[ https://issues.apache.org/jira/browse/ARIES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-802: -- Fix Version/s: blueprint-core-0.3.2 dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component -- Key: ARIES-802 URL: https://issues.apache.org/jira/browse/ARIES-802 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: blueprint-core-0.4.1 Environment: karaf 2.2.4 Reporter: Aki Yoshida Fix For: blueprint-0.4.0, blueprint-core-0.3.2 Attachments: patch.diff I saw this problem several months ago. This problem still occurs in the current trunk 0.4.1-snapshot. I have two bundles A and B running and A depends on B. In my concrete case, A is an application scenario bundle depending on B the cxf bundle. Initially, both are running and have status Active. When I stop B, A goes to status GracePeriod. When I start B again, A is started but does not come back to status Active but goes to status Failure with the following error: 2011-12-14 01:12:49,755 | ERROR | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 362 | 10 - org.apache.aries.blueprint - 0.4.1.SNAPSHOT | Unable to start blueprint container for bundle tmp.test-osgi-cxf-provider-bp org.apache.aries.blueprint.ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component at org.apache.aries.blueprint.parser.ComponentDefinitionRegistryImpl.registerComponentDefinition(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24] at java.lang.Thread.run(Thread.java:662)[:1.6.0_24] The cause of this problem seems to be that this bundle's blueprint container's component definition map is not cleared up prior to getting restarted. This calls ComponentRegistryImpl's registerComponentDefinition and this method checks if the same named component is already in the map. I added a line of code to clear up the definition map and this made the bundle start and its status go to Active. Please take a look at the attached file. Regards, aki -- 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-612) cannot access referenced service in destroy-method
[ https://issues.apache.org/jira/browse/ARIES-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-612: -- Fix Version/s: blueprint-core-0.3.2 cannot access referenced service in destroy-method -- Key: ARIES-612 URL: https://issues.apache.org/jira/browse/ARIES-612 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.3 Environment: Ubuntu Reporter: Tang Kin Chuen Assignee: Alasdair Nottingham Fix For: blueprint uber bundle 0.4, blueprint.core-0.4, blueprint.itests-0.4, blueprint.sample-0.4, blueprint-core-0.3.2 I've got a working blueprint bundle to register some default OBR repositories on initialization of the bundle. The xml config looks like: ?xml version=1.0 encoding=UTF-8 standalone=no? blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; bean class=xxx.yyy.RepositoryRegistrationBean init-method=init destroy-method=shutdown argument index=0 ref=blueprintBundleContext/ argument index=1 ref=repositoryAdmin/ /bean reference id=repositoryAdmin interface=org.apache.felix.bundlerepository.RepositoryAdmin /reference /blueprint Both BundleContext RepositoryAdmin are injected to RepositoryRegistrationBean's constructor. The init() works. However, when i try to access the RepositoryAdmin during shutdown(), i got this exception: 2011-03-15 22:06:49,899 INFO [Thread:Gogo shell] [8/org.apache.aries.blueprint/0.3.0] org.apache.aries.blueprint.container.BeanRecipe - Error invoking destroy method org.osgi.service.blueprint.container.ServiceUnavailableException: The Blueprint container is being or has been destroyed at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:176) at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:49) at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:201) at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50) at org.apache.aries.proxy.impl.DefaultWrapper.invoke(DefaultWrapper.java:31) at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:78) at $Proxy6.removeRepository(Unknown Source) at play.osgi.bundle.config.RepositoryRegistrationBean.shutdown(RepositoryRegistrationBean.java:39) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_24] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_24] Reference mailing list entry http://bit.ly/e0WbRk -- 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-613) use error() instead of info() log in BeanRecipe's destroy() on exception
[ https://issues.apache.org/jira/browse/ARIES-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-613: -- Fix Version/s: blueprint-core-0.3.2 use error() instead of info() log in BeanRecipe's destroy() on exception Key: ARIES-613 URL: https://issues.apache.org/jira/browse/ARIES-613 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.3 Reporter: Tang Kin Chuen Assignee: Alasdair Nottingham Priority: Trivial Fix For: blueprint uber bundle 0.4, blueprint.core-0.4, blueprint-core-0.3.2 Suggesting to change the following line in org.apache.aries.blueprint.container.BeanRecipe's destroy() to LOGGER.error. LOGGER.info(Error invoking destroy method, getRealCause(e)); 2011-03-15 22:21:04,760 INFO [Thread:Gogo shell] [8/org.apache.aries.blueprint/0.3.0] org.apache.aries.blueprint.container.BeanRecipe - Error invoking destroy method org.osgi.service.blueprint.container.ServiceUnavailableException: The Blueprint container is being or has been destroyed at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:176) at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:49) at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:201) at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50) It is a trivial thing, but helps in troubleshooting. -- 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-568) More memory leaks
[ https://issues.apache.org/jira/browse/ARIES-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-568: -- Fix Version/s: blueprint-core-0.3.2 More memory leaks - Key: ARIES-568 URL: https://issues.apache.org/jira/browse/ARIES-568 Project: Aries Issue Type: Bug Components: Blueprint, Util Affects Versions: 0.4 Reporter: Valentin Mahrwald Assignee: Valentin Mahrwald Fix For: util-0.4, blueprint uber bundle 0.4, blueprint.core-0.4, blueprint-core-0.3.2 I have seen at least two more memory leaks in the Apache Aries stack: - org.apache.aries.blueprint.utils.ReflectionUtils keeps a WeakHashMap of property descriptors that is not cleared out - org.apache.aries.util.tracker.InternalRecursiveBundleTracker keeps a Set of BundleContext objects that is not cleared out due to a bug -- 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-720) Improve waiting for namespace handler message
[ https://issues.apache.org/jira/browse/ARIES-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated ARIES-720: -- Fix Version/s: blueprint-core-0.3.2 Improve waiting for namespace handler message - Key: ARIES-720 URL: https://issues.apache.org/jira/browse/ARIES-720 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: blueprint-0.3.1 Reporter: Alasdair Nottingham Assignee: Alasdair Nottingham Fix For: blueprint uber bundle 0.4, blueprint.core-0.4, blueprint-core-0.3.2 The waiting for blueprint namespace handlers message attempts to pass the filters for the namespace handlers into the error message, but the message doesn't contain the insert marker. Need to add the insert marker. -- 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: [VOTE] Apache Aries release candidate parent-1.0.0
+1 David On 12 May 2012 13:00, Holly Cummins holly.k.cumm...@googlemail.com wrote: I've staged a release candidate for the Aries 1.0.0 parent module. The module is staged and tagged in https://svn.apache.org/repos/asf/aries/tags/parent-1.0.0/. The artifacts are in one staged repo, https://repository.apache.org/content/repositories/orgapachearies-113/. Links to the *.zip files for each module are provided below. The only module staged is the parent module: https://repository.apache.org/content/repositories/orgapachearies-079/org/apache/aries/parent/1.0.0/parent-1.0.0-source-release.zip The RAT and IANAL build checks passed. The vote will be open for 72 hours. [ ] +1 [ ] 0 [ ] -1 Holly
[jira] [Updated] (ARIES-851) BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times for the same event.
[
https://issues.apache.org/jira/browse/ARIES-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Gritschenberger updated ARIES-851:
Attachment: (was: bundletracker-test.zip)
BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times
for the same event.
---
Key: ARIES-851
URL: https://issues.apache.org/jira/browse/ARIES-851
Project: Aries
Issue Type: Bug
Components: JPA, Util
Environment: Linux-3.0.0, Karaf-3.0.0-SNAPSHOT with Felix, openjdk-6
Reporter: Christoph Gritschenberger
Attachments: ARIES-851-stacktrace.TXT,
BundleHookBundleTracker-solution1.patch,
BundleHookBundleTracker-solution2.patch, jpa-test-bundle-src.zip,
persistence-feature.xml, test.jpa.bundle-0.1.0-SNAPSHOT.jar
Steps to reproduce
* Compile or get a karaf-3.0.0-SNAPSHOT and unpack it
* Install openjpa-2.2.0 (using the attached feature-file)
* Deploy a bundle containing a persistence-unit (attached jar for example)
get the following Exception 4 times:
{code}
ERROR: Bundle org.apache.aries.jpa.container [78] EventDispatcher: Error
during dispatch. (java.lang.IllegalStateException: Unable to create
persistence units for the bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as
previous persistence units already exist.)
java.lang.IllegalStateException: Unable to create persistence units for the
bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as previous persistence units
already exist.
{code}
See attachment for full stacktrace
In subsequent startups the Exception is still thrown but the stacktrace does
not show in the console or the log.
Also when using equinox the Stacktrace does not appear in either the console
or the log ever, but it's still thrown.
The problem is that the PersistenceBundleManager#addingBundle is called
multiple times for the newly installed bundle.
The PersistenceBundleManager is passed as a BundleTrackerCustomizer to a
BundleHookBundleTracker.
The BundleHookBundleTracker stores it in it's own private attribute and also
passes it to it's super-constructor.
So the customizer is stored in the instance twice.
It's called by both BundleTracker$Tracked.customizerAdding and
BundleHookBundleTracker$Tracked.customizerAdding.
Both Tracked recognize the bundle as untracked and call the
addingBundle-method.
--
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-851) BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times for the same event.
[
https://issues.apache.org/jira/browse/ARIES-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Gritschenberger updated ARIES-851:
Attachment: bundletracker-test.zip
BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times
for the same event.
---
Key: ARIES-851
URL: https://issues.apache.org/jira/browse/ARIES-851
Project: Aries
Issue Type: Bug
Components: JPA, Util
Environment: Linux-3.0.0, Karaf-3.0.0-SNAPSHOT with Felix, openjdk-6
Reporter: Christoph Gritschenberger
Attachments: ARIES-851-stacktrace.TXT,
BundleHookBundleTracker-solution1.patch,
BundleHookBundleTracker-solution2.patch, jpa-test-bundle-src.zip,
persistence-feature.xml, test.jpa.bundle-0.1.0-SNAPSHOT.jar
Steps to reproduce
* Compile or get a karaf-3.0.0-SNAPSHOT and unpack it
* Install openjpa-2.2.0 (using the attached feature-file)
* Deploy a bundle containing a persistence-unit (attached jar for example)
get the following Exception 4 times:
{code}
ERROR: Bundle org.apache.aries.jpa.container [78] EventDispatcher: Error
during dispatch. (java.lang.IllegalStateException: Unable to create
persistence units for the bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as
previous persistence units already exist.)
java.lang.IllegalStateException: Unable to create persistence units for the
bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as previous persistence units
already exist.
{code}
See attachment for full stacktrace
In subsequent startups the Exception is still thrown but the stacktrace does
not show in the console or the log.
Also when using equinox the Stacktrace does not appear in either the console
or the log ever, but it's still thrown.
The problem is that the PersistenceBundleManager#addingBundle is called
multiple times for the newly installed bundle.
The PersistenceBundleManager is passed as a BundleTrackerCustomizer to a
BundleHookBundleTracker.
The BundleHookBundleTracker stores it in it's own private attribute and also
passes it to it's super-constructor.
So the customizer is stored in the instance twice.
It's called by both BundleTracker$Tracked.customizerAdding and
BundleHookBundleTracker$Tracked.customizerAdding.
Both Tracked recognize the bundle as untracked and call the
addingBundle-method.
--
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-851) BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times for the same event.
[
https://issues.apache.org/jira/browse/ARIES-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Gritschenberger updated ARIES-851:
Attachment: test.bundletracker.bundle-0.1.0-SNAPSHOT.jar
bundletracker-test-src.zip
I also found a way to illustriate the behaviour with plain felix.
Download and start felix-4.0.2
felix:install file:/path/to/org.apache.aries.util-1.0.0-SNAPSHOT.jar
start id
felix:install file:/path/to/test.bundletracker.bundle-0.1.0-SNAPSHOT.jar
start id
then install any bundle (e.g. commons-collections) and watch how often the
bundletracker prints the event
felix:install file:/path/to/commons-collections-3.2.1.jar
{code}
g! felix:lb
START LEVEL 1
ID|State |Level|Name
0|Active |0|System Bundle (4.0.2)
1|Active |1|Apache Felix Bundle Repository (1.6.6)
2|Active |1|Apache Felix Gogo Command (0.12.0)
3|Active |1|Apache Felix Gogo Runtime (0.10.0)
4|Active |1|Apache Felix Gogo Shell (0.10.0)
5|Active |1|Test :: BundleTracker :: Bundle (0.1.0.SNAPSHOT)
7|Active |1|Apache Aries Util (1.0.0.SNAPSHOT)
9|Installed |1|Commons Collections (3.2.1)
g! felix:start 9
Event: org.osgi.framework.BundleEvent[source=org.apache.commons.collections [9]]
modified bundleorg.apache.commons.collections
Event: org.osgi.framework.BundleEvent[source=org.apache.commons.collections [9]]
modified bundleorg.apache.commons.collections
Event: org.osgi.framework.BundleEvent[source=org.apache.commons.collections [9]]
modified bundleorg.apache.commons.collections
Event: org.osgi.framework.BundleEvent[source=org.apache.commons.collections [9]]
modified bundleorg.apache.commons.collections
Event: org.osgi.framework.BundleEvent[source=org.apache.commons.collections [9]]
modified bundleorg.apache.commons.collections
Event: org.osgi.framework.BundleEvent[source=org.apache.commons.collections [9]]
modified bundleorg.apache.commons.collections
{code}
BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times
for the same event.
---
Key: ARIES-851
URL: https://issues.apache.org/jira/browse/ARIES-851
Project: Aries
Issue Type: Bug
Components: JPA, Util
Environment: Linux-3.0.0, Karaf-3.0.0-SNAPSHOT with Felix, openjdk-6
Reporter: Christoph Gritschenberger
Attachments: ARIES-851-stacktrace.TXT,
BundleHookBundleTracker-solution1.patch,
BundleHookBundleTracker-solution2.patch, bundletracker-test-src.zip,
jpa-test-bundle-src.zip, persistence-feature.xml,
test.bundletracker.bundle-0.1.0-SNAPSHOT.jar,
test.jpa.bundle-0.1.0-SNAPSHOT.jar
Steps to reproduce
* Compile or get a karaf-3.0.0-SNAPSHOT and unpack it
* Install openjpa-2.2.0 (using the attached feature-file)
* Deploy a bundle containing a persistence-unit (attached jar for example)
get the following Exception 4 times:
{code}
ERROR: Bundle org.apache.aries.jpa.container [78] EventDispatcher: Error
during dispatch. (java.lang.IllegalStateException: Unable to create
persistence units for the bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as
previous persistence units already exist.)
java.lang.IllegalStateException: Unable to create persistence units for the
bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as previous persistence units
already exist.
{code}
See attachment for full stacktrace
In subsequent startups the Exception is still thrown but the stacktrace does
not show in the console or the log.
Also when using equinox the Stacktrace does not appear in either the console
or the log ever, but it's still thrown.
The problem is that the PersistenceBundleManager#addingBundle is called
multiple times for the newly installed bundle.
The PersistenceBundleManager is passed as a BundleTrackerCustomizer to a
BundleHookBundleTracker.
The BundleHookBundleTracker stores it in it's own private attribute and also
passes it to it's super-constructor.
So the customizer is stored in the instance twice.
It's called by both BundleTracker$Tracked.customizerAdding and
BundleHookBundleTracker$Tracked.customizerAdding.
Both Tracked recognize the bundle as untracked and call the
addingBundle-method.
--
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
Please test 0.3.x snapshots....
Guillaume and I have gone through and pulled back several bug fixes for couple of the bundles based on the older 0.3.x releases and now have some new snapshots deployed. It would be great if the various interested parties could take a quick look and test them out. I'd like to start the release process for them possibly on Thursday. The svn branch for the changes is at: https://svn.apache.org/repos/asf/aries/branches/blueprint-0.3.2-fixes which is now a bit mis-named as we also have fixes for utils, jmx, and transaction manager in there.Anyway, please speak up if there are additional issues or problems. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Resolved] (ARIES-851) BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times for the same event.
[
https://issues.apache.org/jira/browse/ARIES-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved ARIES-851.
---
Resolution: Fixed
Fix Version/s: 1.0
Assignee: Guillaume Nodet
Fixed by removing calls to super.open() and super.close()
BundleTrackerCustomizer in BundleHookBundleTracker is called multiple times
for the same event.
---
Key: ARIES-851
URL: https://issues.apache.org/jira/browse/ARIES-851
Project: Aries
Issue Type: Bug
Components: JPA, Util
Environment: Linux-3.0.0, Karaf-3.0.0-SNAPSHOT with Felix, openjdk-6
Reporter: Christoph Gritschenberger
Assignee: Guillaume Nodet
Fix For: 1.0
Attachments: ARIES-851-stacktrace.TXT,
BundleHookBundleTracker-solution1.patch,
BundleHookBundleTracker-solution2.patch, bundletracker-test-src.zip,
jpa-test-bundle-src.zip, persistence-feature.xml,
test.bundletracker.bundle-0.1.0-SNAPSHOT.jar,
test.jpa.bundle-0.1.0-SNAPSHOT.jar
Steps to reproduce
* Compile or get a karaf-3.0.0-SNAPSHOT and unpack it
* Install openjpa-2.2.0 (using the attached feature-file)
* Deploy a bundle containing a persistence-unit (attached jar for example)
get the following Exception 4 times:
{code}
ERROR: Bundle org.apache.aries.jpa.container [78] EventDispatcher: Error
during dispatch. (java.lang.IllegalStateException: Unable to create
persistence units for the bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as
previous persistence units already exist.)
java.lang.IllegalStateException: Unable to create persistence units for the
bundle test.jpa.test.jpa.bundle/0.1.0.SNAPSHOT as previous persistence units
already exist.
{code}
See attachment for full stacktrace
In subsequent startups the Exception is still thrown but the stacktrace does
not show in the console or the log.
Also when using equinox the Stacktrace does not appear in either the console
or the log ever, but it's still thrown.
The problem is that the PersistenceBundleManager#addingBundle is called
multiple times for the newly installed bundle.
The PersistenceBundleManager is passed as a BundleTrackerCustomizer to a
BundleHookBundleTracker.
The BundleHookBundleTracker stores it in it's own private attribute and also
passes it to it's super-constructor.
So the customizer is stored in the instance twice.
It's called by both BundleTracker$Tracked.customizerAdding and
BundleHookBundleTracker$Tracked.customizerAdding.
Both Tracked recognize the bundle as untracked and call the
addingBundle-method.
--
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] [Created] (ARIES-855) Blueprint should attempt to load static nested classes when the initial attempt to load a class has failed
Sergey Beryozkin created ARIES-855:
--
Summary: Blueprint should attempt to load static nested classes
when the initial attempt to load a class has failed
Key: ARIES-855
URL: https://issues.apache.org/jira/browse/ARIES-855
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
At the moment the Blueprint schema blocks the static nested class names,
example, trying to get SimpleBean#Nested:
{code:java}
public class SimpleBean {
public static Nested {
}
}
{code}
referenced as SimpleBean#Nested in a blueprint context fails with the
validation error.
As proposed at the Osgi-dev by BJ H., the implementation should attempt to load
a nested class if the original load attempt fails.
--
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-855) Blueprint should attempt to load static nested classes when the initial attempt to load a class has failed
[
https://issues.apache.org/jira/browse/ARIES-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated ARIES-855:
---
Attachment: aries855.txt
The proposed patch does a single recursion attempt only, given that no use
cases for supporting the deeply nested static classes exists and also to make
the delay in throwing the load exception very minimal.
During the single recursive call only the top level catch block will report an
error log message, and a debug one in case of attempting a retry.
This can be extended to manage nested hierarchies if really needed
Blueprint should attempt to load static nested classes when the initial
attempt to load a class has failed
--
Key: ARIES-855
URL: https://issues.apache.org/jira/browse/ARIES-855
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
Attachments: aries855.txt
At the moment the Blueprint schema blocks the static nested class names,
example, trying to get SimpleBean#Nested:
{code:java}
public class SimpleBean {
public static Nested {
}
}
{code}
referenced as SimpleBean#Nested in a blueprint context fails with the
validation error.
As proposed at the Osgi-dev by BJ H., the implementation should attempt to
load a nested class if the original load attempt fails.
--
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
I've attached a simple patch to https://issues.apache.org/jira/browse/ARIES-855 Let me know please if you think it can be committed now or expect a bit more work done on it. Right now I'm thinking that retrying once only in case of the bean load failure is reasonable. Introducing a system property telling the catch block to fail immediately without a retry might make sense, but I was not sure it was really needed Cheers, Sergey On 14/05/12 11:57, Sergey Beryozkin wrote: Hi All I managed to click on the link leading to the subscription page :-) and eventually forwarded the original post to the osgi-dev Thanks, Sergey On 11/05/12 13:49, David Bosschaert wrote: Just for clarity, the mailing lists and bugzilla instance mentioned before [1] www.osgi.org/bugzilla [2] http://www.osgi.org/MailLists/HomePage are open to anyone. But yes, in order to post to the mailing list you probably need to subscribe first. Cheers, David On 11 May 2012 13:16, Jeremy Hugheshugh...@apache.org wrote: Hi, in order to post, you'll need to subscribe to the list. Otherwise you won't get any responses. Are you saying that you couldn't subscribe either? For each list in the table there is the mailto: link (middle column) and a link to subscribe page (left hand column). HTH, Jeremy On 4 May 2012 16:10, Sergey Beryozkinsberyoz...@gmail.com wrote: 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
Re: Please test 0.3.x snapshots....
On Tuesday, May 22, 2012 07:58:16 PM David Bosschaert wrote: Hi Dan, Is there a list of the changes that were applied to JMX (or do you know of a command to find this out) so I can apply them to jmx-next as well? ARIES-663 and ARIES-782 svn diff -c 1341249 svn diff -c 1341248 Dan Cheers, David On 22 May 2012 16:43, Daniel Kulp dk...@apache.org wrote: Guillaume and I have gone through and pulled back several bug fixes for couple of the bundles based on the older 0.3.x releases and now have some new snapshots deployed. It would be great if the various interested parties could take a quick look and test them out. I'd like to start the release process for them possibly on Thursday. The svn branch for the changes is at: https://svn.apache.org/repos/asf/aries/branches/blueprint-0.3.2-fixes which is now a bit mis-named as we also have fixes for utils, jmx, and transaction manager in there.Anyway, please speak up if there are additional issues or problems. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
