[jira] [Commented] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources
[ https://issues.apache.org/jira/browse/ARIES-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028694#comment-15028694 ] Sergey Beryozkin commented on ARIES-1460: - Hi Aki, can you please give me a favour and run CXF JAXRSSoapRestBlueprintTest with these changes ? I'll be happy to apply it afterwards Cheers, Sergey > Using blueprint-noosgi, unable to resolve absolute schemas to their local > resources > > > Key: ARIES-1460 > URL: https://issues.apache.org/jira/browse/ARIES-1460 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-noosgi-1.1.1 >Reporter: Akitoshi Yoshida > Attachments: > 0001-ARIES-1460-Using-blueprint-noosgi-unable-to-resolve-.patch > > > When using blueprint-noosgi, it seems its schema handling code (i.e., > SimpleNamespaceHandlerSet#getSchema) can resolve relative schemas but not > absolute schemas to their corresponding local resources. As a result, one > will require the Internet connection to resolve those schemas. > It will be practical to avoid making an unnecessary remote schema retrieval. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources
[ https://issues.apache.org/jira/browse/ARIES-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated ARIES-1460: Comment: was deleted (was: Never mind, I'll do it myself :-)) > Using blueprint-noosgi, unable to resolve absolute schemas to their local > resources > > > Key: ARIES-1460 > URL: https://issues.apache.org/jira/browse/ARIES-1460 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-noosgi-1.1.1 >Reporter: Akitoshi Yoshida > Attachments: > 0001-ARIES-1460-Using-blueprint-noosgi-unable-to-resolve-.patch > > > When using blueprint-noosgi, it seems its schema handling code (i.e., > SimpleNamespaceHandlerSet#getSchema) can resolve relative schemas but not > absolute schemas to their corresponding local resources. As a result, one > will require the Internet connection to resolve those schemas. > It will be practical to avoid making an unnecessary remote schema retrieval. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources
[ https://issues.apache.org/jira/browse/ARIES-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated ARIES-1460: Comment: was deleted (was: Hi Aki, can you please give me a favour and run CXF JAXRSSoapRestBlueprintTest with these changes ? I'll be happy to apply it afterwards Cheers, Sergey) > Using blueprint-noosgi, unable to resolve absolute schemas to their local > resources > > > Key: ARIES-1460 > URL: https://issues.apache.org/jira/browse/ARIES-1460 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-noosgi-1.1.1 >Reporter: Akitoshi Yoshida > Attachments: > 0001-ARIES-1460-Using-blueprint-noosgi-unable-to-resolve-.patch > > > When using blueprint-noosgi, it seems its schema handling code (i.e., > SimpleNamespaceHandlerSet#getSchema) can resolve relative schemas but not > absolute schemas to their corresponding local resources. As a result, one > will require the Internet connection to resolve those schemas. > It will be practical to avoid making an unnecessary remote schema retrieval. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources
[ https://issues.apache.org/jira/browse/ARIES-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028696#comment-15028696 ] Sergey Beryozkin commented on ARIES-1460: - Never mind, I'll do it myself :-) > Using blueprint-noosgi, unable to resolve absolute schemas to their local > resources > > > Key: ARIES-1460 > URL: https://issues.apache.org/jira/browse/ARIES-1460 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-noosgi-1.1.1 >Reporter: Akitoshi Yoshida > Attachments: > 0001-ARIES-1460-Using-blueprint-noosgi-unable-to-resolve-.patch > > > When using blueprint-noosgi, it seems its schema handling code (i.e., > SimpleNamespaceHandlerSet#getSchema) can resolve relative schemas but not > absolute schemas to their corresponding local resources. As a result, one > will require the Internet connection to resolve those schemas. > It will be practical to avoid making an unnecessary remote schema retrieval. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources
[ https://issues.apache.org/jira/browse/ARIES-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved ARIES-1460. - Resolution: Fixed Assignee: Sergey Beryozkin Thanks for the patch > Using blueprint-noosgi, unable to resolve absolute schemas to their local > resources > > > Key: ARIES-1460 > URL: https://issues.apache.org/jira/browse/ARIES-1460 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-noosgi-1.1.1 >Reporter: Akitoshi Yoshida >Assignee: Sergey Beryozkin > Attachments: > 0001-ARIES-1460-Using-blueprint-noosgi-unable-to-resolve-.patch > > > When using blueprint-noosgi, it seems its schema handling code (i.e., > SimpleNamespaceHandlerSet#getSchema) can resolve relative schemas but not > absolute schemas to their corresponding local resources. As a result, one > will require the Internet connection to resolve those schemas. > It will be practical to avoid making an unnecessary remote schema retrieval. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources
[ https://issues.apache.org/jira/browse/ARIES-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated ARIES-1460: Fix Version/s: blueprint-noosgi-1.1.2 > Using blueprint-noosgi, unable to resolve absolute schemas to their local > resources > > > Key: ARIES-1460 > URL: https://issues.apache.org/jira/browse/ARIES-1460 > Project: Aries > Issue Type: Improvement > Components: Blueprint >Affects Versions: blueprint-noosgi-1.1.1 >Reporter: Akitoshi Yoshida >Assignee: Sergey Beryozkin > Fix For: blueprint-noosgi-1.1.2 > > Attachments: > 0001-ARIES-1460-Using-blueprint-noosgi-unable-to-resolve-.patch > > > When using blueprint-noosgi, it seems its schema handling code (i.e., > SimpleNamespaceHandlerSet#getSchema) can resolve relative schemas but not > absolute schemas to their corresponding local resources. As a result, one > will require the Internet connection to resolve those schemas. > It will be practical to avoid making an unnecessary remote schema retrieval. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1323) Update blueprint-web ServletContextListener to optionally register NamespaceHandlers
[
https://issues.apache.org/jira/browse/ARIES-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved ARIES-1323.
-
Resolution: Fixed
Update blueprint-web ServletContextListener to optionally register
NamespaceHandlers
Key: ARIES-1323
URL: https://issues.apache.org/jira/browse/ARIES-1323
Project: Aries
Issue Type: Improvement
Components: Blueprint, Web
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Minor
Fix For: blueprint-web-1.1.1
Attachments: aries1323.txt
Option 1. Use a 'blueprintNamespaceHandlers' context parameter:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
Option 2. Check META-INF/blueprint.handlers class resources. The handler
resource only lists one or more NamespaceHandler classes, example:
{noformat}
a.b.C
d.e.F
{noformat}
The web.xml will look much simpler:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1322) Introduce Namespaces annotation
[ https://issues.apache.org/jira/browse/ARIES-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved ARIES-1322. - Resolution: Fixed Introduce Namespaces annotation --- Key: ARIES-1322 URL: https://issues.apache.org/jira/browse/ARIES-1322 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: blueprint-parser-1.1.1 This applies to a blueprint-parser component. NamespaceHandler interface does not list the namespaces this handler supports which makes it difficult to automate the registration of handlers in non-OSGI contexts. Having a Namespace annotation will provide an optional mechanism for NamespaceHandlers to advertise the list of supported namespaces and help discovering the handlers in non OSGI contexts but also introspect them in OSGI if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1334) NoOsgi SimpleNamespaceHandlerSet should try to resolve relative schema references
[ https://issues.apache.org/jira/browse/ARIES-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved ARIES-1334. - Resolution: Fixed NoOsgi SimpleNamespaceHandlerSet should try to resolve relative schema references - Key: ARIES-1334 URL: https://issues.apache.org/jira/browse/ARIES-1334 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: blueprint-noosgi-1.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1322) Introduce Namespaces annotation
[ https://issues.apache.org/jira/browse/ARIES-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated ARIES-1322: Fix Version/s: blueprint-parser-1.1.1 Introduce Namespaces annotation --- Key: ARIES-1322 URL: https://issues.apache.org/jira/browse/ARIES-1322 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: blueprint-parser-1.1.1 This applies to a blueprint-parser component. NamespaceHandler interface does not list the namespaces this handler supports which makes it difficult to automate the registration of handlers in non-OSGI contexts. Having a Namespace annotation will provide an optional mechanism for NamespaceHandlers to advertise the list of supported namespaces and help discovering the handlers in non OSGI contexts but also introspect them in OSGI if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1323) Update blueprint-web ServletContextListener to optionally register NamespaceHandlers
[
https://issues.apache.org/jira/browse/ARIES-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated ARIES-1323:
Description:
Option 1. Use a 'blueprintNamespaceHandlers' context parameter:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
Option 2. Check META-INF/blueprint.handlers class resources. The handler
resource only lists one or more NamespaceHandler classes, example:
{noformat}
a.b.C
d.e.F
{noformat}
The web.xml will look much simpler:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
was:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
Summary: Update blueprint-web ServletContextListener to optionally
register NamespaceHandlers (was: Update blueprint-web ServletContextListener
to register NamespaceHandlers if a blueprintNamespaceHandlers property is set)
Update blueprint-web ServletContextListener to optionally register
NamespaceHandlers
Key: ARIES-1323
URL: https://issues.apache.org/jira/browse/ARIES-1323
Project: Aries
Issue Type: Improvement
Components: Blueprint, Web
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Minor
Fix For: blueprint-web-1.1.1
Attachments: aries1323.txt
Option 1. Use a 'blueprintNamespaceHandlers' context parameter:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
Option 2. Check META-INF/blueprint.handlers class resources. The handler
resource only lists one or more NamespaceHandler classes, example:
{noformat}
a.b.C
d.e.F
{noformat}
The web.xml will look much simpler:
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1323) Update blueprint-web ServletContextListener to register NamespaceHandlers if a blueprintNamespaceHandlers property is set
[
https://issues.apache.org/jira/browse/ARIES-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated ARIES-1323:
Component/s: Web
Fix Version/s: blueprint-web-1.1.1
Update blueprint-web ServletContextListener to register NamespaceHandlers if
a blueprintNamespaceHandlers property is set
-
Key: ARIES-1323
URL: https://issues.apache.org/jira/browse/ARIES-1323
Project: Aries
Issue Type: Improvement
Components: Blueprint, Web
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Minor
Fix For: blueprint-web-1.1.1
Attachments: aries1323.txt
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARIES-1322) Introduce Namespaces annotation
Sergey Beryozkin created ARIES-1322: --- Summary: Introduce Namespaces annotation Key: ARIES-1322 URL: https://issues.apache.org/jira/browse/ARIES-1322 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor This applies to a blueprint-parser component. NamespaceHandler interface does not list the namespaces this handler supports which makes it difficult to automate the registration of handlers in non-OSGI contexts. Having a Namespace annotation will provide an optional mechanism for NamespaceHandlers to advertise the list of supported namespaces and help discovering the handlers in non OSGI contexts but also introspect them in OSGI if needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1322) Introduce Namespaces annotation
[
https://issues.apache.org/jira/browse/ARIES-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14547955#comment-14547955
]
Sergey Beryozkin commented on ARIES-1322:
-
{code:java}
@Inherited
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Namespaces {
/**
* A list of namespaces supported by codeNamespaceHandler/code.
*/
String[] value();
}
{code}
Introduce Namespaces annotation
---
Key: ARIES-1322
URL: https://issues.apache.org/jira/browse/ARIES-1322
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Minor
This applies to a blueprint-parser component.
NamespaceHandler interface does not list the namespaces this handler supports
which makes it difficult to automate the registration of handlers in non-OSGI
contexts.
Having a Namespace annotation will provide an optional mechanism for
NamespaceHandlers to advertise the list of supported namespaces and help
discovering the handlers in non OSGI contexts but also introspect them in
OSGI if needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1323) Update blueprint-web ServletContextListener to register NamespaceHandlers if a blueprintNamespaceHandlers property is set
[
https://issues.apache.org/jira/browse/ARIES-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated ARIES-1323:
Attachment: aries1323.txt
Update blueprint-web ServletContextListener to register NamespaceHandlers if
a blueprintNamespaceHandlers property is set
-
Key: ARIES-1323
URL: https://issues.apache.org/jira/browse/ARIES-1323
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Minor
Attachments: aries1323.txt
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARIES-1323) Update blueprint-web ServletContextListener to register NamespaceHandlers if a blueprintNamespaceHandlers property is set
Sergey Beryozkin created ARIES-1323:
---
Summary: Update blueprint-web ServletContextListener to register
NamespaceHandlers if a blueprintNamespaceHandlers property is set
Key: ARIES-1323
URL: https://issues.apache.org/jira/browse/ARIES-1323
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Priority: Minor
{code:xml}
web-app
context-param
param-nameblueprintLocation/param-name
param-valueWEB-INF/beans.xml/param-value
/context-param
context-param
param-nameblueprintNamespaceHandlers/param-name
param-value
a.b.C,
d.e.F
/param-value
/context-param
listener
listener-class
org.apache.aries.blueprint.web.BlueprintContextListener
/listener-class
/listener
!-- the rest of web-app --
/web-app
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1300) NoOsgi BlueprintContextImpl should accept custom namespace handler sets
[ https://issues.apache.org/jira/browse/ARIES-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved ARIES-1300. - Resolution: Fixed Fix Version/s: blueprint-web-1.1.0 blueprint-noosgi-1.1.0 NoOsgi BlueprintContextImpl should accept custom namespace handler sets --- Key: ARIES-1300 URL: https://issues.apache.org/jira/browse/ARIES-1300 Project: Aries Issue Type: Improvement Components: Blueprint, Web Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: blueprint-noosgi-1.1.0, blueprint-web-1.1.0 Attachments: aries1300.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1300) NoOsgi BlueprintContextImpl should accept custom namespace handler sets
Sergey Beryozkin created ARIES-1300: --- Summary: NoOsgi BlueprintContextImpl should accept custom namespace handler sets Key: ARIES-1300 URL: https://issues.apache.org/jira/browse/ARIES-1300 Project: Aries Issue Type: Improvement Components: Blueprint, Web Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1300) NoOsgi BlueprintContextImpl should accept custom namespace handler sets
[ https://issues.apache.org/jira/browse/ARIES-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated ARIES-1300: Attachment: aries1300.txt NoOsgi BlueprintContextImpl should accept custom namespace handler sets --- Key: ARIES-1300 URL: https://issues.apache.org/jira/browse/ARIES-1300 Project: Aries Issue Type: Improvement Components: Blueprint, Web Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Attachments: aries1300.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1160) Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED
[ https://issues.apache.org/jira/browse/ARIES-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968280#comment-13968280 ] Sergey Beryozkin commented on ARIES-1160: - Sure, everyone seems to be happy about it, so I'm about to apply it shortly Cheers, Sergey Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED - Key: ARIES-1160 URL: https://issues.apache.org/jira/browse/ARIES-1160 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 1.0 Environment: OSGi Reporter: Andrei Shakirin Attachments: ARIES-1160-2.patch, aries-jpa-1.0.0-ARIES-1160.patch, org.apache.aries.jpa.container.patch Use case: persistence bundle is deployed in OSGi using Hibernate persistence provider. Bundle contains blueprint configuration injecting EntityManager and activates transaction management: blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jpa=http://aries.apache.org/xmlns/jpa/v1.0.0; xmlns:tx=http://aries.apache.org/xmlns/transactions/v1.0.0; bean id=addressDao class=de.conrad.ccp.basit.customer.ecom.dao.impl.AddressDaoImpl jpa:context unitname=ecom property=entityManager/ tx:transaction method=* value=Required/ /bean service ref=addressDao interface=de.conrad.ccp.basit.entity.customer.ecom.dao.AddressDao / /blueprint Effect: bundle waiting for EntityManager service. The reason of problem is runtime exception by providerService.createContainerEntityManagerFactory(mpui.getPersistenceUnitInfo(), mpui.getContainerProperties()). Exception is unfortunately not logged by Aries. The stack trace is following: java.lang.IllegalStateException: The bundle de.conrad.poc.customerservice-ecom/0 .0.1.SNAPSHOT is not started. at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(JndiDat aSource.java:61) at org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getC onnection(DelayedLookupDataSource.java:36) at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.get Connection(InjectedDataSourceConnectionProvider.java:70) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProvide rJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:242) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcSer vicesImpl.java:117) at org.hibernate.service.internal.StandardServiceRegistryImpl.configureS ervice(StandardServiceRegistryImpl.java:76) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initialize Service(AbstractServiceRegistryImpl.java:160) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService (AbstractServiceRegistryImpl.java:132) at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration. java:1825) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.jav a:1783) at org.hibernate.ejb.EntityManagerFactoryImpl.init(EntityManagerFactor yImpl.java:96) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Con figuration.java:914) at org.hibernate.osgi.OsgiPersistenceProvider.createContainerEntityManag erFactory(OsgiPersistenceProvider.java:99) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.creat eEntityManagerFactories(EntityManagerFactoryManager.java:330) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundl eStateChange(EntityManagerFactoryManager.java:175) at org.apache.aries.jpa.container.impl.PersistenceBundleManager.addingSe rvice(PersistenceBundleManager.java:197) The problem is that call of createEntityManagerFactories() in EntityManagerFactoryManager.bundleStateChange() is made by BUNDLE.RESOLVED event. The lookup of data source is failed, because the bundle context is not yet available (call by BUNDLE.RESOLVED event). The createEntityManagerFactory is called again by Bundle.ACTIVE event, the problem is that emfs hash map is already created, but it is empty. Therefore STARTED/ACTIVE createEntityManagerFactories() is called, but makes nothing. Attached patch contains two changes: a) log runtime exception throwing by providerService.createContainerEntityManagerFactory b) adds check to empty hash map: if(((emfs == null) || emfs.isEmpty()) !quiesce) The patch fixes the problem. Basically it should analyzed is call createEntityManagerFactories() really necessary for Bundle.RESOLVED event. -- This message was sent by Atlassian JIRA
[jira] [Commented] (ARIES-1160) Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED
[ https://issues.apache.org/jira/browse/ARIES-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968302#comment-13968302 ] Sergey Beryozkin commented on ARIES-1160: - Looks like Apache SVN can not accept the commits right now... Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED - Key: ARIES-1160 URL: https://issues.apache.org/jira/browse/ARIES-1160 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 1.0 Environment: OSGi Reporter: Andrei Shakirin Attachments: ARIES-1160-2.patch, aries-jpa-1.0.0-ARIES-1160.patch, org.apache.aries.jpa.container.patch Use case: persistence bundle is deployed in OSGi using Hibernate persistence provider. Bundle contains blueprint configuration injecting EntityManager and activates transaction management: blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jpa=http://aries.apache.org/xmlns/jpa/v1.0.0; xmlns:tx=http://aries.apache.org/xmlns/transactions/v1.0.0; bean id=addressDao class=de.conrad.ccp.basit.customer.ecom.dao.impl.AddressDaoImpl jpa:context unitname=ecom property=entityManager/ tx:transaction method=* value=Required/ /bean service ref=addressDao interface=de.conrad.ccp.basit.entity.customer.ecom.dao.AddressDao / /blueprint Effect: bundle waiting for EntityManager service. The reason of problem is runtime exception by providerService.createContainerEntityManagerFactory(mpui.getPersistenceUnitInfo(), mpui.getContainerProperties()). Exception is unfortunately not logged by Aries. The stack trace is following: java.lang.IllegalStateException: The bundle de.conrad.poc.customerservice-ecom/0 .0.1.SNAPSHOT is not started. at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(JndiDat aSource.java:61) at org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getC onnection(DelayedLookupDataSource.java:36) at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.get Connection(InjectedDataSourceConnectionProvider.java:70) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProvide rJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:242) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcSer vicesImpl.java:117) at org.hibernate.service.internal.StandardServiceRegistryImpl.configureS ervice(StandardServiceRegistryImpl.java:76) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initialize Service(AbstractServiceRegistryImpl.java:160) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService (AbstractServiceRegistryImpl.java:132) at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration. java:1825) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.jav a:1783) at org.hibernate.ejb.EntityManagerFactoryImpl.init(EntityManagerFactor yImpl.java:96) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Con figuration.java:914) at org.hibernate.osgi.OsgiPersistenceProvider.createContainerEntityManag erFactory(OsgiPersistenceProvider.java:99) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.creat eEntityManagerFactories(EntityManagerFactoryManager.java:330) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundl eStateChange(EntityManagerFactoryManager.java:175) at org.apache.aries.jpa.container.impl.PersistenceBundleManager.addingSe rvice(PersistenceBundleManager.java:197) The problem is that call of createEntityManagerFactories() in EntityManagerFactoryManager.bundleStateChange() is made by BUNDLE.RESOLVED event. The lookup of data source is failed, because the bundle context is not yet available (call by BUNDLE.RESOLVED event). The createEntityManagerFactory is called again by Bundle.ACTIVE event, the problem is that emfs hash map is already created, but it is empty. Therefore STARTED/ACTIVE createEntityManagerFactories() is called, but makes nothing. Attached patch contains two changes: a) log runtime exception throwing by providerService.createContainerEntityManagerFactory b) adds check to empty hash map: if(((emfs == null) || emfs.isEmpty()) !quiesce) The patch fixes the problem. Basically it should analyzed is call createEntityManagerFactories() really necessary for Bundle.RESOLVED event. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (ARIES-1160) Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED
[ https://issues.apache.org/jira/browse/ARIES-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved ARIES-1160. - Resolution: Fixed Fix Version/s: 1.0.1-SNAPSHOT Assignee: Sergey Beryozkin Andrei, Christian, thanks for opening this JIRA and creating patches, the latest patch from Christian applied. I'm marking as fixed for 1.0.1-SNAPSHOT, which seems to be the only matching version. Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED - Key: ARIES-1160 URL: https://issues.apache.org/jira/browse/ARIES-1160 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 1.0 Environment: OSGi Reporter: Andrei Shakirin Assignee: Sergey Beryozkin Fix For: 1.0.1-SNAPSHOT Attachments: ARIES-1160-2.patch, aries-jpa-1.0.0-ARIES-1160.patch, org.apache.aries.jpa.container.patch Use case: persistence bundle is deployed in OSGi using Hibernate persistence provider. Bundle contains blueprint configuration injecting EntityManager and activates transaction management: blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jpa=http://aries.apache.org/xmlns/jpa/v1.0.0; xmlns:tx=http://aries.apache.org/xmlns/transactions/v1.0.0; bean id=addressDao class=de.conrad.ccp.basit.customer.ecom.dao.impl.AddressDaoImpl jpa:context unitname=ecom property=entityManager/ tx:transaction method=* value=Required/ /bean service ref=addressDao interface=de.conrad.ccp.basit.entity.customer.ecom.dao.AddressDao / /blueprint Effect: bundle waiting for EntityManager service. The reason of problem is runtime exception by providerService.createContainerEntityManagerFactory(mpui.getPersistenceUnitInfo(), mpui.getContainerProperties()). Exception is unfortunately not logged by Aries. The stack trace is following: java.lang.IllegalStateException: The bundle de.conrad.poc.customerservice-ecom/0 .0.1.SNAPSHOT is not started. at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(JndiDat aSource.java:61) at org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getC onnection(DelayedLookupDataSource.java:36) at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.get Connection(InjectedDataSourceConnectionProvider.java:70) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProvide rJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:242) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcSer vicesImpl.java:117) at org.hibernate.service.internal.StandardServiceRegistryImpl.configureS ervice(StandardServiceRegistryImpl.java:76) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initialize Service(AbstractServiceRegistryImpl.java:160) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService (AbstractServiceRegistryImpl.java:132) at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration. java:1825) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.jav a:1783) at org.hibernate.ejb.EntityManagerFactoryImpl.init(EntityManagerFactor yImpl.java:96) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Con figuration.java:914) at org.hibernate.osgi.OsgiPersistenceProvider.createContainerEntityManag erFactory(OsgiPersistenceProvider.java:99) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.creat eEntityManagerFactories(EntityManagerFactoryManager.java:330) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundl eStateChange(EntityManagerFactoryManager.java:175) at org.apache.aries.jpa.container.impl.PersistenceBundleManager.addingSe rvice(PersistenceBundleManager.java:197) The problem is that call of createEntityManagerFactories() in EntityManagerFactoryManager.bundleStateChange() is made by BUNDLE.RESOLVED event. The lookup of data source is failed, because the bundle context is not yet available (call by BUNDLE.RESOLVED event). The createEntityManagerFactory is called again by Bundle.ACTIVE event, the problem is that emfs hash map is already created, but it is empty. Therefore STARTED/ACTIVE createEntityManagerFactories() is called, but makes nothing. Attached patch contains two changes: a) log runtime exception throwing by providerService.createContainerEntityManagerFactory b) adds check to empty hash map: if(((emfs ==
[jira] [Commented] (ARIES-1160) Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED
[ https://issues.apache.org/jira/browse/ARIES-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13960017#comment-13960017 ] Sergey Beryozkin commented on ARIES-1160: - Hi All, I can take care of applying it once the patch is finalized, as it looks like all support it Thanks Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED - Key: ARIES-1160 URL: https://issues.apache.org/jira/browse/ARIES-1160 Project: Aries Issue Type: Bug Components: JPA Affects Versions: 1.0 Environment: OSGi Reporter: Andrei Shakirin Attachments: org.apache.aries.jpa.container.patch Use case: persistence bundle is deployed in OSGi using Hibernate persistence provider. Bundle contains blueprint configuration injecting EntityManager and activates transaction management: blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jpa=http://aries.apache.org/xmlns/jpa/v1.0.0; xmlns:tx=http://aries.apache.org/xmlns/transactions/v1.0.0; bean id=addressDao class=de.conrad.ccp.basit.customer.ecom.dao.impl.AddressDaoImpl jpa:context unitname=ecom property=entityManager/ tx:transaction method=* value=Required/ /bean service ref=addressDao interface=de.conrad.ccp.basit.entity.customer.ecom.dao.AddressDao / /blueprint Effect: bundle waiting for EntityManager service. The reason of problem is runtime exception by providerService.createContainerEntityManagerFactory(mpui.getPersistenceUnitInfo(), mpui.getContainerProperties()). Exception is unfortunately not logged by Aries. The stack trace is following: java.lang.IllegalStateException: The bundle de.conrad.poc.customerservice-ecom/0 .0.1.SNAPSHOT is not started. at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(JndiDat aSource.java:61) at org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getC onnection(DelayedLookupDataSource.java:36) at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.get Connection(InjectedDataSourceConnectionProvider.java:70) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProvide rJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:242) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcSer vicesImpl.java:117) at org.hibernate.service.internal.StandardServiceRegistryImpl.configureS ervice(StandardServiceRegistryImpl.java:76) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initialize Service(AbstractServiceRegistryImpl.java:160) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService (AbstractServiceRegistryImpl.java:132) at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration. java:1825) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.jav a:1783) at org.hibernate.ejb.EntityManagerFactoryImpl.init(EntityManagerFactor yImpl.java:96) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Con figuration.java:914) at org.hibernate.osgi.OsgiPersistenceProvider.createContainerEntityManag erFactory(OsgiPersistenceProvider.java:99) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.creat eEntityManagerFactories(EntityManagerFactoryManager.java:330) at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundl eStateChange(EntityManagerFactoryManager.java:175) at org.apache.aries.jpa.container.impl.PersistenceBundleManager.addingSe rvice(PersistenceBundleManager.java:197) The problem is that call of createEntityManagerFactories() in EntityManagerFactoryManager.bundleStateChange() is made by BUNDLE.RESOLVED event. The lookup of data source is failed, because the bundle context is not yet available (call by BUNDLE.RESOLVED event). The createEntityManagerFactory is called again by Bundle.ACTIVE event, the problem is that emfs hash map is already created, but it is empty. Therefore STARTED/ACTIVE createEntityManagerFactories() is called, but makes nothing. Attached patch contains two changes: a) log runtime exception throwing by providerService.createContainerEntityManagerFactory b) adds check to empty hash map: if(((emfs == null) || emfs.isEmpty()) !quiesce) The patch fixes the problem. Basically it should analyzed is call createEntityManagerFactories() really necessary for Bundle.RESOLVED event. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ARIES-1131) Extend blueprint.service import version range in blueprint.webosgi bundle
[ https://issues.apache.org/jira/browse/ARIES-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814313#comment-13814313 ] Sergey Beryozkin commented on ARIES-1131: - Hi JB, thanks for the initial fix, would like to confirm that the 'http' feature does not provide a support for a webbundle: protocol which blueprint-web-osgi would support, so I believe we need a 'war' dependency which does offer a support for it. Cheers, Sergey Extend blueprint.service import version range in blueprint.webosgi bundle - Key: ARIES-1131 URL: https://issues.apache.org/jira/browse/ARIES-1131 Project: Aries Issue Type: Bug Components: Web Reporter: Jean-Baptiste Onofré Assignee: Sergey Beryozkin Attachments: ARIES-1131.patch blueprint.webosgi 1.0.0 bundle imports org.apache.aries.blueprint.service package with version 1.3.0. Unfortunately, blueprint-core 1.3.0 exports this package with version 1.2.0 (which is not correct, I will create another Jira for that). In order to be able to use blueprint.webosgi with blueprint-core 1.3.0, the import version range should be extended to [1.2, 2). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (ARIES-1131) Extend blueprint.service import version range in blueprint.webosgi bundle
[ https://issues.apache.org/jira/browse/ARIES-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated ARIES-1131: Comment: was deleted (was: Hi JB, thanks for the initial fix, would like to confirm that the 'http' feature does not provide a support for a webbundle: protocol which blueprint-web-osgi would support, so I believe we need a 'war' dependency which does offer a support for it. Cheers, Sergey ) Extend blueprint.service import version range in blueprint.webosgi bundle - Key: ARIES-1131 URL: https://issues.apache.org/jira/browse/ARIES-1131 Project: Aries Issue Type: Bug Components: Web Reporter: Jean-Baptiste Onofré Assignee: Sergey Beryozkin Attachments: ARIES-1131.patch blueprint.webosgi 1.0.0 bundle imports org.apache.aries.blueprint.service package with version 1.3.0. Unfortunately, blueprint-core 1.3.0 exports this package with version 1.2.0 (which is not correct, I will create another Jira for that). In order to be able to use blueprint.webosgi with blueprint-core 1.3.0, the import version range should be extended to [1.2, 2). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (ARIES-1131) Extend blueprint.service import version range in blueprint.webosgi bundle
[ https://issues.apache.org/jira/browse/ARIES-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin reassigned ARIES-1131: --- Assignee: Sergey Beryozkin Extend blueprint.service import version range in blueprint.webosgi bundle - Key: ARIES-1131 URL: https://issues.apache.org/jira/browse/ARIES-1131 Project: Aries Issue Type: Bug Components: Web Reporter: Jean-Baptiste Onofré Assignee: Sergey Beryozkin Attachments: ARIES-1131.patch blueprint.webosgi 1.0.0 bundle imports org.apache.aries.blueprint.service package with version 1.3.0. Unfortunately, blueprint-core 1.3.0 exports this package with version 1.2.0 (which is not correct, I will create another Jira for that). In order to be able to use blueprint.webosgi with blueprint-core 1.3.0, the import version range should be extended to [1.2, 2). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ARIES-1121) Introduce BlueprintExtenderService to simplify managing BlueprintContainers from the code
[
https://issues.apache.org/jira/browse/ARIES-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790222#comment-13790222
]
Sergey Beryozkin commented on ARIES-1121:
-
Few comments on the proposed service interface:
{code:java}
public interface BlueprintExtenderService {
BlueprintContainer createContainer(Bundle bundle);
BlueprintContainer createContainer(Bundle bundle, ListObject
blueprintPaths);
BlueprintContainer getContainer(Bundle bundle);
void destroyContainer(Bundle bundle, BlueprintContainer container);
}
{code}
I don't think it needs to become more complex, but I reckon it may not be quite
as minimalistic as it can be.
Specifically, createContainer(Bundle bundle) method is likely to be redundant
in most cases, because if the bundle has Blueprint metadata then the extender
has already created a context and thus getContainer(Bundle bundle) is enough.
That said, having this method probably won't harm.
Next, destroyContainer(Bundle bundle, BlueprintContainer container) -
probably is redundant as well, because the extender is listening on the bundles
so it can remove a container itself. Again, may be keeping won't harm - may be
doing a pro-active clean up can make sense in some cases. The 2nd parameter in
this method is redundant for sure, but I thought the caller should not have a
too easy way to destroy a container for a given bundle.
The thing I've been thinking about: this service interface can be moved to its
own module, if really needed, so that only those applications that need this
service will install this module. That can be easily done but I wonder it it
will be pushing it a bit too far.
Introduce BlueprintExtenderService to simplify managing BlueprintContainers
from the code
-
Key: ARIES-1121
URL: https://issues.apache.org/jira/browse/ARIES-1121
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
Attachments: aries1121.txt
It is not easy to create BlueprintContainers from the code, with
BlueprintExtender being the main piece of code dealing with the containers.
Proposal: Introduce BlueprintExtenderService which will make it
straght-forward for interested consumers to create and use
BlueprintContainers.
The patch for the community review is to follow. Another JIRA supporting a
specific use case will be opened shortly too
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (ARIES-1121) Introduce BlueprintExtenderService to simplify managing BlueprintContainers from the code
Sergey Beryozkin created ARIES-1121: --- Summary: Introduce BlueprintExtenderService to simplify managing BlueprintContainers from the code Key: ARIES-1121 URL: https://issues.apache.org/jira/browse/ARIES-1121 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin It is not easy to create BlueprintContainers from the code, with BlueprintExtender being the main piece of code dealing with the containers. Proposal: Introduce BlueprintExtenderService which will make it straght-forward for interested consumers to create and use BlueprintContainers. The patch for the community review is to follow. Another JIRA supporting a specific use case will be opened shortly too -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ARIES-1122) Introduce Blueprint Web OSGI module
Sergey Beryozkin created ARIES-1122: --- Summary: Introduce Blueprint Web OSGI module Key: ARIES-1122 URL: https://issues.apache.org/jira/browse/ARIES-1122 Project: Aries Issue Type: New Feature Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin The existing Blueprint Web module depends on a non-OSGI Blueprint module. In some cases it is necessary to be able to access or create BlueprintContainer for a given bundle the same way Blueprint Web does but in OSGI environment. Example: Custom servlet will depend on OSGI aware Blueprint ServletContextListener. This listener will use a proposed BlueprintExtenderService to create BlueprintContainer and set is as ServletContext attribute. The custom servlet will check BlueprintContainer and extract the required application components -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ARIES-1122) Introduce Blueprint Web OSGI module
[ https://issues.apache.org/jira/browse/ARIES-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788242#comment-13788242 ] Sergey Beryozkin commented on ARIES-1122: - The new module has a lower bound blueprint-core dependency set to 1.0, will need to be set to 1.2.1 if Aries-1121 is resolved for blueprint-core 1.2.1 Introduce Blueprint Web OSGI module --- Key: ARIES-1122 URL: https://issues.apache.org/jira/browse/ARIES-1122 Project: Aries Issue Type: New Feature Components: Blueprint Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Attachments: aries1122.txt The existing Blueprint Web module depends on a non-OSGI Blueprint module. In some cases it is necessary to be able to access or create BlueprintContainer for a given bundle the same way Blueprint Web does but in OSGI environment. Example: Custom servlet will depend on OSGI aware Blueprint ServletContextListener. This listener will use a proposed BlueprintExtenderService to create BlueprintContainer and set is as ServletContext attribute. The custom servlet will check BlueprintContainer and extract the required application components -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ARIES-855) Blueprint should attempt to load static nested classes when the initial attempt to load a class has failed
Sergey Beryozkin created ARIES-855:
--
Summary: Blueprint should attempt to load static nested classes
when the initial attempt to load a class has failed
Key: ARIES-855
URL: https://issues.apache.org/jira/browse/ARIES-855
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
At the moment the Blueprint schema blocks the static nested class names,
example, trying to get SimpleBean#Nested:
{code:java}
public class SimpleBean {
public static Nested {
}
}
{code}
referenced as SimpleBean#Nested in a blueprint context fails with the
validation error.
As proposed at the Osgi-dev by BJ H., the implementation should attempt to load
a nested class if the original load attempt fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ARIES-855) Blueprint should attempt to load static nested classes when the initial attempt to load a class has failed
[
https://issues.apache.org/jira/browse/ARIES-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated ARIES-855:
---
Attachment: aries855.txt
The proposed patch does a single recursion attempt only, given that no use
cases for supporting the deeply nested static classes exists and also to make
the delay in throwing the load exception very minimal.
During the single recursive call only the top level catch block will report an
error log message, and a debug one in case of attempting a retry.
This can be extended to manage nested hierarchies if really needed
Blueprint should attempt to load static nested classes when the initial
attempt to load a class has failed
--
Key: ARIES-855
URL: https://issues.apache.org/jira/browse/ARIES-855
Project: Aries
Issue Type: Improvement
Components: Blueprint
Reporter: Sergey Beryozkin
Attachments: aries855.txt
At the moment the Blueprint schema blocks the static nested class names,
example, trying to get SimpleBean#Nested:
{code:java}
public class SimpleBean {
public static Nested {
}
}
{code}
referenced as SimpleBean#Nested in a blueprint context fails with the
validation error.
As proposed at the Osgi-dev by BJ H., the implementation should attempt to
load a nested class if the original load attempt fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy
[ https://issues.apache.org/jira/browse/ARIES-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269721#comment-13269721 ] Sergey Beryozkin commented on ARIES-847: Check for 'null' is redundant. Instanceof will always return false if a left operand is null. I don't have a reference to the relevant JVM section to prove it :-), but it is true. Similarly, the string concatenation would convert a null object to 'null. Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy Key: ARIES-847 URL: https://issues.apache.org/jira/browse/ARIES-847 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Christian Schneider Assignee: Sergey Beryozkin Fix For: 0.4 Attachments: aries-847-1.patch If the blueprint file contains an error the obj given to destroy may be null. Currently this is not handled. The big problem in this case is that the user does not get a good error message about his error in the context. I will add a patch with the check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy
[ https://issues.apache.org/jira/browse/ARIES-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269721#comment-13269721 ] Sergey Beryozkin edited comment on ARIES-847 at 5/7/12 4:00 PM: Check for 'null' is redundant. Instanceof will always return false if a left operand is null. I don't have a reference to the relevant JVM section to prove it :-), but it is true. Similarly, the string concatenation would convert a null object to 'null'. was (Author: sergey_beryozkin): Check for 'null' is redundant. Instanceof will always return false if a left operand is null. I don't have a reference to the relevant JVM section to prove it :-), but it is true. Similarly, the string concatenation would convert a null object to 'null. Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy Key: ARIES-847 URL: https://issues.apache.org/jira/browse/ARIES-847 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Christian Schneider Assignee: Sergey Beryozkin Fix For: 0.4 Attachments: aries-847-1.patch If the blueprint file contains an error the obj given to destroy may be null. Currently this is not handled. The big problem in this case is that the user does not get a good error message about his error in the context. I will add a patch with the check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy
[ https://issues.apache.org/jira/browse/ARIES-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269751#comment-13269751 ] Sergey Beryozkin commented on ARIES-847: Hi Christian, I think I'd stick to your original patch idea, i.e., return if the object is not of the expected type, both 'null' diff type confitions seem to deserve the warning. Throwing the exception looks reasonable too, but looking at the source of BeanRecipe.destroy suggests that the policy is to log and let the process the continue. I'm not familiar well enough with Aries yet so I'd be concerned that throwing an exception could affect the overall destroy process somehow... Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy Key: ARIES-847 URL: https://issues.apache.org/jira/browse/ARIES-847 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Christian Schneider Assignee: Sergey Beryozkin Fix For: 0.4 Attachments: aries-847-1.patch If the blueprint file contains an error the obj given to destroy may be null. Currently this is not handled. The big problem in this case is that the user does not get a good error message about his error in the context. I will add a patch with the check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy
[ https://issues.apache.org/jira/browse/ARIES-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269751#comment-13269751 ] Sergey Beryozkin edited comment on ARIES-847 at 5/7/12 4:32 PM: Hi Christian, I think I'd stick to your original patch idea, i.e., return if the object is not of the expected type, both 'null' diff type conditions seem to deserve the warning. Throwing the exception looks reasonable too, but looking at the source of BeanRecipe.destroy suggests that the policy is to log and let the process the continue. I'm not familiar well enough with Aries yet so I'd be concerned that throwing an exception could affect the overall destroy process somehow... was (Author: sergey_beryozkin): Hi Christian, I think I'd stick to your original patch idea, i.e., return if the object is not of the expected type, both 'null' diff type confitions seem to deserve the warning. Throwing the exception looks reasonable too, but looking at the source of BeanRecipe.destroy suggests that the policy is to log and let the process the continue. I'm not familiar well enough with Aries yet so I'd be concerned that throwing an exception could affect the overall destroy process somehow... Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy Key: ARIES-847 URL: https://issues.apache.org/jira/browse/ARIES-847 Project: Aries Issue Type: Bug Components: Blueprint Affects Versions: 0.4 Reporter: Christian Schneider Assignee: Sergey Beryozkin Fix For: 0.4 Attachments: aries-847-1.patch If the blueprint file contains an error the obj given to destroy may be null. Currently this is not handled. The big problem in this case is that the user does not get a good error message about his error in the context. I will add a patch with the check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
