[jira] [Closed] (ARIES-2073) Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods
[ https://issues.apache.org/jira/browse/ARIES-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek closed ARIES-2073. --- Resolution: Fixed > Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods > --- > > Key: ARIES-2073 > URL: https://issues.apache.org/jira/browse/ARIES-2073 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.7.3 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: transaction-blueprint-2.3.1 > > > When calling two methods, one with REQUIRES and one with SUPPORTS behaviour, > JPA access in the 2nd method should look up the existing EM associated with > previous coordination. No new coordination should be created. > SUPPORTS case is one (of six) missing behavior after some work was done in > ARIES-2050. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARIES-2075) transaction-blueprint Coordinations should check existing TX
[
https://issues.apache.org/jira/browse/ARIES-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek closed ARIES-2075.
---
> transaction-blueprint Coordinations should check existing TX
>
>
> Key: ARIES-2075
> URL: https://issues.apache.org/jira/browse/ARIES-2075
> Project: Aries
> Issue Type: Bug
>Affects Versions: transaction-blueprint-2.3.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: transaction-blueprint-2.3.1
>
>
> I have this unannotated method:
> {code:java}
> transactionManager.begin();
> try {
> nestedTestService.testExternalTransaction();
> } finally {
> transactionManager.rollback();
> }
> {code}
> And this annotated {{nestedTestService.testExternalTransaction()}}:
> {code:java}
> @Transactional(TxType.REQUIRED)
> public void testExternalTransaction() {
> TestEntity testEntity = testDao.createNew();
> ...
> {code}
> While the dao uses this EntityManager with the support from {{ />}}:
> {code:java}
> @PersistenceContext(unitName = "unit.1")
> private EntityManager entityManager;
> {code}
> The problem is that after ARIES-2050 fixes,
> {{org.apache.aries.transaction.TxInterceptorImpl#preCall()}} is not blindly
> creating new coordination if there's existing transaction.
> ARIES-2050 fix was not complete (see also ARIES-2073) but also I've
> mishandled the scenario where transaction is created not by another
> {{TxInterceptorImpl.preCall()}}, but by manual
> {{javax.transaction.TransactionManager#begin()}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARIES-2075) transaction-blueprint Coordinations should check existing TX
[
https://issues.apache.org/jira/browse/ARIES-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved ARIES-2075.
-
Resolution: Fixed
> transaction-blueprint Coordinations should check existing TX
>
>
> Key: ARIES-2075
> URL: https://issues.apache.org/jira/browse/ARIES-2075
> Project: Aries
> Issue Type: Bug
>Affects Versions: transaction-blueprint-2.3.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: transaction-blueprint-2.3.1
>
>
> I have this unannotated method:
> {code:java}
> transactionManager.begin();
> try {
> nestedTestService.testExternalTransaction();
> } finally {
> transactionManager.rollback();
> }
> {code}
> And this annotated {{nestedTestService.testExternalTransaction()}}:
> {code:java}
> @Transactional(TxType.REQUIRED)
> public void testExternalTransaction() {
> TestEntity testEntity = testDao.createNew();
> ...
> {code}
> While the dao uses this EntityManager with the support from {{ />}}:
> {code:java}
> @PersistenceContext(unitName = "unit.1")
> private EntityManager entityManager;
> {code}
> The problem is that after ARIES-2050 fixes,
> {{org.apache.aries.transaction.TxInterceptorImpl#preCall()}} is not blindly
> creating new coordination if there's existing transaction.
> ARIES-2050 fix was not complete (see also ARIES-2073) but also I've
> mishandled the scenario where transaction is created not by another
> {{TxInterceptorImpl.preCall()}}, but by manual
> {{javax.transaction.TransactionManager#begin()}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARIES-2073) Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods
[ https://issues.apache.org/jira/browse/ARIES-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek updated ARIES-2073: Fix Version/s: transaction-blueprint-2.3.1 > Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods > --- > > Key: ARIES-2073 > URL: https://issues.apache.org/jira/browse/ARIES-2073 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.7.3 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > Fix For: transaction-blueprint-2.3.1 > > > When calling two methods, one with REQUIRES and one with SUPPORTS behaviour, > JPA access in the 2nd method should look up the existing EM associated with > previous coordination. No new coordination should be created. > SUPPORTS case is one (of six) missing behavior after some work was done in > ARIES-2050. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARIES-2075) transaction-blueprint Coordinations should check existing TX
[
https://issues.apache.org/jira/browse/ARIES-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-2075:
Fix Version/s: transaction-blueprint-2.3.1
> transaction-blueprint Coordinations should check existing TX
>
>
> Key: ARIES-2075
> URL: https://issues.apache.org/jira/browse/ARIES-2075
> Project: Aries
> Issue Type: Bug
>Affects Versions: transaction-blueprint-2.3.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: transaction-blueprint-2.3.1
>
>
> I have this unannotated method:
> {code:java}
> transactionManager.begin();
> try {
> nestedTestService.testExternalTransaction();
> } finally {
> transactionManager.rollback();
> }
> {code}
> And this annotated {{nestedTestService.testExternalTransaction()}}:
> {code:java}
> @Transactional(TxType.REQUIRED)
> public void testExternalTransaction() {
> TestEntity testEntity = testDao.createNew();
> ...
> {code}
> While the dao uses this EntityManager with the support from {{ />}}:
> {code:java}
> @PersistenceContext(unitName = "unit.1")
> private EntityManager entityManager;
> {code}
> The problem is that after ARIES-2050 fixes,
> {{org.apache.aries.transaction.TxInterceptorImpl#preCall()}} is not blindly
> creating new coordination if there's existing transaction.
> ARIES-2050 fix was not complete (see also ARIES-2073) but also I've
> mishandled the scenario where transaction is created not by another
> {{TxInterceptorImpl.preCall()}}, but by manual
> {{javax.transaction.TransactionManager#begin()}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARIES-2075) transaction-blueprint Coordinations should check existing TX
[
https://issues.apache.org/jira/browse/ARIES-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521000#comment-17521000
]
Grzegorz Grzybek commented on ARIES-2075:
-
PR: https://github.com/apache/aries/pull/151
> transaction-blueprint Coordinations should check existing TX
>
>
> Key: ARIES-2075
> URL: https://issues.apache.org/jira/browse/ARIES-2075
> Project: Aries
> Issue Type: Bug
>Affects Versions: transaction-blueprint-2.3.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I have this unannotated method:
> {code:java}
> transactionManager.begin();
> try {
> nestedTestService.testExternalTransaction();
> } finally {
> transactionManager.rollback();
> }
> {code}
> And this annotated {{nestedTestService.testExternalTransaction()}}:
> {code:java}
> @Transactional(TxType.REQUIRED)
> public void testExternalTransaction() {
> TestEntity testEntity = testDao.createNew();
> ...
> {code}
> While the dao uses this EntityManager with the support from {{ />}}:
> {code:java}
> @PersistenceContext(unitName = "unit.1")
> private EntityManager entityManager;
> {code}
> The problem is that after ARIES-2050 fixes,
> {{org.apache.aries.transaction.TxInterceptorImpl#preCall()}} is not blindly
> creating new coordination if there's existing transaction.
> ARIES-2050 fix was not complete (see also ARIES-2073) but also I've
> mishandled the scenario where transaction is created not by another
> {{TxInterceptorImpl.preCall()}}, but by manual
> {{javax.transaction.TransactionManager#begin()}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (ARIES-2075) transaction-blueprint Coordinations should check existing TX
Grzegorz Grzybek created ARIES-2075:
---
Summary: transaction-blueprint Coordinations should check existing
TX
Key: ARIES-2075
URL: https://issues.apache.org/jira/browse/ARIES-2075
Project: Aries
Issue Type: Bug
Affects Versions: transaction-blueprint-2.3.0
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
I have this unannotated method:
{code:java}
transactionManager.begin();
try {
nestedTestService.testExternalTransaction();
} finally {
transactionManager.rollback();
}
{code}
And this annotated {{nestedTestService.testExternalTransaction()}}:
{code:java}
@Transactional(TxType.REQUIRED)
public void testExternalTransaction() {
TestEntity testEntity = testDao.createNew();
...
{code}
While the dao uses this EntityManager with the support from {{}}:
{code:java}
@PersistenceContext(unitName = "unit.1")
private EntityManager entityManager;
{code}
The problem is that after ARIES-2050 fixes,
{{org.apache.aries.transaction.TxInterceptorImpl#preCall()}} is not blindly
creating new coordination if there's existing transaction.
ARIES-2050 fix was not complete (see also ARIES-2073) but also I've mishandled
the scenario where transaction is created not by another
{{TxInterceptorImpl.preCall()}}, but by manual
{{javax.transaction.TransactionManager#begin()}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (ARIES-2073) Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods
[ https://issues.apache.org/jira/browse/ARIES-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519629#comment-17519629 ] Grzegorz Grzybek commented on ARIES-2073: - PR: https://github.com/apache/aries/pull/151 > Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods > --- > > Key: ARIES-2073 > URL: https://issues.apache.org/jira/browse/ARIES-2073 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.7.3 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek >Priority: Major > > When calling two methods, one with REQUIRES and one with SUPPORTS behaviour, > JPA access in the 2nd method should look up the existing EM associated with > previous coordination. No new coordination should be created. > SUPPORTS case is one (of six) missing behavior after some work was done in > ARIES-2050. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARIES-2073) Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods
Grzegorz Grzybek created ARIES-2073: --- Summary: Aries JPA 2.7 wrong behavior with SUPPORTS transaction methods Key: ARIES-2073 URL: https://issues.apache.org/jira/browse/ARIES-2073 Project: Aries Issue Type: Bug Components: JPA Affects Versions: jpa-2.7.3 Reporter: Grzegorz Grzybek Assignee: Grzegorz Grzybek When calling two methods, one with REQUIRES and one with SUPPORTS behaviour, JPA access in the 2nd method should look up the existing EM associated with previous coordination. No new coordination should be created. SUPPORTS case is one (of six) missing behavior after some work was done in ARIES-2050. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARIES-2072) Aries CDI doesn't support Java 17
[
https://issues.apache.org/jira/browse/ARIES-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519419#comment-17519419
]
Grzegorz Grzybek commented on ARIES-2072:
-
So it's not Aries fault, it's Pax Web 7.3 which uses XBean to check annotations.
BTW, Pax Web 8 doesn't use XBean (and even ASM) at all. For class scanning it
uses BCEL (reusing tomcat-scanner-util).
> Aries CDI doesn't support Java 17
> -
>
> Key: ARIES-2072
> URL: https://issues.apache.org/jira/browse/ARIES-2072
> Project: Aries
> Issue Type: Bug
> Components: CDI
>Affects Versions: cdi-1.1.5
> Environment: Apache Karaf 4.3.6
> Openjdk 17
> Fedora 36
>Reporter: Jakub Herkel
>Priority: Major
>
> I tried the latest unreleased version 1.1.5 with a Apache Karaf running under
> Java17 (with classes compiled with Java17) and I can see this exception:
> {code:java}
> The activate method has thrown an exception
> java.lang.IllegalArgumentException: Unsupported class file major version 61
> at org.apache.xbean.asm8.ClassReader.(ClassReader.java:196) ~[?:?]
> at org.apache.xbean.asm8.ClassReader.(ClassReader.java:177) ~[?:?]
> at org.apache.xbean.asm8.ClassReader.(ClassReader.java:163) ~[?:?]
> at org.apache.xbean.asm8.ClassReader.(ClassReader.java:284) ~[?:?]
> at
> org.apache.xbean.finder.BundleAssignableClassFinder.isSuperClassAssignable(BundleAssignableClassFinder.java:222)
> ~[?:?]
> at
> org.apache.xbean.finder.BundleAssignableClassFinder.isClassAcceptable(BundleAssignableClassFinder.java:114)
> ~[?:?]
> at
> org.apache.xbean.finder.BundleAssignableClassFinder.isClassAcceptable(BundleAssignableClassFinder.java:125)
> ~[?:?]
> at
> org.apache.xbean.osgi.bundle.util.BundleClassFinder.scanDirectory(BundleClassFinder.java:257)
> ~[?:?] {code}
> Probably aries cdi should be updated from org.apache.xbean/xbean-asm8-shaded
> to xbean-asm9-shaded.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARIES-2053) aries-cdi-extension-el-jsp has unresolved property in JavaJSP contract
[
https://issues.apache.org/jira/browse/ARIES-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-2053:
Affects Version/s: cdi-1.1.3
> aries-cdi-extension-el-jsp has unresolved property in JavaJSP contract
> --
>
> Key: ARIES-2053
> URL: https://issues.apache.org/jira/browse/ARIES-2053
> Project: Aries
> Issue Type: Bug
>Affects Versions: cdi-1.1.3
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> If you check
> https://github.com/apache/aries-cdi/blob/org.apache.aries.cdi-1.1.3/cdi-extension-el-jsp/src/main/java/org/apache/aries/cdi/extension/el/jsp/package-info.java#L40
> there's {{jsp.version}} property, but it's unresolved during build time and
> the resulting META-INF/MANIFEST.MF requirement is:
> {noformat}
> Require-Capability: osgi.contract;filter:="(&(osgi.contract=JavaJSP)(v
> ersion=${jsp.version}))";osgi.contract=JavaJSP,...
> {noformat}
> at runtime, I'm getting:
> {noformat}
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.aries.cdi.extension.el.jsp [61](R 61.0): \
> missing requirement [org.apache.aries.cdi.extension.el.jsp [61](R 61.0)] \
> osgi.contract; (&(osgi.contract=JavaJSP)(version=${jsp.version}))
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARIES-2053) aries-cdi-extension-el-jsp has unresolved property in JavaJSP contract
Grzegorz Grzybek created ARIES-2053:
---
Summary: aries-cdi-extension-el-jsp has unresolved property in
JavaJSP contract
Key: ARIES-2053
URL: https://issues.apache.org/jira/browse/ARIES-2053
Project: Aries
Issue Type: Bug
Reporter: Grzegorz Grzybek
If you check
https://github.com/apache/aries-cdi/blob/org.apache.aries.cdi-1.1.3/cdi-extension-el-jsp/src/main/java/org/apache/aries/cdi/extension/el/jsp/package-info.java#L40
there's {{jsp.version}} property, but it's unresolved during build time and
the resulting META-INF/MANIFEST.MF requirement is:
{noformat}
Require-Capability: osgi.contract;filter:="(&(osgi.contract=JavaJSP)(v
ersion=${jsp.version}))";osgi.contract=JavaJSP,...
{noformat}
at runtime, I'm getting:
{noformat}
org.osgi.framework.BundleException: Unable to resolve
org.apache.aries.cdi.extension.el.jsp [61](R 61.0): \
missing requirement [org.apache.aries.cdi.extension.el.jsp [61](R 61.0)] \
osgi.contract; (&(osgi.contract=JavaJSP)(version=${jsp.version}))
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARIES-2052) ProxyServices#supportsClassDefining() in weld 3.1.7 breaks aries-cdi
Grzegorz Grzybek created ARIES-2052:
---
Summary: ProxyServices#supportsClassDefining() in weld 3.1.7
breaks aries-cdi
Key: ARIES-2052
URL: https://issues.apache.org/jira/browse/ARIES-2052
Project: Aries
Issue Type: Bug
Reporter: Grzegorz Grzybek
https://issues.redhat.com/browse/WELD-2581 (fixed in weld 3.1.7+) changed
WeldStartup behavior from:
{code:java}
if (!registry.get(ProxyServices.class).supportsClassDefining()) {
// we will need to invoke CL.defineClass() ourselves, crack open those
methods eagerly
ClassFileUtils.makeClassLoaderMethodsAccessible();
}
{code}
to:
{code:java}
ProxyServices proxyServices = registry.get(ProxyServices.class);
if (!proxyServices.supportsClassDefining()) {
throw
BootstrapLogger.LOG.proxyServicesWithoutClassDefining(proxyServices.getClass().getName());
}
{code}
However {{org.apache.aries.cdi.weld.BundleResourcesLoader()}} doesn't override
default method from the ProxyServices interface:
{code:java}
default boolean supportsClassDefining() {
return false;
}
{code}
And throws an exception at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARIES-2050) Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
[
https://issues.apache.org/jira/browse/ARIES-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362858#comment-17362858
]
Grzegorz Grzybek commented on ARIES-2050:
-
[~cschneider], [~gnodet] and [~jbonofre], I'd like to ask you for opinion on
these PRs.
> Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
>
>
> Key: ARIES-2050
> URL: https://issues.apache.org/jira/browse/ARIES-2050
> Project: Aries
> Issue Type: Bug
>Affects Versions: jpa-2.7.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I have a scenario consisting of the following call graph:
> {noformat}
> testService.performTest() [ @Transactional(TxType.REQUIRED) ]
> +-- List cars = carDao.getAllCars()
> | +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> | (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
> |
> +-- carDao.createNew(car);
> | +-- em.persist(car);
> |
> +-- newTxTestService.testNewTransaction(transactionManager.getTransaction())
> [ @Transactional(TxType.REQUIRES_NEW) ]
> +-- List cars = carDao.getAllCars();
> +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> {noformat}
> The problem is that inside the method marked with
> {{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
> underlying {{em}} instance because of:
> {code:java}
> Coordination getTopCoordination() {
> Coordination coordination = coordinator.peek();
> while (coordination != null && coordination.getEnclosingCoordination() !=
> null) {
> coordination = coordination.getEnclosingCoordination();
> }
> return coordination;
> }
> {code}
> And even if the suspended transaction is not yet committed, the em returns
> the persisted (but not yet committed) cars.
> The coordination stack consists of (names of coordination objects):
> *
> txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
> *
> txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
> * jpa
> the top coordination contains {{em}} variable associated with suspended
> transaction.
> I'm working on a solution that properly assigns _current_ em respecting
> tx-demarcated coordinations.
> [~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
> solution, please share.
> For now I think both aries-jpa and aries-blueprint-transaction have to be
> fixed (the latter one should put some magical variable to the coordination
> objects pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARIES-2050) Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
[
https://issues.apache.org/jira/browse/ARIES-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362761#comment-17362761
]
Grzegorz Grzybek commented on ARIES-2050:
-
With my test, a scenario with REQUIRED → REQUIRES_NEW leads to this situation
inside EMSupplierImpl:
{noformat}
result = {java.util.ArrayList@17622} size = 3
0 = {org.apache.felix.coordinator.impl.CoordinationHolder@17459}
"org.apache.felix.coordinator.impl.CoordinationImpl@47"
coordination: org.apache.felix.coordinator.impl.CoordinationImpl =
{org.apache.felix.coordinator.impl.CoordinationImpl@17478}
name: java.lang.String =
"txInterceptor.fuse.jpa.jta.test.service.TestService.performTest"
variables: java.util.Map = {java.util.HashMap@17482} size = 2
{@4706} "interface javax.transaction.Transaction" -> "REQUIRED"
{@4435} "interface javax.persistence.EntityManager" ->
{java.util.HashMap@17489} size = 1
key: java.lang.Class = {@4435} "interface javax.persistence.EntityManager"
value: java.util.HashMap = {java.util.HashMap@17489} size = 1
"fuse.jpa.jta.test.JpaPersistenceUnit" ->
{org.hibernate.internal.SessionImpl@17649} "SessionImpl(2115685679)"
...
1 = {org.apache.felix.coordinator.impl.CoordinationHolder@17460}
"org.apache.felix.coordinator.impl.CoordinationImpl@4a"
coordination: org.apache.felix.coordinator.impl.CoordinationImpl =
{org.apache.felix.coordinator.impl.CoordinationImpl@17471}
name: java.lang.String =
"txInterceptor.fuse.jpa.jta.test.service.NewTxTestService.testNewTransaction"
variables: java.util.Map = {java.util.HashMap@17475} size = 2
{@4706} "interface javax.transaction.Transaction" -> "REQUIRES_NEW"
{@4435} "interface javax.persistence.EntityManager" ->
{java.util.HashMap@17634} size = 1
key: java.lang.Class = {@4435} "interface javax.persistence.EntityManager"
value: java.util.HashMap = {java.util.HashMap@17634} size = 1
"fuse.jpa.jta.test.JpaPersistenceUnit" ->
{org.hibernate.internal.SessionImpl@17611} "SessionImpl(1734890509)"
...
2 = {org.apache.felix.coordinator.impl.CoordinationHolder@17461}
"org.apache.felix.coordinator.impl.CoordinationImpl@4b"
coordination: org.apache.felix.coordinator.impl.CoordinationImpl =
{org.apache.felix.coordinator.impl.CoordinationImpl@17465}
name: java.lang.String = "jpa"
variables: java.util.Map = {java.util.HashMap@17468} size = 0
{noformat}
Note that two TX-related coordinations (pushed by TxInterceptor) have:
* an attribute under {{javax.transaction.Transaction.class}} key
* different value under {{javax.persistence.EntityManager.class}} key -
EMSupplierImpl doesn't always pick up the top-most coordination.
The quick summary of the change is:
* {{org.apache.aries.transaction.TxInterceptorImpl#preCall()}} doesn't
necessarily create new coordination. For example for REQUIRED, if there already
is a transaction, no new coordination is required. However if there's
REQUIRES_NEW after REQUIRED, a new coordination is always needed.
* Assuming the above,
{{org.apache.aries.jpa.support.impl.EMSupplierImpl#getTopCoordination()}}
selects first (starting from the bottom) coordination that has
{{javax.transaction.Transaction.class}} variable - this coordination will be
selected to store the EntityManager instance.
> Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
>
>
> Key: ARIES-2050
> URL: https://issues.apache.org/jira/browse/ARIES-2050
> Project: Aries
> Issue Type: Bug
>Affects Versions: jpa-2.7.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I have a scenario consisting of the following call graph:
> {noformat}
> testService.performTest() [ @Transactional(TxType.REQUIRED) ]
> +-- List cars = carDao.getAllCars()
> | +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> | (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
> |
> +-- carDao.createNew(car);
> | +-- em.persist(car);
> |
> +-- newTxTestService.testNewTransaction(transactionManager.getTransaction())
> [ @Transactional(TxType.REQUIRES_NEW) ]
> +-- List cars = carDao.getAllCars();
> +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> {noformat}
> The problem is that inside the method marked with
> {{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
> underlying {{em}} instance because of:
> {code:java}
> Coordination getTopCoordination() {
> Coordination coordination = coordinator.peek();
> while (coordination != null && coordination.getEnclosingCoordination() !=
> null) {
> coordination = coordination.getEnclosingCoordination();
> }
> return coordination;
> }
> {code}
[jira] [Updated] (ARIES-2050) Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
[
https://issues.apache.org/jira/browse/ARIES-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-2050:
Description:
I have a scenario consisting of the following call graph:
{noformat}
testService.performTest() [ @Transactional(TxType.REQUIRED) ]
+-- List cars = carDao.getAllCars()
| +-- return em.createQuery("select c from Car c", Car.class).getResultList()
| (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
|
+-- carDao.createNew(car);
| +-- em.persist(car);
|
+-- newTxTestService.testNewTransaction(transactionManager.getTransaction()) [
@Transactional(TxType.REQUIRES_NEW) ]
+-- List cars = carDao.getAllCars();
+-- return em.createQuery("select c from Car c",
Car.class).getResultList()
{noformat}
The problem is that inside the method marked with
{{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
underlying {{em}} instance because of:
{code:java}
Coordination getTopCoordination() {
Coordination coordination = coordinator.peek();
while (coordination != null && coordination.getEnclosingCoordination() !=
null) {
coordination = coordination.getEnclosingCoordination();
}
return coordination;
}
{code}
And even if the suspended transaction is not yet committed, the em returns the
persisted (but not yet committed) cars.
The coordination stack consists of (names of coordination objects):
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
* jpa
the top coordination contains {{em}} variable associated with suspended
transaction.
I'm working on a solution that properly assigns _current_ em respecting
tx-demarcated coordinations.
[~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
solution, please share.
For now I think both aries-jpa and aries-blueprint-transaction have to be fixed
(the latter one should put some magical variable to the coordination objects
pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
was:
I have a scenario consisting of the following call graph:
{noformat}
testService.performTest() [ @Transactional(TxType.REQUIRED) ]
+-- List cars = carDao.getAllCars()
| +-- return em.createQuery("select c from Car c", Car.class).getResultList()
| (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
|
+-- carDao.createNew(car);
| +-- em.persist(car);
|
+-- newTxTestService.testNewTransaction(transactionManager.getTransaction()) [
@Transactional(TxType.REQUIRES_NEW) ]
+-- List cars = carDao.getAllCars();
+-- return em.createQuery("select c from Car c",
Car.class).getResultList()
{noformat}
The problem is that inside the method marked with
{{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
underlying {{em}} instance because of:
{code:java}
Coordination getTopCoordination() {
Coordination coordination = coordinator.peek();
while (coordination != null && coordination.getEnclosingCoordination() !=
null) {
coordination = coordination.getEnclosingCoordination();
}
return coordination;
}
{code}
The coordination stack consists of (names of coordination objects):
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
* jpa
the top coordination contains {{em}} variable associated with suspended
transaction.
I'm working on a solution that properly assigns _current_ em respecting
tx-demarcated coordinations.
[~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
solution, please share.
For now I think both aries-jpa and aries-blueprint-transaction have to be fixed
(the latter one should put some magical variable to the coordination objects
pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
> Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
>
>
> Key: ARIES-2050
> URL: https://issues.apache.org/jira/browse/ARIES-2050
> Project: Aries
> Issue Type: Bug
>Affects Versions: jpa-2.7.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
> I have a scenario consisting of the following call graph:
> {noformat}
> testService.performTest() [ @Transactional(TxType.REQUIRED) ]
> +-- List cars = carDao.getAllCars()
> | +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> | (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
> |
> +-- carDao.createNew(car);
> |
[jira] [Created] (ARIES-2050) Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
Grzegorz Grzybek created ARIES-2050:
---
Summary: Aries JPA 2.7 shouldn't always reuse EM instance from
previous coordinations
Key: ARIES-2050
URL: https://issues.apache.org/jira/browse/ARIES-2050
Project: Aries
Issue Type: Bug
Affects Versions: jpa-2.7.2
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
I have a scenario consisting of the following call graph:
{noformat}
testService.performTest() [ @Transactional(TxType.REQUIRED) ]
+-- List cars = carDao.getAllCars()
| +-- return em.createQuery("select c from Car c", Car.class).getResultList()
| (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
|
+-- carDao.createNew(car);
| +-- em.persist(car);
|
+-- newTxTestService.testNewTransaction(transactionManager.getTransaction()) [
@Transactional(TxType.REQUIRES_NEW) ]
+-- List cars = carDao.getAllCars();
+-- return em.createQuery("select c from Car c",
Car.class).getResultList()
{noformat}
The problem is that inside the method marked with
{{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
underlying {{em}} instance because of:
{code:java}
Coordination getTopCoordination() {
Coordination coordination = coordinator.peek();
while (coordination != null && coordination.getEnclosingCoordination() !=
null) {
coordination = coordination.getEnclosingCoordination();
}
return coordination;
}
{code}
The coordination stack consists of (names of coordination objects):
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
* jpa
the top coordination contains {{em}} variable associated with suspended
transaction.
I'm working on a solution that properly assigns _current_ em respecting
tx-demarcated coordinations.
[~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
solution, please share.
For now I think both aries-jpa and aries-blueprint-transaction have to be fixed
(the latter one should put some magical variable to the coordination objects
pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARIES-1765) Aries JPA - Update to JPA 2.2
[ https://issues.apache.org/jira/browse/ARIES-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780433#comment-16780433 ] Grzegorz Grzybek commented on ARIES-1765: - I confirm that too. I use jpa feature from aries-jpa 2.7.2 and I override a javax.persistence 2.1 API with 2.2 - without issues when using Hibernate 5.3.x. > Aries JPA - Update to JPA 2.2 > - > > Key: ARIES-1765 > URL: https://issues.apache.org/jira/browse/ARIES-1765 > Project: Aries > Issue Type: Bug > Components: JPA >Affects Versions: jpa-2.6.0 >Reporter: Giuseppe Gerla >Priority: Minor > > Because eclipselink delivered 2.7.0 version that is based on JPA 2.2, could > be useful to verify and eventually introduce compliance with this new version > of API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1765) Aries JPA - Update to JPA 2.2
[
https://issues.apache.org/jira/browse/ARIES-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780206#comment-16780206
]
Grzegorz Grzybek edited comment on ARIES-1765 at 2/28/19 7:43 AM:
--
[~cschneider], IMO, there are no major API changes between 2.1 and 2.2 - there
are some new interfaces methods, but marked as {{default}}. Did you try adding
{{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
was (Author: gzres):
[~cschnei...@bixolabs.com], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try adding {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
> Aries JPA - Update to JPA 2.2
> -
>
> Key: ARIES-1765
> URL: https://issues.apache.org/jira/browse/ARIES-1765
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.6.0
>Reporter: Giuseppe Gerla
>Priority: Minor
>
> Because eclipselink delivered 2.7.0 version that is based on JPA 2.2, could
> be useful to verify and eventually introduce compliance with this new version
> of API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1765) Aries JPA - Update to JPA 2.2
[
https://issues.apache.org/jira/browse/ARIES-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780206#comment-16780206
]
Grzegorz Grzybek edited comment on ARIES-1765 at 2/28/19 7:43 AM:
--
[~ch...@die-schneider.net], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try adding {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
was (Author: gzres):
[~cschneider], IMO, there are no major API changes between 2.1 and 2.2 - there
are some new interfaces methods, but marked as {{default}}. Did you try adding
{{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
> Aries JPA - Update to JPA 2.2
> -
>
> Key: ARIES-1765
> URL: https://issues.apache.org/jira/browse/ARIES-1765
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.6.0
>Reporter: Giuseppe Gerla
>Priority: Minor
>
> Because eclipselink delivered 2.7.0 version that is based on JPA 2.2, could
> be useful to verify and eventually introduce compliance with this new version
> of API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1765) Aries JPA - Update to JPA 2.2
[
https://issues.apache.org/jira/browse/ARIES-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780206#comment-16780206
]
Grzegorz Grzybek commented on ARIES-1765:
-
[~ch...@die-schneider.de], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
> Aries JPA - Update to JPA 2.2
> -
>
> Key: ARIES-1765
> URL: https://issues.apache.org/jira/browse/ARIES-1765
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.6.0
>Reporter: Giuseppe Gerla
>Priority: Minor
>
> Because eclipselink delivered 2.7.0 version that is based on JPA 2.2, could
> be useful to verify and eventually introduce compliance with this new version
> of API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1765) Aries JPA - Update to JPA 2.2
[
https://issues.apache.org/jira/browse/ARIES-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780206#comment-16780206
]
Grzegorz Grzybek edited comment on ARIES-1765 at 2/28/19 7:42 AM:
--
[~ch...@die-schneider.de], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try adding {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
was (Author: gzres):
[~ch...@die-schneider.de], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
> Aries JPA - Update to JPA 2.2
> -
>
> Key: ARIES-1765
> URL: https://issues.apache.org/jira/browse/ARIES-1765
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.6.0
>Reporter: Giuseppe Gerla
>Priority: Minor
>
> Because eclipselink delivered 2.7.0 version that is based on JPA 2.2, could
> be useful to verify and eventually introduce compliance with this new version
> of API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1765) Aries JPA - Update to JPA 2.2
[
https://issues.apache.org/jira/browse/ARIES-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780206#comment-16780206
]
Grzegorz Grzybek edited comment on ARIES-1765 at 2/28/19 7:42 AM:
--
[~cschnei...@bixolabs.com], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try adding {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
was (Author: gzres):
[~ch...@die-schneider.de], IMO, there are no major API changes between 2.1 and
2.2 - there are some new interfaces methods, but marked as {{default}}. Did you
try adding {{2_2}} module to
{{org.apache.aries.jpa.javax.persistence:org.apache.aries.jpa.javax.persistence.parent}}?
> Aries JPA - Update to JPA 2.2
> -
>
> Key: ARIES-1765
> URL: https://issues.apache.org/jira/browse/ARIES-1765
> Project: Aries
> Issue Type: Bug
> Components: JPA
>Affects Versions: jpa-2.6.0
>Reporter: Giuseppe Gerla
>Priority: Minor
>
> Because eclipselink delivered 2.7.0 version that is based on JPA 2.2, could
> be useful to verify and eventually introduce compliance with this new version
> of API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-960) Support type inference and generics
[
https://issues.apache.org/jira/browse/ARIES-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755980#comment-16755980
]
Grzegorz Grzybek commented on ARIES-960:
https://stackoverflow.com/questions/54339093/how-to-pass-validation-query-for-sql-server-in-fuse-osgi-environment/54350230?noredirect=1#comment95604193_54350230
> Support type inference and generics
> ---
>
> Key: ARIES-960
> URL: https://issues.apache.org/jira/browse/ARIES-960
> Project: Aries
> Issue Type: New Feature
> Components: Blueprint
>Affects Versions: blueprint-core-1.0.1
> Environment: Karaf
> Karaf version 2.3.0
> Karaf home /home/ceefour/git/bippo-commerce5/karaf
> Karaf base /home/ceefour/git/bippo-commerce5/karaf
> OSGi Framework org.apache.felix.framework - 4.0.3
> JVM
> Java Virtual MachineOpenJDK 64-Bit Server VM version 23.2-b09
> Version 1.7.0_07
> Vendor Oracle Corporation
> Uptime 7 minutes
> Total compile time 33.261 seconds
> Threads
> Live threads101
> Daemon threads 86
> Peak135
> Total started 177
> Memory
> Current heap size 228,508 kbytes
> Maximum heap size 466,048 kbytes
> Committed heap size 256,000 kbytes
> Pending objects 0
> Garbage collector Name = 'PS Scavenge', Collections = 55, Time =
> 0.443 seconds
> Garbage collector Name = 'PS MarkSweep', Collections = 2, Time =
> 0.280 seconds
> Classes
> Current classes loaded 11,212
> Total classes loaded11,213
> Total classes unloaded 1
> Operating system
> NameLinux version 3.2.0-32-generic
> Architectureamd64
> Processors 8
>Reporter: Hendy Irawan
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: blueprint-core-1.9.0
>
>
> This is similar to #ARIES-834 and #ARIES-843, which was reported as fixed,
> but for some reason, it's not fixed in my case.
> {code}
> 2012-11-07 18:30:50,648 | ERROR | rint Extender: 3 | BlueprintContainerImpl
> | container.BlueprintContainerImpl 375 | 7 -
> org.apache.aries.blueprint.core - 1.0.1 | Unable to start blueprint container
> for bundle berbatik_security.xml
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> find a matching constructor on class org.soluvas.web.login.SoluvasRealm for
> arguments
> [org.apache.aries.blueprint.container.BeanRecipe$UnwrapperedBeanHolder@5c2a497b,
>
> org.apache.aries.blueprint.container.BeanRecipe$UnwrapperedBeanHolder@5c3e5982]
> when instanciating bean shiroRealm
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:336)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_07]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_07]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:933)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.0.1]
> at
>
[jira] [Commented] (ARIES-1872) Provide karaf features repository
[ https://issues.apache.org/jira/browse/ARIES-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710625#comment-16710625 ] Grzegorz Grzybek commented on ARIES-1872: - I may be related to https://ops4j1.jira.com/browse/PAXWEB-1116 > Provide karaf features repository > - > > Key: ARIES-1872 > URL: https://issues.apache.org/jira/browse/ARIES-1872 > Project: Aries > Issue Type: New Feature > Components: jax-rs-whiteboard >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1872) Provide karaf features repository
[ https://issues.apache.org/jira/browse/ARIES-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710625#comment-16710625 ] Grzegorz Grzybek edited comment on ARIES-1872 at 12/5/18 8:55 PM: -- It may be related to https://ops4j1.jira.com/browse/PAXWEB-1116 was (Author: gzres): I may be related to https://ops4j1.jira.com/browse/PAXWEB-1116 > Provide karaf features repository > - > > Key: ARIES-1872 > URL: https://issues.apache.org/jira/browse/ARIES-1872 > Project: Aries > Issue Type: New Feature > Components: jax-rs-whiteboard >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679420#comment-16679420
]
Grzegorz Grzybek commented on ARIES-1858:
-
Here's a list of special things that
{{org.apache.camel.blueprint.BlueprintPropertiesParser}} does:
* checking hierarchy:
{code:java}
Class clazz = ((ExtendedBeanMetadata) meta).getRuntimeClass();
if (clazz != null && AbstractPropertyPlaceholder.class.isAssignableFrom(clazz))
{
ids.add(id);
}
{code}
* casting:
{code:java}
Object component = container.getComponentInstance(id);
if (component instanceof AbstractPropertyPlaceholder) {
AbstractPropertyPlaceholder placeholder = (AbstractPropertyPlaceholder)
component;
{code}
* reflectively getting a method reference:
{code:java}
method = AbstractPropertyPlaceholder.class.getDeclaredMethod("retrieveValue",
String.class);
method.setAccessible(true);
{code}
* non-reflectively calling {{getDefaultProperties()}} method:
{code:java}
if (placeholder instanceof PropertyPlaceholder) {
Map map = ((PropertyPlaceholder) placeholder).getDefaultProperties();
isDefault = map != null && map.containsKey(key);
}
{code}
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0property-placeholder}}
> and
> {{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0property-placeholder}}.
> This is definitely not catched by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1858:
Description:
ARIES-1298 changed the runtime class of bean registered from
{{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
and
{{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
This is definitely not caught by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
was:
ARIES-1298 changed the runtime class of bean registered from
{{{[http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0]}property-placeholder}}
and
{{{[http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0]}property-placeholder}}.
This is definitely not caught by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
> and
> {{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
> This is definitely not caught by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1858) Make type property placeholders compatible with older Camel versions
Grzegorz Grzybek created ARIES-1858:
---
Summary: Make type property placeholders compatible with older
Camel versions
Key: ARIES-1858
URL: https://issues.apache.org/jira/browse/ARIES-1858
Project: Aries
Issue Type: Improvement
Components: Blueprint
Affects Versions: blueprint-core-1.10.0
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
Fix For: blueprint-core-1.10.1
ARIES-1298 changed the runtime class of bean registered from
{{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0property-placeholder}}
and
{{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0property-placeholder}}.
This is definitely not catched by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1858:
Description:
ARIES-1298 changed the runtime class of bean registered from
{{{[http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0]}property-placeholder}}
and
{{{[http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0]}property-placeholder}}.
This is definitely not caught by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
was:
ARIES-1298 changed the runtime class of bean registered from
{{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
and
{{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
This is definitely not catched by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{{[http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0]}property-placeholder}}
> and
> {{{[http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0]}property-placeholder}}.
> This is definitely not caught by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved ARIES-1858.
-
Resolution: Fixed
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
> and
> {{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
> This is definitely not caught by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1858:
Description:
ARIES-1298 changed the runtime class of bean registered from
{{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
and
{{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
This is definitely not catched by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
was:
ARIES-1298 changed the runtime class of bean registered from
{{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0property-placeholder}}
and
{{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0property-placeholder}}.
This is definitely not catched by semver plugin.
{{camel-blueprint}} (see CAMEL-12570) added support for this new runtime class
- it was needed because Camel explicitly casts and uses reflection on old
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class, while
blueprint-core 1.10.0 registers placeholder class that extends
{{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
two are not related.
The problem is that when user will try to upgrade to e.g., Karaf with
blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
detecting blueprint property resolvers.
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
> and
> {{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
> This is definitely not catched by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1858:
Summary: Make typed property placeholders compatible with older Camel
versions (was: Make type property placeholders compatible with older Camel
versions)
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0property-placeholder}}
> and
> {{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0property-placeholder}}.
> This is definitely not catched by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1858) Make typed property placeholders compatible with older Camel versions
[
https://issues.apache.org/jira/browse/ARIES-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1858:
Fix Version/s: blueprint-cm-1.3.1
> Make typed property placeholders compatible with older Camel versions
> -
>
> Key: ARIES-1858
> URL: https://issues.apache.org/jira/browse/ARIES-1858
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.10.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: blueprint-core-1.10.1, blueprint-cm-1.3.1
>
>
> ARIES-1298 changed the runtime class of bean registered from
> {{http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.x.0}property-placeholder}}
> and
> {{http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.x.0}property-placeholder}}.
> This is definitely not caught by semver plugin.
> {{camel-blueprint}} (see CAMEL-12570) added support for this new runtime
> class - it was needed because Camel explicitly casts and uses reflection on
> old {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholder}} class,
> while blueprint-core 1.10.0 registers placeholder class that extends
> {{org.apache.aries.blueprint.ext.AbstractPropertyPlaceholderExt}} - and these
> two are not related.
> The problem is that when user will try to upgrade to e.g., Karaf with
> blueprint-core 1.10.0 *without upgrading Camel*, Camel blueprint will stop
> detecting blueprint property resolvers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1853) SAXParseException in transaction.xml because of uneven number of schemaLocation URI
[ https://issues.apache.org/jira/browse/ARIES-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved ARIES-1853. - Resolution: Fixed > SAXParseException in transaction.xml because of uneven number of > schemaLocation URI > --- > > Key: ARIES-1853 > URL: https://issues.apache.org/jira/browse/ARIES-1853 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: transaction-blueprint-2.2.0 >Reporter: Volker Althaus >Assignee: Grzegorz Grzybek >Priority: Trivial > Fix For: transaction-blueprint-2.3.0 > > > I am using the bundle org.apache.aries.transaction.blueprint-2.2.0.jar in a > Karaf 4.2.1 environment. I get several warnings in the log file because the > schemaLocation value of OSGI-INF/transaction.xml has an uneven number. Does > not affect the bundle start, but these warnings should be avoided. > org.xml.sax.SAXParseException: SchemaLocation: schemaLocation-Wert = > 'http://www.osgi.org/xmlns/blueprint/v1.0.0' muss eine gerade Anzahl an URIs > haben. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) > ~[?:?] > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:99) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:392) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.storeLocations(XMLSchemaValidator.java:2347) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1754) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:740) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374) > [?:?] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARIES-1853) SAXParseException in transaction.xml because of uneven number of schemaLocation URI
[ https://issues.apache.org/jira/browse/ARIES-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek updated ARIES-1853: Fix Version/s: transaction-blueprint-2.3.0 > SAXParseException in transaction.xml because of uneven number of > schemaLocation URI > --- > > Key: ARIES-1853 > URL: https://issues.apache.org/jira/browse/ARIES-1853 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: transaction-blueprint-2.2.0 >Reporter: Volker Althaus >Priority: Trivial > Fix For: transaction-blueprint-2.3.0 > > > I am using the bundle org.apache.aries.transaction.blueprint-2.2.0.jar in a > Karaf 4.2.1 environment. I get several warnings in the log file because the > schemaLocation value of OSGI-INF/transaction.xml has an uneven number. Does > not affect the bundle start, but these warnings should be avoided. > org.xml.sax.SAXParseException: SchemaLocation: schemaLocation-Wert = > 'http://www.osgi.org/xmlns/blueprint/v1.0.0' muss eine gerade Anzahl an URIs > haben. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) > ~[?:?] > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:99) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:392) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.storeLocations(XMLSchemaValidator.java:2347) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1754) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:740) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374) > [?:?] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1853) SAXParseException in transaction.xml because of uneven number of schemaLocation URI
[ https://issues.apache.org/jira/browse/ARIES-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned ARIES-1853: --- Assignee: Grzegorz Grzybek > SAXParseException in transaction.xml because of uneven number of > schemaLocation URI > --- > > Key: ARIES-1853 > URL: https://issues.apache.org/jira/browse/ARIES-1853 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: transaction-blueprint-2.2.0 >Reporter: Volker Althaus >Assignee: Grzegorz Grzybek >Priority: Trivial > Fix For: transaction-blueprint-2.3.0 > > > I am using the bundle org.apache.aries.transaction.blueprint-2.2.0.jar in a > Karaf 4.2.1 environment. I get several warnings in the log file because the > schemaLocation value of OSGI-INF/transaction.xml has an uneven number. Does > not affect the bundle start, but these warnings should be avoided. > org.xml.sax.SAXParseException: SchemaLocation: schemaLocation-Wert = > 'http://www.osgi.org/xmlns/blueprint/v1.0.0' muss eine gerade Anzahl an URIs > haben. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) > ~[?:?] > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:99) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:392) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.storeLocations(XMLSchemaValidator.java:2347) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1754) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:740) > [?:?] > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374) > [?:?] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARIES-1808) ComponentDefinitionException message should contain actual class (interface) name instead of "ReferenceRecipe$ServiceProxyWrapper"
[
https://issues.apache.org/jira/browse/ARIES-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1808:
Component/s: Blueprint
> ComponentDefinitionException message should contain actual class (interface)
> name instead of "ReferenceRecipe$ServiceProxyWrapper"
> --
>
> Key: ARIES-1808
> URL: https://issues.apache.org/jira/browse/ARIES-1808
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Michael Vorburger
>Priority: Major
>
> I made some mistake in looking up a via an interface and then
> passing that id as an to a which expected a concrete class
> implementing that interface, and thought that kind error message could be a
> lot more helpful if it contained the contain actual class (interface) names
> it was about instead of (literally) "ReferenceRecipe$ServiceProxyWrapper" :
> {noformat}
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> find a matching constructor on class
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataBrokerAdapter
> for arguments
> [org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@3be77953
> (class
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper),
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@333e9ff0
> (class
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper)]
> when instanciating bean tracingBindingDataBroker
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
> find a matching constructor on class
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataBrokerAdapter
> for arguments
> [org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@3be77953
> (class
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper),
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@333e9ff0
> (class
> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper)]
> when instanciating bean tracingBindingDataBroker
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:704)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:410)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:275)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48){noformat}
>
> https://git.opendaylight.org/gerrit/#/c/72530/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1762) No namespace handler for http://www.springframework.org/schema/beans
[
https://issues.apache.org/jira/browse/ARIES-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678236#comment-16678236
]
Grzegorz Grzybek commented on ARIES-1762:
-
It should work with aries-blueprint-spring.
> No namespace handler for http://www.springframework.org/schema/beans
>
>
> Key: ARIES-1762
> URL: https://issues.apache.org/jira/browse/ARIES-1762
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Oscar Rodriguez
>Priority: Major
>
> Hi guys,
> I was trying to bundle an Spring Integration app under an OSGI container
> using blueprints but so far I haven't been able to do so.
> My bet was to use Apache Aries with the Spring module so after searching for
> this topic on the web I tried something similar to what it's found in
> http://svn.apache.org/viewvc/aries/trunk/blueprint/itests/blueprint-testbundles/
> as a proof on concept.
> My setup is simple, all I'm trying to do is to define a bean within spring,
> and exporting it as a OSGI service. No springt integration yet. So my
> blueprint.xml looks like:
> {code:xml}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xmlns:bp="http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:bean="http://www.springframework.org/schema/beans;
>xmlns:util="http://www.springframework.org/schema/util;
>xmlns:context="http://www.springframework.org/schema/context;
>xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://www.springframework.org/schema/tx
> http://www.springframework.org/schema/tx/spring-tx-4.2.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd;>
> http://www.springframework.org/schema/tx"/>
>
> interface="com.demo.api.Sample"/>
>
> {code}
> Bundle is created with gradle with both spring-context and spring-tx
> dependencies: Same as on the "blueprint-testbundles" project. However for
> some reason service is not getting registered.
> This is what im getting after deploying the bundle:
> {code:java}
> 15:42:34,944 INFO
> [fileinstall-/bundles/osgi/modules][BundleStartStopLogger:35] STARTED
> sample-impl_1.0.0 [617]
> 15:42:34,944 INFO [Blueprint Extender: 1][BlueprintContainerImpl:324] Bundle
> sample-impl/1.0.0 is waiting for namespace handlers
> [http://www.springframework.org/schema/beans]
> {code}
> And this is what I get when I try to inspect services from apache gogo
> console:
> {code:java}
> inspect capability service 617
> sample-impl_1.0.0 [617] provides:
> ---
> service [EMPTY]
> {code}
> These are the versions on Apache Aries I'm using:
> {code:java}
> org.apache.aries.blueprint.annotation.api-1.0.1.jar
> org.apache.aries.blueprint.api-1.0.1.jar
> org.apache.aries.blueprint.cm-1.1.0.jar
> org.apache.aries.blueprint.core-1.8.3.jar
> org.apache.aries.blueprint.spring-0.5.0.jar
> org.apache.aries.proxy-1.0.1.jar
> org.apache.aries.util-1.1.3.jar
> {code}
> All of them are shown as active on the OSGI container. Shouldn't the
> apache.aries.blueprint.spring be registered
> http://www.springframework.org/schema/beans as namespace handler?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1762) No namespace handler for http://www.springframework.org/schema/beans
[
https://issues.apache.org/jira/browse/ARIES-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1762:
Component/s: Blueprint
> No namespace handler for http://www.springframework.org/schema/beans
>
>
> Key: ARIES-1762
> URL: https://issues.apache.org/jira/browse/ARIES-1762
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Oscar Rodriguez
>Priority: Major
>
> Hi guys,
> I was trying to bundle an Spring Integration app under an OSGI container
> using blueprints but so far I haven't been able to do so.
> My bet was to use Apache Aries with the Spring module so after searching for
> this topic on the web I tried something similar to what it's found in
> http://svn.apache.org/viewvc/aries/trunk/blueprint/itests/blueprint-testbundles/
> as a proof on concept.
> My setup is simple, all I'm trying to do is to define a bean within spring,
> and exporting it as a OSGI service. No springt integration yet. So my
> blueprint.xml looks like:
> {code:xml}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xmlns:bp="http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:bean="http://www.springframework.org/schema/beans;
>xmlns:util="http://www.springframework.org/schema/util;
>xmlns:context="http://www.springframework.org/schema/context;
>xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util-4.2.xsd
> http://www.springframework.org/schema/context
> http://www.springframework.org/schema/context/spring-context-4.2.xsd
> http://www.springframework.org/schema/tx
> http://www.springframework.org/schema/tx/spring-tx-4.2.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-4.2.xsd;>
> http://www.springframework.org/schema/tx"/>
>
> interface="com.demo.api.Sample"/>
>
> {code}
> Bundle is created with gradle with both spring-context and spring-tx
> dependencies: Same as on the "blueprint-testbundles" project. However for
> some reason service is not getting registered.
> This is what im getting after deploying the bundle:
> {code:java}
> 15:42:34,944 INFO
> [fileinstall-/bundles/osgi/modules][BundleStartStopLogger:35] STARTED
> sample-impl_1.0.0 [617]
> 15:42:34,944 INFO [Blueprint Extender: 1][BlueprintContainerImpl:324] Bundle
> sample-impl/1.0.0 is waiting for namespace handlers
> [http://www.springframework.org/schema/beans]
> {code}
> And this is what I get when I try to inspect services from apache gogo
> console:
> {code:java}
> inspect capability service 617
> sample-impl_1.0.0 [617] provides:
> ---
> service [EMPTY]
> {code}
> These are the versions on Apache Aries I'm using:
> {code:java}
> org.apache.aries.blueprint.annotation.api-1.0.1.jar
> org.apache.aries.blueprint.api-1.0.1.jar
> org.apache.aries.blueprint.cm-1.1.0.jar
> org.apache.aries.blueprint.core-1.8.3.jar
> org.apache.aries.blueprint.spring-0.5.0.jar
> org.apache.aries.proxy-1.0.1.jar
> org.apache.aries.util-1.1.3.jar
> {code}
> All of them are shown as active on the OSGI container. Shouldn't the
> apache.aries.blueprint.spring be registered
> http://www.springframework.org/schema/beans as namespace handler?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1483) NullPointerException in Blueprint with karaf 4.0.3 and Hibernate
[
https://issues.apache.org/jira/browse/ARIES-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1483:
Fix Version/s: blueprint-core-1.5.0
> NullPointerException in Blueprint with karaf 4.0.3 and Hibernate
>
>
> Key: ARIES-1483
> URL: https://issues.apache.org/jira/browse/ARIES-1483
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Christian Niehues
>Priority: Minor
> Fix For: blueprint-core-1.5.0
>
>
> I get a NullPointerException just right after the restart of my karaf 4.0.3
> after installing hibernate with jpa and some relatated features:
> {quote}karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13]
> EventDispatcher: Error during dispatch. (java.lang.NullPointerException)
> java.lang.NullPointerException
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745){quote}
> Here is how to reproduce it. I am really new to karaf and aries so these are
> some commands I collected from examples/tutorials for JPA with karaf:
> - start a clean initial karaf 4.0.3
> - feature:repo-add pax-jdbc 0.7.0
> - feature:install hibernate jpa
> - feature:install jdbc pax-jdbc-config pax-jdbc-pool-dbcp2 transaction
> - restart karaf
> The exception doesn't appear everytime, so maybe some more restarts are
> needed. I hope you can reproduce it with that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1483) NullPointerException in Blueprint with karaf 4.0.3 and Hibernate
[
https://issues.apache.org/jira/browse/ARIES-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved ARIES-1483.
-
Resolution: Fixed
> NullPointerException in Blueprint with karaf 4.0.3 and Hibernate
>
>
> Key: ARIES-1483
> URL: https://issues.apache.org/jira/browse/ARIES-1483
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Christian Niehues
>Priority: Minor
> Fix For: blueprint-core-1.5.0
>
>
> I get a NullPointerException just right after the restart of my karaf 4.0.3
> after installing hibernate with jpa and some relatated features:
> {quote}karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13]
> EventDispatcher: Error during dispatch. (java.lang.NullPointerException)
> java.lang.NullPointerException
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745){quote}
> Here is how to reproduce it. I am really new to karaf and aries so these are
> some commands I collected from examples/tutorials for JPA with karaf:
> - start a clean initial karaf 4.0.3
> - feature:repo-add pax-jdbc 0.7.0
> - feature:install hibernate jpa
> - feature:install jdbc pax-jdbc-config pax-jdbc-pool-dbcp2 transaction
> - restart karaf
> The exception doesn't appear everytime, so maybe some more restarts are
> needed. I hope you can reproduce it with that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1483) NullPointerException in Blueprint with karaf 4.0.3 and Hibernate
[
https://issues.apache.org/jira/browse/ARIES-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1483:
Component/s: Blueprint
> NullPointerException in Blueprint with karaf 4.0.3 and Hibernate
>
>
> Key: ARIES-1483
> URL: https://issues.apache.org/jira/browse/ARIES-1483
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Christian Niehues
>Priority: Minor
>
> I get a NullPointerException just right after the restart of my karaf 4.0.3
> after installing hibernate with jpa and some relatated features:
> {quote}karaf@root()> ERROR: Bundle org.apache.aries.blueprint.core [13]
> EventDispatcher: Error during dispatch. (java.lang.NullPointerException)
> java.lang.NullPointerException
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:126)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:991)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:839)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:546)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4557)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3549)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:459)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:710)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:385)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:270)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745){quote}
> Here is how to reproduce it. I am really new to karaf and aries so these are
> some commands I collected from examples/tutorials for JPA with karaf:
> - start a clean initial karaf 4.0.3
> - feature:repo-add pax-jdbc 0.7.0
> - feature:install hibernate jpa
> - feature:install jdbc pax-jdbc-config pax-jdbc-pool-dbcp2 transaction
> - restart karaf
> The exception doesn't appear everytime, so maybe some more restarts are
> needed. I hope you can reproduce it with that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1093) Aries proxy doesn't work properly on uninstall/reinstall
[ https://issues.apache.org/jira/browse/ARIES-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek updated ARIES-1093: Component/s: Proxy > Aries proxy doesn't work properly on uninstall/reinstall > > > Key: ARIES-1093 > URL: https://issues.apache.org/jira/browse/ARIES-1093 > Project: Aries > Issue Type: Bug > Components: Proxy >Reporter: Timothy Ward >Priority: Critical > > There are a couple of problems with the Aries Proxy code if you do > install/uninstall cycles: > Firstly the Aries subclass generator uses Class.forName(String) in the static > initializers of the classes that it generates. This works, but we need to > pass the correct ClassLoader to avoid odd caching bugs (See > http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html) > Secondly, if the API is installed separately, then reinstalling the Proxy > Impl breaks proxying. The existing woven classes stay woven but new woven > subclasses use a different unique name for the WovenProxy fields. This causes > NoSuchFieldError to be thrown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1254) ManifestHeaderProcessor.parseFilter throws IllegalArgumentException on legal filter containing '='
[
https://issues.apache.org/jira/browse/ARIES-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678216#comment-16678216
]
Grzegorz Grzybek commented on ARIES-1254:
-
I wasn't able to track it - the parser never supported {{version=xxx}}.
> ManifestHeaderProcessor.parseFilter throws IllegalArgumentException on legal
> filter containing '='
> --
>
> Key: ARIES-1254
> URL: https://issues.apache.org/jira/browse/ARIES-1254
> Project: Aries
> Issue Type: Bug
> Components: Util
> Environment: All envs
>Reporter: Iain Lewis
>Priority: Major
>
> I have an OSGI bundle where the manifest contains a capability requirement of:
> Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.6))"
> Trying to parse this with the parseFilter() method throws an
> IlegalArgumentException. The code snippet below is sufficient to reproduce
> the problem.
> {noformat}
> String attribute =
> "osgi.ee;filter:=\"(&(osgi.ee=JavaSE)(version=1.6))\"";
> List requirementMetadata =
> ManifestHeaderProcessor.parseRequirementString(attribute);
> for (GenericMetadata metaData : requirementMetadata) {
> if (metaData.getNamespace().equals("osgi.ee")) {
> Map dirs =
> metaData.getDirectives();
> for (String key : dirs.keySet()) {
> if (key.equals("filter")) {
> Map filter =
> ManifestHeaderProcessor.parseFilter(dirs.get(key)); // Throws
> IllegalArgumentException
> }
> }
> }
> }
> {noformat}
> There is a fairly trivial fix for this. Looking at the version of the source
> from here:
> https://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/manifest/ManifestHeaderProcessor.java
> On line 713:
> {noformat}
> else if (LESS_EQ_OP.equals(op))
> upperVersion = value;
> else
> throw new IllegalArgumentException();
> }
> {noformat}
> Should become this:
> {noformat}
> } else if (LESS_EQ_OP.equals(op)) {
> upperVersion = value;
> } else if (EQ_OP.equals(op)) {
>lowerVersion = value;
>upperVersion = value;
> } else {
> throw new IllegalArgumentException();
> }
> {noformat}
> And a new constant of EQ_OP needs to be added
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1254) ManifestHeaderProcessor.parseFilter throws IllegalArgumentException on legal filter containing '='
[
https://issues.apache.org/jira/browse/ARIES-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678126#comment-16678126
]
Grzegorz Grzybek edited comment on ARIES-1254 at 11/7/18 12:47 PM:
---
Indeed. I checked felix utils and felix framework and I don't see felix having
problems with {{=}} with version attribute.
The specification itself contains such examples:
{quote}
h4. 8.2 osgi.ee Namespace
\[…]
{noformat}
Require-Capability: «
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"
{noformat}
{quote}
was (Author: gzres):
Indeed. I checked felix utils and felix framework and I don't see it felix
having problems with {{=}} with version attribute.
The specification itself contains such examples:
{quote}
h4. 8.2 osgi.ee Namespace
\[…]
{noformat}
Require-Capability: «
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"
{noformat}
{quote}
> ManifestHeaderProcessor.parseFilter throws IllegalArgumentException on legal
> filter containing '='
> --
>
> Key: ARIES-1254
> URL: https://issues.apache.org/jira/browse/ARIES-1254
> Project: Aries
> Issue Type: Bug
> Components: Util
> Environment: All envs
>Reporter: Iain Lewis
>Priority: Major
>
> I have an OSGI bundle where the manifest contains a capability requirement of:
> Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.6))"
> Trying to parse this with the parseFilter() method throws an
> IlegalArgumentException. The code snippet below is sufficient to reproduce
> the problem.
> {noformat}
> String attribute =
> "osgi.ee;filter:=\"(&(osgi.ee=JavaSE)(version=1.6))\"";
> List requirementMetadata =
> ManifestHeaderProcessor.parseRequirementString(attribute);
> for (GenericMetadata metaData : requirementMetadata) {
> if (metaData.getNamespace().equals("osgi.ee")) {
> Map dirs =
> metaData.getDirectives();
> for (String key : dirs.keySet()) {
> if (key.equals("filter")) {
> Map filter =
> ManifestHeaderProcessor.parseFilter(dirs.get(key)); // Throws
> IllegalArgumentException
> }
> }
> }
> }
> {noformat}
> There is a fairly trivial fix for this. Looking at the version of the source
> from here:
> https://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/manifest/ManifestHeaderProcessor.java
> On line 713:
> {noformat}
> else if (LESS_EQ_OP.equals(op))
> upperVersion = value;
> else
> throw new IllegalArgumentException();
> }
> {noformat}
> Should become this:
> {noformat}
> } else if (LESS_EQ_OP.equals(op)) {
> upperVersion = value;
> } else if (EQ_OP.equals(op)) {
>lowerVersion = value;
>upperVersion = value;
> } else {
> throw new IllegalArgumentException();
> }
> {noformat}
> And a new constant of EQ_OP needs to be added
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1254) ManifestHeaderProcessor.parseFilter throws IllegalArgumentException on legal filter containing '='
[
https://issues.apache.org/jira/browse/ARIES-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678126#comment-16678126
]
Grzegorz Grzybek commented on ARIES-1254:
-
Indeed. I checked felix utils and felix framework and I don't see it felix
having problems with {{=}} with version attribute.
The specification itself contains such examples:
{quote}
h4. 8.2 osgi.ee Namespace
\[…]
{noformat}
Require-Capability: «
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"
{noformat}
{quote}
> ManifestHeaderProcessor.parseFilter throws IllegalArgumentException on legal
> filter containing '='
> --
>
> Key: ARIES-1254
> URL: https://issues.apache.org/jira/browse/ARIES-1254
> Project: Aries
> Issue Type: Bug
> Components: Util
> Environment: All envs
>Reporter: Iain Lewis
>Priority: Major
>
> I have an OSGI bundle where the manifest contains a capability requirement of:
> Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.6))"
> Trying to parse this with the parseFilter() method throws an
> IlegalArgumentException. The code snippet below is sufficient to reproduce
> the problem.
> {noformat}
> String attribute =
> "osgi.ee;filter:=\"(&(osgi.ee=JavaSE)(version=1.6))\"";
> List requirementMetadata =
> ManifestHeaderProcessor.parseRequirementString(attribute);
> for (GenericMetadata metaData : requirementMetadata) {
> if (metaData.getNamespace().equals("osgi.ee")) {
> Map dirs =
> metaData.getDirectives();
> for (String key : dirs.keySet()) {
> if (key.equals("filter")) {
> Map filter =
> ManifestHeaderProcessor.parseFilter(dirs.get(key)); // Throws
> IllegalArgumentException
> }
> }
> }
> }
> {noformat}
> There is a fairly trivial fix for this. Looking at the version of the source
> from here:
> https://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/manifest/ManifestHeaderProcessor.java
> On line 713:
> {noformat}
> else if (LESS_EQ_OP.equals(op))
> upperVersion = value;
> else
> throw new IllegalArgumentException();
> }
> {noformat}
> Should become this:
> {noformat}
> } else if (LESS_EQ_OP.equals(op)) {
> upperVersion = value;
> } else if (EQ_OP.equals(op)) {
>lowerVersion = value;
>upperVersion = value;
> } else {
> throw new IllegalArgumentException();
> }
> {noformat}
> And a new constant of EQ_OP needs to be added
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1841) Race condition on blueprint-cm with ConfigAdmin
[
https://issues.apache.org/jira/browse/ARIES-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1841:
Description:
If a blueprint bundle use CM like:
{code}
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.2.0"/>
{code}
if the configuration is created by another bundle (directly using
{{ConfigurationAdmin}}) like:
{code}
Configuration configuration =
configurationAdmin.getConfiguration(CONFIG_PID, null);
Dictionary dictionary =
Optional.ofNullable(configuration.getProperties()).orElse(new Hashtable());
for (Map.Entry entry : properties.entrySet()) {
dictionary.put(entry.getKey().toString(), entry.getValue());
}
configuration.update(dictionary);
{code}
then, it's possible to have a race condition where the blueprint container
thread starts whereas the config update is not complete (two different threads).
Blueprint CM should have an option to wait an updated config. For instance, it
could check {{\_felix\_.cm.newConfiguration}} property.
was:
If a blueprint bundle use CM like:
{code}
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.2.0"/>
{code}
if the configuration is created by another bundle (directly using
{{ConfigurationAdmin}}) like:
{code}
Configuration configuration =
configurationAdmin.getConfiguration(CONFIG_PID, null);
Dictionary dictionary =
Optional.ofNullable(configuration.getProperties()).orElse(new Hashtable());
for (Map.Entry entry : properties.entrySet()) {
dictionary.put(entry.getKey().toString(), entry.getValue());
}
configuration.update(dictionary);
{code}
then, it's possible to have a race condition where the blueprint container
thread starts whereas the config update is not complete (two different threads).
Blueprint CM should have an option to wait an updated config. For instance, it
could check {{_felix_.cm.newConfiguration}} property.
> Race condition on blueprint-cm with ConfigAdmin
> ---
>
> Key: ARIES-1841
> URL: https://issues.apache.org/jira/browse/ARIES-1841
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.9.0, blueprint-core-1.8.3
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: blueprint-core-1.8.4, blueprint-core-1.9.1
>
>
> If a blueprint bundle use CM like:
> {code}
> xmlns="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.2.0"/>
> {code}
> if the configuration is created by another bundle (directly using
> {{ConfigurationAdmin}}) like:
> {code}
> Configuration configuration =
> configurationAdmin.getConfiguration(CONFIG_PID, null);
> Dictionary dictionary =
> Optional.ofNullable(configuration.getProperties()).orElse(new Hashtable());
> for (Map.Entry entry : properties.entrySet()) {
> dictionary.put(entry.getKey().toString(), entry.getValue());
> }
>configuration.update(dictionary);
> {code}
> then, it's possible to have a race condition where the blueprint container
> thread starts whereas the config update is not complete (two different
> threads).
> Blueprint CM should have an option to wait an updated config. For instance,
> it could check {{\_felix\_.cm.newConfiguration}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1816) Unable to use with generic arguments
[ https://issues.apache.org/jira/browse/ARIES-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16531846#comment-16531846 ] Grzegorz Grzybek commented on ARIES-1816: - Thanks! > Unable to use with generic arguments > --- > > Key: ARIES-1816 > URL: https://issues.apache.org/jira/browse/ARIES-1816 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.10.0 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: blueprint-core-1.10.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1174) Avoid service reference timeout when system bundle is stopping
[ https://issues.apache.org/jira/browse/ARIES-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524731#comment-16524731 ] Grzegorz Grzybek commented on ARIES-1174: - [~gnt] any ideas about this problem? I don't see nice and generic solution... > Avoid service reference timeout when system bundle is stopping > -- > > Key: ARIES-1174 > URL: https://issues.apache.org/jira/browse/ARIES-1174 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-core-1.1.0 >Reporter: Benno Geißelmann >Assignee: Guillaume Nodet >Priority: Major > > The default timeout of Blueprint to wait for a service to come is 5 minutes. > A problem which comes with the timeout behaviour is, that in some states you > don't want to wait for the service. For example if the system bundle is in > state "stopping" this timeout will cause that the stopping takes 5 minutes. > In my opinion this makes no sense as the container will shutdown so there > shouldn't be waited for a service to come. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1790) ValidatingDelegatingManagedConnectionFactory is not used with aries.xa.validateOnMatch
[
https://issues.apache.org/jira/browse/ARIES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404700#comment-16404700
]
Grzegorz Grzybek commented on ARIES-1790:
-
[~gnt], same for
{{org.apache.aries.transaction.jdbc.internal.ManagedDataSourceFactory#register}}...
> ValidatingDelegatingManagedConnectionFactory is not used with
> aries.xa.validateOnMatch
> --
>
> Key: ARIES-1790
> URL: https://issues.apache.org/jira/browse/ARIES-1790
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1790) ValidatingDelegatingManagedConnectionFactory is not used with aries.xa.validateOnMatch
Grzegorz Grzybek created ARIES-1790: --- Summary: ValidatingDelegatingManagedConnectionFactory is not used with aries.xa.validateOnMatch Key: ARIES-1790 URL: https://issues.apache.org/jira/browse/ARIES-1790 Project: Aries Issue Type: Bug Components: Transaction Reporter: Grzegorz Grzybek Assignee: Grzegorz Grzybek -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1174) Avoid service reference timeout when system bundle is stopping
[
https://issues.apache.org/jira/browse/ARIES-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180731#comment-16180731
]
Grzegorz Grzybek commented on ARIES-1174:
-
I see this problem in yet another scenario. I have two bundles:
* a blueprint bundle declaring and for
{{org.apache.camel.spi.IdempotentRepository}} implementation
* a blueprint bundle with Camel context using file endpoint with
{{idempotentRepository=#messageIdRepository}} reference.
When I first stop Camel context bundle and then one with
{{IdempotentRepository}} service, everything's fine, but changing the order
leads to unnecessary wait. Camel wants to stop and it waits for the repository.
It's not that trivial as it seems at first glance - there may be cases where
target OSGi service *is needed* during shutdown of blueprint bundle using
, it could be ignored, but it (IMO) has to be explicit decision.
> Avoid service reference timeout when system bundle is stopping
> --
>
> Key: ARIES-1174
> URL: https://issues.apache.org/jira/browse/ARIES-1174
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
>Affects Versions: blueprint-core-1.1.0
>Reporter: Benno Geißelmann
>Assignee: Grzegorz Grzybek
>
> The default timeout of Blueprint to wait for a service to come is 5 minutes.
> A problem which comes with the timeout behaviour is, that in some states you
> don't want to wait for the service. For example if the system bundle is in
> state "stopping" this timeout will cause that the stopping takes 5 minutes.
> In my opinion this makes no sense as the container will shutdown so there
> shouldn't be waited for a service to come.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARIES-1635) BeanMetadata parsing issue when ext and cm are combined.
[
https://issues.apache.org/jira/browse/ARIES-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180498#comment-16180498
]
Grzegorz Grzybek commented on ARIES-1635:
-
[~chrisodom] are you sure you configured your blueprint.xml properly?
> BeanMetadata parsing issue when ext and cm are combined.
>
>
> Key: ARIES-1635
> URL: https://issues.apache.org/jira/browse/ARIES-1635
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.2, blueprint-cm-1.0.8
>Reporter: Chris Odom
>Assignee: Grzegorz Grzybek
>
> {noformat}
> org.osgi.service.blueprint.container.ComponentDefinitionException: Multiple
> placeholders with the same prefix and suffix are not allowed
> at
> org.apache.aries.blueprint.ext.PlaceholdersUtils.validatePlaceholder(PlaceholdersUtils.java:49)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parsePropertyPlaceholder(ExtNamespaceHandler.java:367)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parse(ExtNamespaceHandler.java:165)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1369)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:427)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.populate(Parser.java:331)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:349)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1179)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:731)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:486)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2172)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.7]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.7]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7]
> at
>
[jira] [Commented] (ARIES-1635) BeanMetadata parsing issue when ext and cm are combined.
[
https://issues.apache.org/jira/browse/ARIES-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180497#comment-16180497
]
Grzegorz Grzybek commented on ARIES-1635:
-
I checked the same with exactly bp.core 1.6.2 and bp.cm 1.0.8 and it still
works...
> BeanMetadata parsing issue when ext and cm are combined.
>
>
> Key: ARIES-1635
> URL: https://issues.apache.org/jira/browse/ARIES-1635
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.2, blueprint-cm-1.0.8
>Reporter: Chris Odom
>Assignee: Grzegorz Grzybek
>
> {noformat}
> org.osgi.service.blueprint.container.ComponentDefinitionException: Multiple
> placeholders with the same prefix and suffix are not allowed
> at
> org.apache.aries.blueprint.ext.PlaceholdersUtils.validatePlaceholder(PlaceholdersUtils.java:49)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parsePropertyPlaceholder(ExtNamespaceHandler.java:367)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parse(ExtNamespaceHandler.java:165)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1369)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:427)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.populate(Parser.java:331)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:349)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1179)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:731)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:486)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2172)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.7]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.7]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7]
> at
>
[jira] [Commented] (ARIES-1635) BeanMetadata parsing issue when ext and cm are combined.
[
https://issues.apache.org/jira/browse/ARIES-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180481#comment-16180481
]
Grzegorz Grzybek commented on ARIES-1635:
-
In my case:
{code:xml}
{code}
{noformat}
BeanMetadata[id='my2Props', initialization=0, dependsOn=null, className='null',
initMethodName='init', destroyMethodName='null', arguments=null, \
properties=[\
BeanProperty[name='placeholderPrefix', value=ValueMetadata[stringValue='${',
type='null']], \
BeanProperty[name='placeholderSuffix', value=ValueMetadata[stringValue='}',
type='null']], \
BeanProperty[name='systemProperties',
value=ValueMetadata[stringValue='override', type='null']]\
], factoryMethodName='null', factoryComponent=null, scope='singleton',
runtimeClass=class org.apache.aries.blueprint.ext.PropertyPlaceholder,
fieldInjection=false]
{noformat}
When:
{code:xml}
{code}
I have:
{noformat}
BeanMetadata[id='my2Props', initialization=0, dependsOn=null, className='null',
initMethodName='init', destroyMethodName='null', arguments=null, \
properties=[\
BeanProperty[name='placeholderPrefix', value=ValueMetadata[stringValue='$[',
type='null']], \
BeanProperty[name='placeholderSuffix', value=ValueMetadata[stringValue=']',
type='null']], \
BeanProperty[name='systemProperties',
value=ValueMetadata[stringValue='override', type='null']]\
], factoryMethodName='null', factoryComponent=null, scope='singleton',
runtimeClass=class org.apache.aries.blueprint.ext.PropertyPlaceholder,
fieldInjection=false]
{noformat}
> BeanMetadata parsing issue when ext and cm are combined.
>
>
> Key: ARIES-1635
> URL: https://issues.apache.org/jira/browse/ARIES-1635
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.2, blueprint-cm-1.0.8
>Reporter: Chris Odom
>Assignee: Grzegorz Grzybek
>
> {noformat}
> org.osgi.service.blueprint.container.ComponentDefinitionException: Multiple
> placeholders with the same prefix and suffix are not allowed
> at
> org.apache.aries.blueprint.ext.PlaceholdersUtils.validatePlaceholder(PlaceholdersUtils.java:49)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parsePropertyPlaceholder(ExtNamespaceHandler.java:367)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parse(ExtNamespaceHandler.java:165)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1369)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:427)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.parser.Parser.populate(Parser.java:331)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:349)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[21:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[30:org.apache.aries.util:1.1.1]
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1179)[org.apache.felix.framework-5.4.0.jar:]
>
[jira] [Updated] (ARIES-1635) BeanMetadata parsing issue when ext and cm are combined.
[
https://issues.apache.org/jira/browse/ARIES-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1635:
Description:
{noformat}
org.osgi.service.blueprint.container.ComponentDefinitionException: Multiple
placeholders with the same prefix and suffix are not allowed
at
org.apache.aries.blueprint.ext.PlaceholdersUtils.validatePlaceholder(PlaceholdersUtils.java:49)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parsePropertyPlaceholder(ExtNamespaceHandler.java:367)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parse(ExtNamespaceHandler.java:165)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1369)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:427)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.parser.Parser.populate(Parser.java:331)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:349)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[21:org.apache.aries.blueprint.core:1.6.2]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[30:org.apache.aries.util:1.1.1]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[30:org.apache.aries.util:1.1.1]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[30:org.apache.aries.util:1.1.1]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[30:org.apache.aries.util:1.1.1]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[30:org.apache.aries.util:1.1.1]
at
org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1179)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:731)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:486)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2172)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.7]
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.7]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.7]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_111]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_111]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_111]
{noformat}
Debug of BeanMetadata:
{noformat}
BeanMetadata[id='system-database-config', initialization=0, dependsOn=null,
className='null', initMethodName='init', destroyMethodName='null',
arguments=null,
[jira] [Assigned] (ARIES-1635) BeanMetadata parsing issue when ext and cm are combined.
[ https://issues.apache.org/jira/browse/ARIES-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned ARIES-1635: --- Assignee: Grzegorz Grzybek > BeanMetadata parsing issue when ext and cm are combined. > > > Key: ARIES-1635 > URL: https://issues.apache.org/jira/browse/ARIES-1635 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.6.2, blueprint-cm-1.0.8 >Reporter: Chris Odom >Assignee: Grzegorz Grzybek > > org.osgi.service.blueprint.container.ComponentDefinitionException: Multiple > placeholders with the same prefix and suffix are not allowed > at > org.apache.aries.blueprint.ext.PlaceholdersUtils.validatePlaceholder(PlaceholdersUtils.java:49)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parsePropertyPlaceholder(ExtNamespaceHandler.java:367)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.ext.impl.ExtNamespaceHandler.parse(ExtNamespaceHandler.java:165)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1369)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:427)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.parser.Parser.populate(Parser.java:331)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:349)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)[21:org.apache.aries.blueprint.core:1.6.2] > at > org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[30:org.apache.aries.util:1.1.1] > at > org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[30:org.apache.aries.util:1.1.1] > at > org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[30:org.apache.aries.util:1.1.1] > at > org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[30:org.apache.aries.util:1.1.1] > at > org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[30:org.apache.aries.util:1.1.1] > at > org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1179)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:731)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:486)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.felix.framework.Felix.startBundle(Felix.java:2172)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.7] > at
[jira] [Resolved] (ARIES-1256) Individual reference timeout is ignored
[
https://issues.apache.org/jira/browse/ARIES-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved ARIES-1256.
-
Resolution: Won't Fix
> Individual reference timeout is ignored
> ---
>
> Key: ARIES-1256
> URL: https://issues.apache.org/jira/browse/ARIES-1256
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.1.0
>Reporter: Irina Boldea
>
> Explicitly setting the timeout for an individual reference is ignored and the
> the default one of 5 minutes is taken.
> {code}
> timeout="12"/>
> {code}
> The TimeoutException is thrown only after 5 minutes instead of 2 minutes.
> {code}
> Unable to start blueprint container for bundle org.example.testbundle due to
> unresolved dependencies [(objectClass=org.example.ExampleRef)]
> java.util.concurrent.TimeoutException
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:375)
> {code}.
> Thank you.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ARIES-1256) Individual reference timeout is ignored
[
https://issues.apache.org/jira/browse/ARIES-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned ARIES-1256:
---
Assignee: Grzegorz Grzybek
> Individual reference timeout is ignored
> ---
>
> Key: ARIES-1256
> URL: https://issues.apache.org/jira/browse/ARIES-1256
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.1.0
>Reporter: Irina Boldea
>Assignee: Grzegorz Grzybek
>
> Explicitly setting the timeout for an individual reference is ignored and the
> the default one of 5 minutes is taken.
> {code}
> timeout="12"/>
> {code}
> The TimeoutException is thrown only after 5 minutes instead of 2 minutes.
> {code}
> Unable to start blueprint container for bundle org.example.testbundle due to
> unresolved dependencies [(objectClass=org.example.ExampleRef)]
> java.util.concurrent.TimeoutException
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:375)
> {code}.
> Thank you.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARIES-1256) Individual reference timeout is ignored
[
https://issues.apache.org/jira/browse/ARIES-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180460#comment-16180460
]
Grzegorz Grzybek commented on ARIES-1256:
-
You're mixing reference timeout (which works) with entire blueprint timeout.
When BlueprintContainer is run, it first sets default (entire) blueprint
timeout to 5 minutes, and then parses manifest entry for Bundle-SymbolicName.
If there's:
{noformat}
Bundle-SymbolicName: my.blueprint.bundle;blueprint.timeout=12
{noformat}
Then you'll get the expected behavior. At entire blueprint container level you
(aries) don't know which of the s will timeout. So when designing BP
application, please select blueprint.timeout as maximum of each of the
reference timeouts.
> Individual reference timeout is ignored
> ---
>
> Key: ARIES-1256
> URL: https://issues.apache.org/jira/browse/ARIES-1256
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.1.0
>Reporter: Irina Boldea
>
> Explicitly setting the timeout for an individual reference is ignored and the
> the default one of 5 minutes is taken.
> {code}
> timeout="12"/>
> {code}
> The TimeoutException is thrown only after 5 minutes instead of 2 minutes.
> {code}
> Unable to start blueprint container for bundle org.example.testbundle due to
> unresolved dependencies [(objectClass=org.example.ExampleRef)]
> java.util.concurrent.TimeoutException
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:375)
> {code}.
> Thank you.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ARIES-441) NullPointerException when cm:property-placeholder used with a non existant persistent id
[ https://issues.apache.org/jira/browse/ARIES-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved ARIES-441. Resolution: Won't Fix Assignee: Grzegorz Grzybek This is a problem with Equinox implementation of ConfigAdmin service. With felix.configadmin everything works fine. > NullPointerException when cm:property-placeholder used with a non existant > persistent id > > > Key: ARIES-441 > URL: https://issues.apache.org/jira/browse/ARIES-441 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: 0.3 >Reporter: Craig Muchinsky >Assignee: Grzegorz Grzybek > > When cm:property-placeholder is used and the persistence id specified doesn't > exist, the following NPE is thrown: > java.lang.NullPointerException > at > org.eclipse.equinox.internal.cm.ManagedServiceTracker.add(ManagedServiceTracker.java:115) > at > org.eclipse.equinox.internal.cm.ManagedServiceTracker.addingService(ManagedServiceTracker.java:70) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:715) > at > java.security.AccessController.doPrivileged(AccessController.java:202) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:713) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:525) > at > org.apache.aries.blueprint.compendium.cm.ManagedObjectManager.register(ManagedObjectManager.java:49) > at > org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder.init(CmPropertyPlaceholder.java:103) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:600) > at > org.apache.aries.blueprint.utils.ReflectionUtils$1.run(ReflectionUtils.java:226) > at > java.security.AccessController.doPrivileged(AccessController.java:284) > at > org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:224) > at > org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:829) > at > org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:634) > at > org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:729) > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64) > at > org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219) > at > org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:198) > at > org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:137) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.processProcessors(BlueprintContainerImpl.java:492) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:313) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:453) > at
[jira] [Assigned] (ARIES-1174) Avoid service reference timeout when system bundle is stopping
[ https://issues.apache.org/jira/browse/ARIES-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned ARIES-1174: --- Assignee: Grzegorz Grzybek > Avoid service reference timeout when system bundle is stopping > -- > > Key: ARIES-1174 > URL: https://issues.apache.org/jira/browse/ARIES-1174 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-core-1.1.0 >Reporter: Benno Geißelmann >Assignee: Grzegorz Grzybek > > The default timeout of Blueprint to wait for a service to come is 5 minutes. > A problem which comes with the timeout behaviour is, that in some states you > don't want to wait for the service. For example if the system bundle is in > state "stopping" this timeout will cause that the stopping takes 5 minutes. > In my opinion this makes no sense as the container will shutdown so there > shouldn't be waited for a service to come. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ARIES-1552) Aries Blueprint and Custom Namespace
[
https://issues.apache.org/jira/browse/ARIES-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180417#comment-16180417
]
Grzegorz Grzybek commented on ARIES-1552:
-
If you by _custom namespace_ mean some XML Schema document, then you have to
implement {{org.apache.aries.blueprint.NamespaceHandler}} interface.
> Aries Blueprint and Custom Namespace
>
>
> Key: ARIES-1552
> URL: https://issues.apache.org/jira/browse/ARIES-1552
> Project: Aries
> Issue Type: Question
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.2
>Reporter: Setya
>
> Hi all,
> My current OSGI-Spring based application is currently using AxonFramework
> which has custom namespace. If I were to migrate to Aries blueprint can still
> use the same custom namespace as is ?
> Regards,
> Setya
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ARIES-1593) Blueprint NamespaceHandler can't resolve XSD in offline mode
[ https://issues.apache.org/jira/browse/ARIES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved ARIES-1593. - Resolution: Duplicate Assignee: Grzegorz Grzybek duplicate of ARIES-1723 > Blueprint NamespaceHandler can't resolve XSD in offline mode > > > Key: ARIES-1593 > URL: https://issues.apache.org/jira/browse/ARIES-1593 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.6.1 >Reporter: Niten Aggarwal >Assignee: Grzegorz Grzybek > > When the NamespaceHandler is offline, it fails to resolve the XSD: > 1.6.1 | Unable to start blueprint container for bundle > org.talend.esb.job.controller/6.2.0.SNAPSHOT > org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name > 'ptp:ParameterizedInt' to a(n) 'simpleType definition' component. > at > org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown > Source)[:] > at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:] > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseNamedAttr(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseLocal(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.traverseAttrsAndAttrGrps(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseLocal(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlobal(Unknown > Source)[:] > at > org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown > Source)[:] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ARIES-1593) Blueprint NamespaceHandler can't resolve XSD in offline mode
[
https://issues.apache.org/jira/browse/ARIES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180410#comment-16180410
]
Grzegorz Grzybek commented on ARIES-1593:
-
You can always use {{etc/overrides.properties}} to instruct feature service to
use different version of blueprint-cm.
{{etc/overrides.properties}}:
{noformat}
mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core/1.6.2
{noformat}
> Blueprint NamespaceHandler can't resolve XSD in offline mode
>
>
> Key: ARIES-1593
> URL: https://issues.apache.org/jira/browse/ARIES-1593
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.1
>Reporter: Niten Aggarwal
>
> When the NamespaceHandler is offline, it fails to resolve the XSD:
> 1.6.1 | Unable to start blueprint container for bundle
> org.talend.esb.job.controller/6.2.0.SNAPSHOT
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
> 'ptp:ParameterizedInt' to a(n) 'simpleType definition' component.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
> at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseNamedAttr(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseLocal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.traverseAttrsAndAttrGrps(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseLocal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlobal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown
> Source)[:]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARIES-1723) Blueprint NamespaceHandler can't resolve XSD in offline mode
[
https://issues.apache.org/jira/browse/ARIES-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180393#comment-16180393
]
Grzegorz Grzybek commented on ARIES-1723:
-
I have these changes made to a class fixed with ARIES-1540:
{noformat}
* 195a95b32 - [ARIES-1682] Fallback to URL API if URI.resolve(systemId) is
still relative (case of jar:file:) (7 months ago)
* cd294ead5 - [ARIES-1503] Wrap bad behaving NamespaceHandlers to fix their
behavior (12 months ago)
* ff122ebcb - [ARIES-1574] Remove the reference to AutoCloseable in
blueprint-core in order to maintain Java 1.6 compatibility. (1 year, 3 months
ago)
* 91b7e4fe5 - [ARIES-1540] Blueprint NamespaceHandler can't resolve XSD in
offline mode (1 year, 5 months ago)
{noformat}
Which of the changes revert the behavior? We use blueprint-core 1.8.0 without
offline problems... Do you have sample blueprint.xml which fails offline?
> Blueprint NamespaceHandler can't resolve XSD in offline mode
>
>
> Key: ARIES-1723
> URL: https://issues.apache.org/jira/browse/ARIES-1723
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.8.0
>Reporter: Pointbreak
>Priority: Blocker
>
> When the NamespaceHandler is offline, it fails to resolve the XSD. This is
> the exact same bug that was resolved in ARIES-1540 (blueprint-core-1.6.2).
> The changes made in that fix seem to have been undone in later versions.
> Issue ARIES-1540 describes the issue, and contains the bugfix. If I look at
> the code for 1.8.0 the change of that fix can be applied with no changes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ARIES-1723) Blueprint NamespaceHandler can't resolve XSD in offline mode
[ https://issues.apache.org/jira/browse/ARIES-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned ARIES-1723: --- Assignee: Grzegorz Grzybek > Blueprint NamespaceHandler can't resolve XSD in offline mode > > > Key: ARIES-1723 > URL: https://issues.apache.org/jira/browse/ARIES-1723 > Project: Aries > Issue Type: Bug > Components: Blueprint >Affects Versions: blueprint-core-1.8.0 >Reporter: Pointbreak >Assignee: Grzegorz Grzybek >Priority: Blocker > > When the NamespaceHandler is offline, it fails to resolve the XSD. This is > the exact same bug that was resolved in ARIES-1540 (blueprint-core-1.6.2). > The changes made in that fix seem to have been undone in later versions. > Issue ARIES-1540 describes the issue, and contains the bugfix. If I look at > the code for 1.8.0 the change of that fix can be applied with no changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ARIES-1732) blueprint-cm - race condition
[ https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved ARIES-1732. - Resolution: Won't Fix > blueprint-cm - race condition > - > > Key: ARIES-1732 > URL: https://issues.apache.org/jira/browse/ARIES-1732 > Project: Aries > Issue Type: Bug > Components: Blueprint >Reporter: Paolo Antinori >Assignee: Grzegorz Grzybek > > There is a possible race condition in > `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and > `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager` > There are situations where `ConfigAdmin` service might not be available and > returns `null` when queried for the initial `config`. > In other cases instead, `CmPropertyPlaceholder` receives updates from > `ConfigAdmin` thread even before it has completed it's initialization. > The code doesn't discriminate if `config` is `null` or not, and treats any > value as valid, marking `CmPropertyPlaceholder` instance as initialized. > This leads to spotty errors. > The suggested fix, that simply prevents that `update(null)` invocation mark > the `CmPropertyPlaceholder` instance as initialized, addresses the issue. > Code here: > https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ARIES-1732) blueprint-cm - race condition
[ https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135075#comment-16135075 ] Grzegorz Grzybek commented on ARIES-1732: - [~paolo.antinori], [~gnt] please review my comments - IMO we should _won't fix_ it... > blueprint-cm - race condition > - > > Key: ARIES-1732 > URL: https://issues.apache.org/jira/browse/ARIES-1732 > Project: Aries > Issue Type: Bug > Components: Blueprint >Reporter: Paolo Antinori >Assignee: Grzegorz Grzybek > > There is a possible race condition in > `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and > `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager` > There are situations where `ConfigAdmin` service might not be available and > returns `null` when queried for the initial `config`. > In other cases instead, `CmPropertyPlaceholder` receives updates from > `ConfigAdmin` thread even before it has completed it's initialization. > The code doesn't discriminate if `config` is `null` or not, and treats any > value as valid, marking `CmPropertyPlaceholder` instance as initialized. > This leads to spotty errors. > The suggested fix, that simply prevents that `update(null)` invocation mark > the `CmPropertyPlaceholder` instance as initialized, addresses the issue. > Code here: > https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ARIES-1732) blueprint-cm - race condition
[
https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134849#comment-16134849
]
Grzegorz Grzybek commented on ARIES-1732:
-
We have a race inside
{{org.apache.aries.blueprint.compendium.cm.ManagedObjectManager#register()}} too
* calling {{cm.getBundle().getBundleContext().registerService()}} schedules
{{org.apache.felix.cm.impl.ConfigurationManager.ManagedServiceUpdate}} which
then calls
{{org.apache.aries.blueprint.compendium.cm.ManagedObjectManager.ConfigurationWatcher#updated()}}
in CM UpdateThread
* a bit later, we call {{cm.updated(config)}} after getting the CM
configuration manually
> blueprint-cm - race condition
> -
>
> Key: ARIES-1732
> URL: https://issues.apache.org/jira/browse/ARIES-1732
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Paolo Antinori
>Assignee: Grzegorz Grzybek
>
> There is a possible race condition in
> `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and
> `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager`
> There are situations where `ConfigAdmin` service might not be available and
> returns `null` when queried for the initial `config`.
> In other cases instead, `CmPropertyPlaceholder` receives updates from
> `ConfigAdmin` thread even before it has completed it's initialization.
> The code doesn't discriminate if `config` is `null` or not, and treats any
> value as valid, marking `CmPropertyPlaceholder` instance as initialized.
> This leads to spotty errors.
> The suggested fix, that simply prevents that `update(null)` invocation mark
> the `CmPropertyPlaceholder` instance as initialized, addresses the issue.
> Code here:
> https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ARIES-1668) Failing to set null value inside property-placeholder
[
https://issues.apache.org/jira/browse/ARIES-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned ARIES-1668:
---
Assignee: Grzegorz Grzybek
> Failing to set null value inside property-placeholder
> --
>
> Key: ARIES-1668
> URL: https://issues.apache.org/jira/browse/ARIES-1668
> Project: Aries
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Valentin Aitken
>Assignee: Grzegorz Grzybek
> Labels: blueprint
>
> *Scenario:*
> For a bean I'd like to supply property-placeholder with a default null value.
> {code:xml}
>
>
>
>
>
>
>
>
>
>
> {code}
> {code:java}
> package org.apache.xxx;
> public class FooImpl {
> public void setFooBar(Integer fooBar) { this.fooBar = fooBar;}
> public Integer getFooBar() { return fooBar; }
> }
> {code}
> *Observed behaviour:*
> {noformat}
> ERROR 17 o.a.a.b.c.BlueprintContainerImpl [rint Extender: 3] Unable to start
> blueprint container for bundle org.apache.xxx/0.x.0.SNAPSHOT
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error
> setting property: PropertyDescriptor org.apache.xxx.FooImpl.getFooBar(), setter: [class
> org.apache.xxx.FooImpl.setFooBar(class java.lang.Integer)]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:963)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:929)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:910)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:844)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[17:org.apache.aries.blueprint.core:1.5.0]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:712)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:399)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:273)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111]
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[17:org.apache.aries.blueprint.core:1.5.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_111]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_111]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_111]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_111]
> Caused by: java.lang.NumberFormatException: For input string: ""
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)[:1.8.0_111]
> {noformat}
> Versions loaded in karaf
> {noformat}
> | mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.api/1.0.1
> | mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.cm/1.0.7
> | mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core/1.5.0
> {noformat}
> *My Analysis:*
> I discovered that
>
[jira] [Commented] (ARIES-1732) blueprint-cm - race condition
[
https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134810#comment-16134810
]
Grzegorz Grzybek commented on ARIES-1732:
-
boolean logic isn't that easy...
When I tried the above, creating BP container when there's no PID, lead to
uninitialized {{CmManagedProperties#initialized}}. So when the PID was created,
{{CmManagedProperties}} was initialized, but the container wasn't reloaded
(because it was being initialized). There's another boolean flag needed then to
know we're in _was initialized with empty properties_
> blueprint-cm - race condition
> -
>
> Key: ARIES-1732
> URL: https://issues.apache.org/jira/browse/ARIES-1732
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Paolo Antinori
>Assignee: Grzegorz Grzybek
>
> There is a possible race condition in
> `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and
> `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager`
> There are situations where `ConfigAdmin` service might not be available and
> returns `null` when queried for the initial `config`.
> In other cases instead, `CmPropertyPlaceholder` receives updates from
> `ConfigAdmin` thread even before it has completed it's initialization.
> The code doesn't discriminate if `config` is `null` or not, and treats any
> value as valid, marking `CmPropertyPlaceholder` instance as initialized.
> This leads to spotty errors.
> The suggested fix, that simply prevents that `update(null)` invocation mark
> the `CmPropertyPlaceholder` instance as initialized, addresses the issue.
> Code here:
> https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ARIES-1732) blueprint-cm - race condition
[
https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133028#comment-16133028
]
Grzegorz Grzybek edited comment on ARIES-1732 at 8/21/17 5:49 AM:
--
Even if I found another solution to "multiple {{>}}
declarations for single PID" (ensuring that the configuration has "?" set as
location, so {{org.apache.felix.cm.impl.ConfigurationManager#canReceive()}}
returns {{true}} for all bundles), I still believe that Paolo's fix is fine.
I mean - if someone creates:
{code:xml}
{code}
(s)he doesn't expect the PID to be empty - and in fact doesn't expect CM to be
unavailable.
So my idea is to change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#updated()}} to:
* not accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
false
* not change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} to
true when it's false and props are empty
* accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
true (in case blueprint bundle is not restarted, but the PID is removed) -
looks like currently it's not happening...
What do you think?
was (Author: gzres):
Even if I found another solution to "multiple {{>}}
declarations for single PID" (ensuring that the configuration has "?" set as
location, so {{org.apache.felix.cm.impl.ConfigurationManager#canReceive()}}
returns {{true}} for all bundles), I still believe that Paolo's fix is fine.
I mean - if someone creates:
{code:xml}
{code}
(s)he doesn't expect the PID to be empty - and in fact doesn't expect CM to be
unavailable.
So my idea is to change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#updated()}} to:
* not accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
false
* not change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} to
true when it's false and props are empty
* accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
true (in case blueprint bundle is not restarted, but the PID is removed)
What do you think?
> blueprint-cm - race condition
> -
>
> Key: ARIES-1732
> URL: https://issues.apache.org/jira/browse/ARIES-1732
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Paolo Antinori
>Assignee: Grzegorz Grzybek
>
> There is a possible race condition in
> `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and
> `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager`
> There are situations where `ConfigAdmin` service might not be available and
> returns `null` when queried for the initial `config`.
> In other cases instead, `CmPropertyPlaceholder` receives updates from
> `ConfigAdmin` thread even before it has completed it's initialization.
> The code doesn't discriminate if `config` is `null` or not, and treats any
> value as valid, marking `CmPropertyPlaceholder` instance as initialized.
> This leads to spotty errors.
> The suggested fix, that simply prevents that `update(null)` invocation mark
> the `CmPropertyPlaceholder` instance as initialized, addresses the issue.
> Code here:
> https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARIES-1732) blueprint-cm - race condition
[
https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133028#comment-16133028
]
Grzegorz Grzybek commented on ARIES-1732:
-
Even if I found another solution to "multiple {{>}}
declarations for single PID" (ensuring that the configuration has "?" set as
location, so {{org.apache.felix.cm.impl.ConfigurationManager#canReceive()}}
returns {{true}} for all bundles), I still believe that Paolo's fix is fine.
I mean - if someone creates:
{code:xml}
{code}
(s)he doesn't expect the PID to be empty - and in fact doesn't expect CM to be
unavailable.
So my idea is to change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#updated()}} to:
* not accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
false
* not change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} to
true when it's false and props are empty
* accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
true (in case blueprint bundle is not restarted, but the PID is removed)
What do you think?
> blueprint-cm - race condition
> -
>
> Key: ARIES-1732
> URL: https://issues.apache.org/jira/browse/ARIES-1732
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Reporter: Paolo Antinori
>Assignee: Grzegorz Grzybek
>
> There is a possible race condition in
> `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and
> `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager`
> There are situations where `ConfigAdmin` service might not be available and
> returns `null` when queried for the initial `config`.
> In other cases instead, `CmPropertyPlaceholder` receives updates from
> `ConfigAdmin` thread even before it has completed it's initialization.
> The code doesn't discriminate if `config` is `null` or not, and treats any
> value as valid, marking `CmPropertyPlaceholder` instance as initialized.
> This leads to spotty errors.
> The suggested fix, that simply prevents that `update(null)` invocation mark
> the `CmPropertyPlaceholder` instance as initialized, addresses the issue.
> Code here:
> https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ARIES-1732) blueprint-cm - race condition
[ https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek reassigned ARIES-1732: --- Assignee: Grzegorz Grzybek > blueprint-cm - race condition > - > > Key: ARIES-1732 > URL: https://issues.apache.org/jira/browse/ARIES-1732 > Project: Aries > Issue Type: Bug > Components: Blueprint >Reporter: Paolo Antinori >Assignee: Grzegorz Grzybek > > There is a possible race condition in > `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and > `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager` > There are situations where `ConfigAdmin` service might not be available and > returns `null` when queried for the initial `config`. > In other cases instead, `CmPropertyPlaceholder` receives updates from > `ConfigAdmin` thread even before it has completed it's initialization. > The code doesn't discriminate if `config` is `null` or not, and treats any > value as valid, marking `CmPropertyPlaceholder` instance as initialized. > This leads to spotty errors. > The suggested fix, that simply prevents that `update(null)` invocation mark > the `CmPropertyPlaceholder` instance as initialized, addresses the issue. > Code here: > https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ARIES-1618) Regression after ARIES-1342: Duplicate interface name in class file
[
https://issues.apache.org/jira/browse/ARIES-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved ARIES-1618.
-
Resolution: Fixed
> Regression after ARIES-1342: Duplicate interface name in class file
> ---
>
> Key: ARIES-1618
> URL: https://issues.apache.org/jira/browse/ARIES-1618
> Project: Aries
> Issue Type: Bug
> Components: Proxy
>Affects Versions: proxy-impl-1.0.5
> Environment: Karaf 4.0.6, JDK 1.8.0_u77
>Reporter: Vladimir Konkov
>Assignee: Grzegorz Grzybek
>Priority: Critical
> Fix For: proxy-impl-1.1.1
>
>
> I have regression on Karaf 4.0.6 (Proxy Service 1.0.5) with such blueprint
> config:
> {code:xml}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0;>
> interface="org.apache.aries.transaction.AriesTransactionManager"/>
>
>
> {code}
> Because of hierarchy ordering fix in ARIES-1342 resulting interfaces set
> contains duplicates (!) - two javax.transaction.TransactionManager entries.
> As result Exception thrown on proxy class generation:
> {noformat}
> Caused by: org.apache.aries.proxy.UnableToProxyException:
> java.lang.ClassFormatError: Duplicate interface name in class file
> Proxy3636dfb0_3a9f_46d5_8eb4_32506b8a33ae
> at
> org.apache.aries.proxy.impl.interfaces.ProxyClassLoader.createProxyClass(ProxyClassLoader.java:165)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.interfaces.InterfaceProxyGenerator.getProxyInstance(InterfaceProxyGenerator.java:97)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.AsmProxyManager.createNewProxy(AsmProxyManager.java:80)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingInterceptingProxy(AbstractProxyManager.java:75)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingProxy(AbstractProxyManager.java:40)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.createProxy(AbstractServiceReferenceRecipe.java:332)[12:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:107)[12:org.apache.aries.blueprint.core:1.6.2]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[ https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002339#comment-16002339 ] Grzegorz Grzybek commented on ARIES-1719: - Added new tests in transaction/transaction-manager: * initialConfiguration() * initialConfigurationEmptyTransactionLog() * initialConfigurationExistingTransactionLogNoChanges() * existingTransactionLogChangedLogDir() * unknownExistingTransactionLogChangedLogDir() * changedNumberOfFiles() * changedMaxBlocksPerFile() * changedBlockSize() * changed3ParametersAndLogDir() * existingTransactionLogChangedLogFileName() * existingTransactionLogChangedLogFileNameAndLogDir() * existingTransactionLogChangedLogFileNameAndBlockSize() > HOWLLog can't be restarted with different configuration > --- > > Key: ARIES-1719 > URL: https://issues.apache.org/jira/browse/ARIES-1719 > Project: Aries > Issue Type: Bug > Components: Transaction >Affects Versions: transaction-manager-1.3.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > Fix For: transaction-manager-1.3.3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ARIES-1719) HOWLLog can't be restarted with different configuration
[ https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved ARIES-1719. - Resolution: Fixed Fix Version/s: transaction-manager-1.3.3 > HOWLLog can't be restarted with different configuration > --- > > Key: ARIES-1719 > URL: https://issues.apache.org/jira/browse/ARIES-1719 > Project: Aries > Issue Type: Bug > Components: Transaction >Affects Versions: transaction-manager-1.3.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > Fix For: transaction-manager-1.3.3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002274#comment-16002274
]
Grzegorz Grzybek commented on ARIES-1719:
-
This works too:
{noformat}
karaf@root> config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileName mytransaction
karaf@root> config:propdel --pid org.apache.aries.transaction
aries.transaction.howl.logFileName
karaf@root> config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileExt txt
karaf@root> config:propdel --pid org.apache.aries.transaction
aries.transaction.howl.logFileExt
{noformat}
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002255#comment-16002255
]
Grzegorz Grzybek commented on ARIES-1719:
-
Final solution - handles all changes to filename, extension, log dir and howl
related parameters:
{noformat}
2017-05-09 10:07:55,978 | INFO | {Karaf Shell Console Thread}
[org.apache.aries.transaction.internal.TransactionLogUtils] \
(TransactionLogUtils.java:163) | \
Copying transaction log from /karaf/data/txlog-015bec401b47 to
/karaf/data/txlog
2017-05-09 10:07:55,996 | INFO | {Karaf Shell Console Thread}
[org.apache.aries.transaction.internal.TransactionLogUtils] \
(TransactionLogUtils.java:193) | \
Copying active transaction with XID
[Xid:globalId=330006f72672e6170616368652e61726965732e7472616e73616374696f6e2e74657374000,length=64,branchId=,length=64]
2017-05-09 10:07:55,997 | INFO | {Karaf Shell Console Thread}
[org.apache.aries.transaction.internal.TransactionLogUtils] \
(TransactionLogUtils.java:195) | \
- Copying branch
[Xid:globalId=330006f72672e6170616368652e61726965732e7472616e73616374696f6e2e74657374000,length=64,branchId=10002a0006170616368652e61726965732e7472616e73616374696f6e2e74657374000,length=64]
for resource res-01
2017-05-09 10:07:56,032 | INFO | {Karaf Shell Console Thread}
[org.apache.aries.transaction.internal.TransactionLogUtils] \
(TransactionLogUtils.java:199) | Migration of active transactions finished
{noformat}
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (ARIES-1618) Regression after ARIES-1342: Duplicate interface name in class file
[
https://issues.apache.org/jira/browse/ARIES-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned ARIES-1618:
---
Assignee: Grzegorz Grzybek
> Regression after ARIES-1342: Duplicate interface name in class file
> ---
>
> Key: ARIES-1618
> URL: https://issues.apache.org/jira/browse/ARIES-1618
> Project: Aries
> Issue Type: Bug
> Components: Proxy
>Affects Versions: proxy-impl-1.0.5
> Environment: Karaf 4.0.6, JDK 1.8.0_u77
>Reporter: Vladimir Konkov
>Assignee: Grzegorz Grzybek
>Priority: Critical
>
> I have regression on Karaf 4.0.6 (Proxy Service 1.0.5) with such blueprint
> config:
> {code:xml}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0;>
> interface="org.apache.aries.transaction.AriesTransactionManager"/>
>
>
> {code}
> Because of hierarchy ordering fix in ARIES-1342 resulting interfaces set
> contains duplicates (!) - two javax.transaction.TransactionManager entries.
> As result Exception thrown on proxy class generation:
> {noformat}
> Caused by: org.apache.aries.proxy.UnableToProxyException:
> java.lang.ClassFormatError: Duplicate interface name in class file
> Proxy3636dfb0_3a9f_46d5_8eb4_32506b8a33ae
> at
> org.apache.aries.proxy.impl.interfaces.ProxyClassLoader.createProxyClass(ProxyClassLoader.java:165)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.interfaces.InterfaceProxyGenerator.getProxyInstance(InterfaceProxyGenerator.java:97)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.AsmProxyManager.createNewProxy(AsmProxyManager.java:80)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingInterceptingProxy(AbstractProxyManager.java:75)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingProxy(AbstractProxyManager.java:40)[20:org.apache.aries.proxy.impl:1.0.5]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.createProxy(AbstractServiceReferenceRecipe.java:332)[12:org.apache.aries.blueprint.core:1.6.2]
> at
> org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:107)[12:org.apache.aries.blueprint.core:1.6.2]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ARIES-1722) NLS class in transaction-manager refers to wrong message bundle
[ https://issues.apache.org/jira/browse/ARIES-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek resolved ARIES-1722. - Resolution: Fixed > NLS class in transaction-manager refers to wrong message bundle > --- > > Key: ARIES-1722 > URL: https://issues.apache.org/jira/browse/ARIES-1722 > Project: Aries > Issue Type: Bug > Components: Transaction >Affects Versions: transaction-manager-1.3.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986862#comment-15986862
]
Grzegorz Grzybek edited comment on ARIES-1719 at 4/27/17 3:57 PM:
--
OK, here's my solution.
I did {{config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileDir '$karaf.data/txlog7'}} and have
this in log:
{noformat}
2017-04-27 17:18:27,599 | INFO | {fileinstall-/data/karaf/etc} [?] (?:?) | \
Updating configuration from org.apache.aries.transaction.cfg
2017-04-27 17:18:27,656 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:178) | \
Copying transaction log from /data/karaf/data/txlog6 to
/data/karaf/data/txlog7
2017-04-27 17:18:27,661 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:203) | \
Copying active transaction with XID
[Xid:globalId=ffd93fffe8ffae5b10047544d4944000,length=64,branchId=,length=64]
2017-04-27 17:18:27,693 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:206) | \
Migration of active transactions finished
{noformat}
Of course I have to deal with {{stop}}→{{config:propset}}→{{start}}, because
when aries.transaction.manager bundle is stopped it can't migrate the tx log...
I have to implement migration even if aries.transaction.manager starts for the
first time with new configuration and old howl logs... I have to detect
previous configuration...
was (Author: gzres):
OK, here's my solution.
I did {{config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileDir '$karaf.data/txlog7'}} and have
this in log:
{noformat}
2017-04-27 17:18:27,599 | INFO | {fileinstall-/data/karaf/etc} [?] (?:?) | \
Updating configuration from org.apache.aries.transaction.cfg
2017-04-27 17:18:27,656 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:178) | \
Copying transaction log from /data/karaf/data/txlog6 to /data/karaf/txlog7
2017-04-27 17:18:27,661 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:203) | \
Copying active transaction with XID
[Xid:globalId=ffd93fffe8ffae5b10047544d4944000,length=64,branchId=,length=64]
2017-04-27 17:18:27,693 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:206) | \
Migration of active transactions finished
{noformat}
Of course I have to deal with {{stop}}→{{config:propset}}→{{start}}, because
when aries.transaction.manager bundle is stopped it can't migrate the tx log...
I have to implement migration even if aries.transaction.manager starts for the
first time with new configuration and old howl logs... I have to detect
previous configuration...
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986862#comment-15986862
]
Grzegorz Grzybek edited comment on ARIES-1719 at 4/27/17 3:55 PM:
--
OK, here's my solution.
I did {{config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileDir '$karaf.data/txlog7'}} and have
this in log:
{noformat}
2017-04-27 17:18:27,599 | INFO | {fileinstall-/data/karaf/etc} [?] (?:?) | \
Updating configuration from org.apache.aries.transaction.cfg
2017-04-27 17:18:27,656 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:178) | \
Copying transaction log from /data/karaf/data/txlog6 to /data/karaf/txlog7
2017-04-27 17:18:27,661 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:203) | \
Copying active transaction with XID
[Xid:globalId=ffd93fffe8ffae5b10047544d4944000,length=64,branchId=,length=64]
2017-04-27 17:18:27,693 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:206) | \
Migration of active transactions finished
{noformat}
Of course I have to deal with {{stop}}→{{config:propset}}→{{start}}, because
when aries.transaction.manager bundle is stopped it can't migrate the tx log...
I have to implement migration even if aries.transaction.manager starts for the
first time with new configuration and old howl logs... I have to detect
previous configuration...
was (Author: gzres):
OK, here's my solution.
I did {{config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileDir '$karaf.data/txlog7'}} and have
this in log:
{noformat}
2017-04-27 17:18:27,599 | INFO | {fileinstall-/data/karaf/etc} [?] (?:?) | \
Updating configuration from org.apache.aries.transaction.cfg
2017-04-27 17:18:27,656 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:178) | \
Copying transaction log from /data/karaf/data/txlog6 to /data/karaf/txlog7
2017-04-27 17:18:27,661 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:203) | \
Copying active transaction with XID
[Xid:globalId=ffd93fffe8ffae5b10047544d4944000,length=64,branchId=,length=64]
2017-04-27 17:18:27,693 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:206) | \
Migration of active transactions finished
{noformat}
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15986862#comment-15986862
]
Grzegorz Grzybek commented on ARIES-1719:
-
OK, here's my solution.
I did {{config:propset --pid org.apache.aries.transaction
aries.transaction.howl.logFileDir '$karaf.data/txlog7'}} and have
this in log:
{noformat}
2017-04-27 17:18:27,599 | INFO | {fileinstall-/data/karaf/etc} [?] (?:?) | \
Updating configuration from org.apache.aries.transaction.cfg
2017-04-27 17:18:27,656 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:178) | \
Copying transaction log from /data/karaf/data/txlog6 to /data/karaf/txlog7
2017-04-27 17:18:27,661 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:203) | \
Copying active transaction with XID
[Xid:globalId=ffd93fffe8ffae5b10047544d4944000,length=64,branchId=,length=64]
2017-04-27 17:18:27,693 | INFO | {CM Configuration Updater (Update:
pid=org.apache.aries.transaction)}
[org.apache.aries.transaction.internal.Activator] (Activator.java:206) | \
Migration of active transactions finished
{noformat}
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[ https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983229#comment-15983229 ] Grzegorz Grzybek commented on ARIES-1719: - Thanks - I'll do my best. btw - were there any plans to fork/include in geronimo-txmanager the repository from svn.forge.objectweb.org/svnroot/howl? > HOWLLog can't be restarted with different configuration > --- > > Key: ARIES-1719 > URL: https://issues.apache.org/jira/browse/ARIES-1719 > Project: Aries > Issue Type: Bug > Components: Transaction >Affects Versions: transaction-manager-1.3.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983154#comment-15983154
]
Grzegorz Grzybek commented on ARIES-1719:
-
After the initial problem, next changes lead always to:
{noformat}
18:21:18,770 | ERROR | ies.transaction) | configadmin | 7
- org.apache.felix.configadmin - 1.8.4 | [org.osgi.service.cm.ManagedService,
id=311,
bundle=163/mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.3.0]:
Updating configuration org.apache.aries.transaction caused a problem:
LogFileManager.open: unable to obtain lock on file
$KARAF_HOME/data/txlog/transaction_1.log
org.osgi.service.cm.ConfigurationException: null : LogFileManager.open: unable
to obtain lock on file $KARAF_HOME/data/txlog/transaction_1.log
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:139)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.Activator.updated(Activator.java:65)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1747)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[7:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: org.objectweb.howl.log.LogConfigurationException:
LogFileManager.open: unable to obtain lock on file
$KARAF_HOME/data/txlog/transaction_1.log
at
org.objectweb.howl.log.LogFileManager.open(LogFileManager.java:782)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.Logger.open(Logger.java:304)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:258)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:136)[163:org.apache.aries.transaction.manager:1.3.0]
... 7 more
{noformat}
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983139#comment-15983139
]
Grzegorz Grzybek edited comment on ARIES-1719 at 4/25/17 4:18 PM:
--
{{org.apache.aries.transaction.manager}} bundle starts
{{org.apache.aries.transaction.internal.TransactionManagerService}} and
(underneath) {{org.apache.geronimo.transaction.log.HOWLLog}}.
Everything is configured using {{org.apache.aries.transaction}} PID.
When changing {{aries.transaction.howl.maxBlocksPerFile}} property we can't
start new instance of service. In Karaf it can be reproduced using:
{noformat}
> config:propset --pid org.apache.aries.transaction
> aries.transaction.howl.maxBlocksPerFile 512
{noformat}
In logs, we have:
{noformat}
14:57:14,776 | ERROR | ies.transaction) | configadmin | 7
- org.apache.felix.configadmin - 1.8.4 | [org.osgi.service.cm.ManagedService,
id=311,
bundle=163/mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.3.0]:
Updating configuration org.apache.aries.transaction caused a problem:
Configured file size [512] blocks not equal previous file size [2147483647]
blocks
org.osgi.service.cm.ConfigurationException: null : Configured file size [512]
blocks not equal previous file size [2147483647] blocks
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:139)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.Activator.updated(Activator.java:65)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1747)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[7:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: org.objectweb.howl.log.LogConfigurationException: Configured file
size [512] blocks not equal previous file size [2147483647] blocks
at
org.objectweb.howl.log.LogFileManager.validateFileHeader(LogFileManager.java:1072)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.LogFileManager.init(LogFileManager.java:901)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.Logger.open(Logger.java:315)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:258)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:136)[163:org.apache.aries.transaction.manager:1.3.0]
... 7 more
{noformat}
In my opinion, we should wipe old logs.
was (Author: gzres):
{{org.apache.aries.transaction.manager}} bundle starts
{{org.apache.aries.transaction.internal.TransactionManagerService}} and
(underneath) {{org.apache.geronimo.transaction.log.HOWLLog}}.
Everything is configured using {{org.apache.aries.transaction}} PID.
When changing {{aries.transaction.howl.maxBlocksPerFile}} property we can't
start new instance of service. In Karaf it can be reproduced using:
{noformat}
> config:propset --pid org.apache.aries.transaction
> aries.transaction.howl.maxBlocksPerFile 512
{noformat}
In logs, we have:
{noformat}
14:57:14,776 | ERROR | ies.transaction) | configadmin | 7
- org.apache.felix.configadmin - 1.8.4 | [org.osgi.service.cm.ManagedService,
id=311,
bundle=163/mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.3.0]:
Updating configuration org.apache.aries.transaction caused a problem:
Configured file size [512] blocks not equal previous file size [2147483647]
blocks
org.osgi.service.cm.ConfigurationException: null : Configured file size [512]
blocks not equal previous file size [2147483647] blocks
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:139)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.Activator.updated(Activator.java:65)[163:org.apache.aries.transaction.manager:1.3.0]
at
[jira] [Commented] (ARIES-1719) HOWLLog can't be restarted with different configuration
[
https://issues.apache.org/jira/browse/ARIES-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983139#comment-15983139
]
Grzegorz Grzybek commented on ARIES-1719:
-
{{org.apache.aries.transaction.manager}} bundle starts
{{org.apache.aries.transaction.internal.TransactionManagerService}} and
(underneath) {{org.apache.geronimo.transaction.log.HOWLLog}}.
Everything is configured using {{org.apache.aries.transaction}} PID.
When changing {{aries.transaction.howl.maxBlocksPerFile}} property we can't
start new instance of service. In Karaf it can be reproduced using:
{noformat}
> config:propset --pid org.apache.aries.transaction
> aries.transaction.howl.maxBlocksPerFile 512
{noformat}
In logs, we have:
{noformat}
14:57:14,776 | ERROR | ies.transaction) | configadmin | 7
- org.apache.felix.configadmin - 1.8.4 | [org.osgi.service.cm.ManagedService,
id=311,
bundle=163/mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.3.0]:
Updating configuration org.apache.aries.transaction caused a problem:
Configured file size [512] blocks not equal previous file size [2147483647]
blocks
org.osgi.service.cm.ConfigurationException: null : Configured file size [512]
blocks not equal previous file size [2147483647] blocks
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:139)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.Activator.updated(Activator.java:65)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1747)[7:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[7:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: org.objectweb.howl.log.LogConfigurationException: Configured file
size [512] blocks not equal previous file size [2147483647] blocks
at
org.objectweb.howl.log.LogFileManager.validateFileHeader(LogFileManager.java:1072)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.LogFileManager.init(LogFileManager.java:901)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.Logger.open(Logger.java:315)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.objectweb.howl.log.xa.XALogger.open(XALogger.java:893)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:258)[163:org.apache.aries.transaction.manager:1.3.0]
at
org.apache.aries.transaction.internal.TransactionManagerService.(TransactionManagerService.java:136)[163:org.apache.aries.transaction.manager:1.3.0]
... 7 more
{noformat}
> HOWLLog can't be restarted with different configuration
> ---
>
> Key: ARIES-1719
> URL: https://issues.apache.org/jira/browse/ARIES-1719
> Project: Aries
> Issue Type: Bug
> Components: Transaction
>Affects Versions: transaction-manager-1.3.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved ARIES-1682.
-
Resolution: Fixed
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
> Fix For: blueprint-core-1.7.2
>
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any bundle using the
> http://cxf.apache.org/transports/http/configuration namespace.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-1682:
Fix Version/s: blueprint-core-1.7.2
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
> Fix For: blueprint-core-1.7.2
>
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any bundle using the
> http://cxf.apache.org/transports/http/configuration namespace.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887600#comment-15887600
]
Grzegorz Grzybek commented on ARIES-1682:
-
Resolved
[here|https://github.com/apache/aries/compare/ad13b48aeedc985e4fbfdb60d5230cb05012b5c3%5E...79ab9deb3d7c5c94763e320d5855a1d9c84a9961]
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
> Fix For: blueprint-core-1.7.2
>
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any bundle using the
>
[jira] [Commented] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882394#comment-15882394
]
Grzegorz Grzybek commented on ARIES-1682:
-
PR with test: https://github.com/apache/aries/pull/66
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any bundle using the
> http://cxf.apache.org/transports/http/configuration namespace.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882291#comment-15882291
]
Grzegorz Grzybek commented on ARIES-1682:
-
Of course I didn't read your comment about problems with {{jar:file://}} :)
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any bundle using the
> http://cxf.apache.org/transports/http/configuration namespace.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882247#comment-15882247
]
Grzegorz Grzybek commented on ARIES-1682:
-
Hmm, from:
* systemId = "./blueprint-aries-1682-common.xsd"
* baseURI = "bundleresource://32.fwk2144665602/blueprint-aries-1682.xsd"
I got resolved =
"bundleresource://32.fwk2144665602/blueprint-aries-1682-common.xsd"
Checking in real Karaf.
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any
[jira] [Assigned] (ARIES-1682) Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
[
https://issues.apache.org/jira/browse/ARIES-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reassigned ARIES-1682:
---
Assignee: Grzegorz Grzybek
> Aries Blueprint Core 1.7.1 breaks relative JAR URI handling
> ---
>
> Key: ARIES-1682
> URL: https://issues.apache.org/jira/browse/ARIES-1682
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.7.1
>Reporter: John Poth
>Assignee: Grzegorz Grzybek
>
> When
> [resolving|(https://github.com/apache/aries/blob/fbc9ce10264b5c87e2a466b163824045c1817dcb/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/namespace/NamespaceHandlerRegistryImpl.java#L577]
> relative xsd paths, blueprint will throw the error:
> {code}
> java.lang.RuntimeException: java.net.MalformedURLException: no protocol:
> ../wsdl/http-conf.xsd
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:514)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchemaSource(XSDHandler.java:2109)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1092)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:628)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.MalformedURLException: no protocol: ../wsdl/http-conf.xsd
> at java.net.URL.(URL.java:593)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl$Loader.resolveResource(NamespaceHandlerRegistryImpl.java:512)
> ... 26 more
> {code}
> This was caused by the relative path in
> [CXF|https://github.com/apache/cxf/blob/a8bf13d406548837a307842aca3e8cbcc267135c/rt/transports/http/src/main/resources/schemas/configuration/http-conf.xsd#L34]
> in the xsd.
> To reproduce simply deploy any bundle using the
> http://cxf.apache.org/transports/http/configuration namespace.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (ARIES-1684) Upgrade ZooKeeper to 3.4.9
[ https://issues.apache.org/jira/browse/ARIES-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871395#comment-15871395 ] Grzegorz Grzybek edited comment on ARIES-1684 at 2/17/17 8:17 AM: -- I suggest waiting for 3.4.10 or downgrading to 3.4.7, see ZOOKEEPER-2383. I also maintain zookeeper server in OSGi runtime (fabric8v1) and I had problems with 3.4.8 and 3.4.9. was (Author: gzres): I suggest waiting for 3.4.10 or downgrading to 3.4.7, see ZOOKEEPER-2383. > Upgrade ZooKeeper to 3.4.9 > -- > > Key: ARIES-1684 > URL: https://issues.apache.org/jira/browse/ARIES-1684 > Project: Aries > Issue Type: Improvement > Components: Remote Service Admin >Affects Versions: rsa-1.9.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider > Fix For: rsa-1.10.0 > > > 3.4.7 has been removed from the official release list, and in any case it's a > bit old. 3.4.9 has been out for several months and fixes some additional > issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARIES-1540) Blueprint NamespaceHandler can't resolve XSD in offline mode
[
https://issues.apache.org/jira/browse/ARIES-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15842568#comment-15842568
]
Grzegorz Grzybek commented on ARIES-1540:
-
[~leinweberm] yes - we've fixed it with CXF-7183.
> Blueprint NamespaceHandler can't resolve XSD in offline mode
>
>
> Key: ARIES-1540
> URL: https://issues.apache.org/jira/browse/ARIES-1540
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.1
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
> Fix For: blueprint-core-1.6.2
>
>
> When the NamespaceHandler is offline, it fails to resolve the XSD:
> {code}
> 17:18:44,952 | WARN | pool-27-thread-1 | l$NamespaceHandlerSetImpl$Loader
> 544 | 16 - org.apache.aries.blueprint.core - 1.6.1 | Dynamically adding
> namespace handler http://cxf.apache.org/configuration/beans to bundle
> org.talend.esb.job.controller/6.2.0.SNAPSHOT
> 17:18:44,955 | WARN | pool-27-thread-1 | l$NamespaceHandlerSetImpl$Loader
> 544 | 16 - org.apache.aries.blueprint.core - 1.6.1 | Dynamically adding
> namespace handler http://cxf.apache.org/configuration/parameterized-types to
> bundle org.talend.esb.job.controller/6.2.0.SNAPSHOT
> 17:18:44,956 | ERROR | pool-27-thread-1 | container.BlueprintContainerImpl
> 437 | 16 - org.apache.aries.blueprint.core - 1.6.1 | Unable to start
> blueprint container for bundle org.talend.esb.job.controller/6.2.0.SNAPSHOT
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
> 'ptp:ParameterizedInt' to a(n) 'simpleType definition' component.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
> at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseNamedAttr(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseLocal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.traverseAttrsAndAttrGrps(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseLocal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlobal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown
> Source)[:]
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
> Source)[:]
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)[:]
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown
> Source)[:]
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown
> Source)[:]
> at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown
> Source)[:]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.createSchema(NamespaceHandlerRegistryImpl.java:637)[16:org.apache.aries.blueprint.core:1.6.1]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.doGetSchema(NamespaceHandlerRegistryImpl.java:458)[16:org.apache.aries.blueprint.core:1.6.1]
> at
> org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:443)[16:org.apache.aries.blueprint.core:1.6.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:343)[16:org.apache.aries.blueprint.core:1.6.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)[16:org.apache.aries.blueprint.core:1.6.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)[16:org.apache.aries.blueprint.core:1.6.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)[16:org.apache.aries.blueprint.core:1.6.1]
>
[jira] [Commented] (ARIES-1407) Service (un)registration listener not called anymore
[ https://issues.apache.org/jira/browse/ARIES-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571391#comment-15571391 ] Grzegorz Grzybek commented on ARIES-1407: - spring-dm is not maintained for almost 7 years now. spring-dm was good idea in the golden age of OSGi and Spring guys had always the _advantage_ of being both implementation and specification - they just did what they thought is ok. I'm not sure how spring-dm works, but probably some kind of listener is invoked ... And remember - spring-dm is and extension to ubiquitous ApplicationContext, where you have all kids of spring-framework mechanisms like events and listeners, factory objects, etc. So it can't really be compared with Blueprint which was OSGi from day 0. > Service (un)registration listener not called anymore > > > Key: ARIES-1407 > URL: https://issues.apache.org/jira/browse/ARIES-1407 > Project: Aries > Issue Type: Bug > Components: Blueprint > Environment: Servicemix 5.4.1 >Reporter: metatech > Attachments: blueprint_registration_listener_fix_v2.patch > > > Service (un)registration listeners are not called anymore since Blueprint > 1.4.0. > There are 2 booleans in the "ServiceRecipe" class which are tested against > the wrong values. > Please find a patch which makes them work again with Blueprint 1.4.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
