Re: [VOTE] Release Apache Aries Remote Service Admin 1.10.0 - 2

[Sergey Beryozkin]

+1

Sergey
On 22/02/17 10:13, Christian Schneider wrote:

In comparison to the first release vote I fixed this additional issue:

ClassloaderObjectInputStream can not load InputStreamProxy class
https://issues.apache.org/jira/browse/ARIES-1693


Highlights:

- Streams and async calls for fastbin
- Capabilities and requirements from the rsa spec 1.1


I've staged the release at

https://repository.apache.org/content/repositories/orgapachearies-1098

For a list of issues resolved see:

https://issues.apache.org/jira/browse/ARIES/fixforversion/12338250


Release Notes - Aries - Version rsa-1.10.0

** Bug
* [ARIES-1623] - FilterHelper OBJECTCLASS_EXPRESSION excludes inner
classes
* [ARIES-1632] - fastbin does not throw an error for unknown services

** Improvement
* [ARIES-1595] - Support capabilities and requirements specified in
RSA 1.1

** New Feature
* [ARIES-1586] - Async calls in fastbin
* [ARIES-1587] - Support streams in fastbin


Please review and vote

Here is my
+1

Christian

Re: [VOTE] Aries blueprint-maven-plugin-spi 1.0.0 & blueprint-maven-plugin-annotation 1.0.0 & blueprint-maven-plugin 1.5.0

[Sergey Beryozkin]

+1

Sergey


On 30.11.2016 15:01, Dominik Przybysz wrote:

I've staged a release for vote at:
*https://repository.apache.org/content/repositories/orgapachearies-1090
*

Release Notes - Aries blueprint-maven-plugin-spi 1.0.0 &
blueprint-maven-plugin-annotation 1.0.0 & blueprint-maven-plugin 1.5.0

** Bugs:
* [ARIES-1596] Exception when running blueprint-maven-plugin
* [ARIES-1555] Cannot build blueprint-maven-plugin

** Improvements:
* [ARIES-1619] Add javadoc in blueprint maven plugin spi
* [ARIES-1611] Blueprint plugin: support javax.cdi.Transactional
annotation
* [ARIES-1610] Blueprint plugin: check namespace patterns instead conrete
namespace
* [ARIES-1602] Remove annotations from Blueprint Maven Plugin model
package
and make them using only SPI
* [ARIES-1599] Add new goal to blueprint maven plugin -
add-resource-dir in
generate-resources phase
* [ARIES-1598] Generate blueprint file in generated-sources/blueprint
directory
* [ARIES-1597] blueprint-maven-plugin new option to override generatedDir
* [ARIES-1570] Prepare extension machanism in blueprint maven plugin
* [ARIES-1568] Support @DependsOn annotation
* [ARIES-1566] Support @Lazy annotation
* [ARIES-1563] Add field-injection attribute only if bean needs it
* [ARIES-1562] Allow for setter injection in blueprint-maven-plugin
* [ARIES-1561] Produced bean could be exposed as Service in
blueprint-maven-plugin

** New features:
* [ARIES-1628] Allow to configure beans with pure annotations
* [ARIES-1606] Extract SPI from blueptin maven plugin to external project
* [ARIES-1605] Add custom preperties map in plugin and spi handler for
init
context

*https://issues.apache.org/jira/browse/ARIES/fixforversion/12336065/
*


Please review and vote:
   [ ] +1 Release the above artifacts
   [ ] -1 Do not

Here is my +1 (non-binding)

Re: Just a personal introduction

[Sergey Beryozkin]

Nice, welcome

Sergey
On 20/07/16 19:12, Carlos Sierra Andrés wrote:

Hello everyone,

I am Carlos Sierra and I work in Liferay. I worked in Liferay's OSGi
support for JAX-RS and I hopefully will help in OSGi RFC 217 and a
future RI implementation for Aries project.

I hope I can learn a lot from you all and eventually be helpful.

Bests!




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] Apache Aries Blueprint Core 1.6.2

[Sergey Beryozkin]

+1


On 29/04/16 17:37, Guillaume Nodet wrote:

+1

2016-04-29 18:32 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:


Hi all,

in order to fix ARIES-1540 (critical issue), I submit blueprint-core 1.6.2
release to your vote.

Staging Repository:
https://repository.apache.org/content/repositories/orgapachearies-1068/

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com








--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] Release 6 bug fix bundles

[Sergey Beryozkin]

+1

Checked again CXF blueprint-noosgi test without the connection, all is good

Cheers, Sergey
On 15/03/16 16:24, Guillaume Nodet wrote:

I've staged a vote for the following bundles:
   * proxy-impl 1.0.5
   * jmx-core 1.1.6
   * blueprint-core 1.6.0
   * blueprint-spring 0.2.0
   * blueprint-spring-extender 0.2.0
   * blueprint-noosgi 1.1.2

Staging repository
https://repository.apache.org/content/repositories/orgapachearies-1061

Proxy-Impl 1.0.5
** Bug
 * [ARIES-1161] - ProxyGenerator uses ProxyCLassLoaded with wrong
classloader
 * [ARIES-1342] - Aries Proxy Impl fails to proxy a service with
covariant type hierarchy in Java 8
 * [ARIES-1486] - can't create proxy on java 8 vm  for interfaces
containing lambda
 * [ARIES-1492] - Exception creating a subclass proxy of class with
package-private access modifer.

Jmx-Core 1.1.6
** Bug
 * [ARIES-1468] - Aries Transaction Blueprint bundle fails to start
sometimes

Blueprint Core 1.6.0
** Bug
 * [ARIES-1498] - NullPointerException NPE Blueprint Container
AbstractServiceReferenceRecipe setSatisfied
 * [ARIES-1500] - Fix wildcard types support
 * [ARIES-1503] - Timing issue when cm blueprint references ext
namespaces
** New Feature
 * [ARIES-1482] - Support programmatic creation of blueprint container
with specific additional namespaces

Blueprint Spring 0.2.0 / Blueprint Spring Extender 0.2.0
** New Feature
 * [ARIES-1480] - Complete spring extender support

Blueprint Noosgi 1.1.2
** Improvement
 * [ARIES-1460] - Using blueprint-noosgi, unable to resolve absolute
schemas to their local resources


Please review and vote !

Cheers




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] Create new subproject Aries Remote Service Admin with initial code from CXF DOSGi

[Sergey Beryozkin]

+1

Sergey
On 07/03/16 16:06, Christian Schneider wrote:

In my previous mail I started a discussion about moving the CXF DOSGi
code to Aries.
As there was no negative feedback I am starting a vote to create a new
subproject and move the non CXF specific code over to aries.

I propose the name Aries Remote Service Admin (aries-rsa) as a name.

The goal of the project is to implement the remote service admin spec in
a very slim way with as few external dependencies as possible.
A secondary goal is to provide an API for providers that allows to
implement new transports and serializations in a very simple way.

An initial code structure could look like this:
/rsa
 /parent
 /core
 /topology-manager
 /provider-api
 /rsa-core
 /discovery
 /local
 /zookeeper
 /provider
 /rmi
 /itests
 /features
 /examples

The CXF specific provider will remain at CXF.
I think we do not need to provide a full distribution like in CXF-DOSGi.
A karaf feature should make sense though.

To make it easy for current developers of CXF DOSGi to participate in
the new development I propose that we keep the barrier low when voting
for an aries committer if he is committer in CXF
and already involved in CXF DOSGi.

Please vote
   [  ] +1 Create Aries Remote Service Admin subproject
   [  ] -1 Do not

Here is my
+1

Christian




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] Release Apache Aries JPA Container 1.0.4 (2nd try)

[Sergey Beryozkin]

+1

Sergey
On 01/03/16 11:47, David Bosschaert wrote:

+1

David

On 1 March 2016 at 10:31, Guillaume Nodet  wrote:


I've staged another release candidate for the jpa-container-1.0.4 which
contains two bug fixes
   * ARIES-1487 : JPA waits forever on osgi:service/javax.sql.DataSource/(
osgi.jndi.service.name=jdbc/DataSource).
   * ARIES-1499 : Refreshing a persistent bundle leaves it in the grace
period blueprint state

Staging repo available at:
   https://repository.apache.org/content/repositories/orgapachearies-1060

Source tree


http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.jpa.container-1.0.4/

Please review and vote,

Guillaume Nodet

Re: [VOTE] Release Apache Aries JPA Container 1.0.4

[Sergey Beryozkin]

+1

Sergey
On 29/02/16 13:03, Christian Schneider wrote:

+1

Christian

On 29.02.2016 14:01, Guillaume Nodet wrote:

I've staged a release candidate for the jpa-container-1.0.3 which
contains
a single bug fixe for ARIES-1487 : JPA waits forever on
osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/DataSource).


Staging repo available at:
   https://repository.apache.org/content/repositories/orgapachearies-1058

Source tree

http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.jpa.container-1.0.4/


Please review and vote,

Guillaume Nodet

Re: [VOTE] blueprint-parser-1.4.0, org.apache.aries.blueprint.core-1.5.0,

[Sergey Beryozkin]

+1

Sergey
On 14/12/15 15:47, Christian Schneider wrote:

I've staged some releases for vote.


  blueprint-parser-1.4.0

Repository:
https://repository.apache.org/content/repositories/orgapachearies-1054

Release Notes
https://issues.apache.org/jira/browse/ARIES/fixforversion/12334350

** New Feature
 * [ARIES-1456] - Spring support


  blueprint-core-1.5.0

Repository:
https://repository.apache.org/content/repositories/orgapachearies-1055


Release Notes
https://issues.apache.org/jira/browse/ARIES/fixforversion/12334309

** Bug
 * [ARIES-1467] - Blueprint creates unnecessary prototype bean
instances
 * [ARIES-1477] - NPE in NamespaceHandlerRegistryImpl
 * [ARIES-1478] - Avoid possible IllegalStateException when
registering a service


  org.apache.aries.blueprint.spring-0.1.0
  org.apache.aries.blueprint.spring.extender-0.1.0

Repository:
https://repository.apache.org/content/repositories/orgapachearies-1056

Release Notes
https://issues.apache.org/jira/browse/ARIES/fixforversion/12334353
** New Feature
 * [ARIES-1456] - Spring support
 * [ARIES-1480] - Complete spring extender support

https://issues.apache.org/jira/browse/ARIES/fixforversion/12334351
** New Feature
 * [ARIES-1456] - Spring support

Please review and vote:
   [ ] +1 Release the above artifacts
   [ ] -1 Do not

Here is my +1

Cheers,
Christian




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

[jira] [Commented] (ARIES-1460) Using blueprint-noosgi, unable to resolve absolute schemas to their local resources

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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)

Re: [VOTE] Aries JPA 2.2.0

[Sergey Beryozkin]

+1
Sergey
On 22/09/15 12:49, Christian Schneider wrote:

I've staged a release for vote at:
https://repository.apache.org/content/repositories/orgapachearies-1038

Release Notes - Aries - Version jpa-2.2.0

** Bug
 * [ARIES-1372] - Avoid NPE in case of exception in preCall
 * [ARIES-1374] - EmSupplier is not unpublished when
EntityManagerFactory is unpublished
 * [ARIES-1385] - Create karaf feature for aries jpa
 * [ARIES-1386] - Use bnd file to describe OSGi config and use bnd
baselining
 * [ARIES-1393] - XAJpaTemplate calls EntityManager#joinTransaction
regardless of desired TransactionType
 * [ARIES-1401] - Damping Timeout for access to EntityManager in
blueprint too short
 * [ARIES-1402] - We are unable to build jpa for a 1.6 JVM due to
changes in the jpa-parent/pom
 * [ARIES-1403] - Namespace for jpa blueprint should be jpa/2.0.0
 * [ARIES-1409] - JPA compilation error when compiling against 1.6
jre/lib jars.
 * [ARIES-1412] - EmProxy needs to unwrap InvocationTargetException

** Improvement
 * [ARIES-1405] - Make sure bundle goes into graceperiod if services
needed for JPA are not present
 * [ARIES-1406] - Add karaf itests to test the examples

https://issues.apache.org/jira/browse/ARIES/fixforversion/12333252


Please review and vote:
   [ ] +1 Release the above artifacts
   [ ] -1 Do not

Here is my +1

Cheers,
Christian




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] Release Aries JMX 1.1.5

[Sergey Beryozkin]

+1

Sergey
On 26/08/15 12:54, David Bosschaert wrote:

Hi,

I'm calling a vote on Aries JMX 1.1.5.

The following bug was fixed:
ARIES-1365 ServiceState attribute notifications slow down
startup/shutdown time considerably

Following the new Aries release guidelines, this releases all JMX
components with version 1.1.5, so the release contains:

org.apache.aries.jmx.api version 1.1.5
org.apache.aries.jmx.blueprint.api version 1.1.5
org.apache.aries.jmx.blueprint.core version 1.1.5
org.apache.aries.jmx.blueprint version 1.1.5
org.apache.aries.jmx.core.whiteboard version 1.1.5
org.apache.aries.jmx.core version 1.1.5
org.apache.aries.jmx.parent version 1.1.5
org.apache.aries.jmx.whiteboard version 1.1.5
org.apache.aries.jmx version 1.1.5

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1037

Please vote:

  +1 Approve the release
  -1 Do not approve the release (please explain why)

This vote will be open for at least 72 hours.

Best regards,

David Bosschaert




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] transaction blueprint 1.1.1

[Sergey Beryozkin]

+1

Sergey

On 08/08/15 19:23, Christian Schneider wrote:

Because of a critical error I had to do another bugfix release.

I've staged a release for vote at:
https://repository.apache.org/content/repositories/orgapachearies-1036

*Release Notes - Aries - Version transaction-blueprint-1.1.1*

** Bug
 * [ARIES-1369] - Transaction is not rolled back if coordination has
failed


https://issues.apache.org/jira/browse/ARIES/fixforversion/12333243

Please review and vote:
   [ ] +1 Release the above artifacts
   [ ] -1 Do not

Here is my +1

Cheers,
Christian




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1

[Sergey Beryozkin]

+1
Sergey
On 06/08/15 13:35, Christian Schneider wrote:

+1
Christian

On 06.08.2015 13:46, dav...@apache.org wrote:

Hi all,

I'm calling a vote on the first release of the Aries Asynchronous OSGi
Services implementation. The release has number 1.0.1 as the previous
vote was cancelled.
This implements the OSGi Asynchronous Services specification (chapter
138) and the OSGi Promises specification (chapter 705) of the OSGi
Enterprise R6 specifications, which were released yesterday [1]

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1034

For details on getting started see
http://aries.apache.org/modules/async-svcs.html

Please vote:

  +1 Approve the release
  -1 Do not approve the release (please explain why)

This vote will be open for at least 72 hours.

Best regards,

David Bosschaert

[1] http://www.osgi.org/Download/Release6

Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.0

[Sergey Beryozkin]

+1
Sergey
On 03/07/15 12:55, dav...@apache.org wrote:

Here's my +1

David

On 3 July 2015 at 11:36,  dav...@apache.org wrote:

Hi all,

I'm calling a vote on the first release of the Aries Asynchronous OSGi
Services implementation. This implements the OSGi Asynchronous
Services specification (chapter 138) and the OSGi Promises
specification (chapter 705) of the upcoming OSGi Enterprise R6
specifications, which are available as proposed final draft [1].

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1031

For details on getting started see
http://aries.apache.org/modules/async-svcs.html
Kudos to Tim Ward for providing this implementation.

Please vote:

  +1 Approve the release
  -1 Do not approve the release (please explain why)

This vote will be open for at least 72 hours.

Best regards,

David Bosschaert

[1] http://www.osgi.org/Specifications/Drafts

Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases

[Sergey Beryozkin]

This vote passes with 4 binding +1s.

I'll promote the artifacts
Thanks all
Sergey
On 29/06/15 16:56, Sergey Beryozkin wrote:

Hi All

This is a vote to support the release of blueprint-parser-1.3.1,
blueprint-noosgi-1.1.1, blueprint-web 1.1.1.

The staging repository for blueprint-parser-1.3.1 is at

https://repository.apache.org/content/repositories/orgapachearies-1027

The staging repository for blueprint-noosgi-1.1.1 and
blueprint-web-1.1.1 is at

https://repository.apache.org/content/repositories/orgapachearies-1028

The following issues have been addressed:

https://issues.apache.org/jira/browse/ARIES-1322
https://issues.apache.org/jira/browse/ARIES-1323
https://issues.apache.org/jira/browse/ARIES-1334

A servlet-based deployment of Blueprint contexts with custom namespace
handlers will work better in non OSGI environments after the release.

The vote is open for the next 72 hours, here is my +1,

Thanks, Sergey

Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases

[Sergey Beryozkin]

Hi Tom

I think it is onlt the 2nd time I'm doing an Aries release, may be 3rd, 
the last time it was a new module, so only this time, when I looked at 
release few blueprint modules did I find myself about -Pdev, I saw the 
dev profile properties before but never thouyght about why one would use 
them until I checked the Aries Blueprint section.


I think it is reasonable to use -Pdev for a short period of time, though 
it s obviously the responsibility of the current release manager to 
ensure -Pdev works :-). I guess it's been relied upon in few cases before.


Perhaps it makes sense to have a dedicated dev discussion about various 
release strategies, the parent pom one, vs -Pdev, etc


Thanks, Sergey


On 01/07/15 13:25, Thomas Watson wrote:

I must confess that I did not know about this -Pdev option.  Is that only
needed when we are in this release limbo period?

Tom





From:   Sergey Beryozkin sberyoz...@gmail.com
To: dev@aries.apache.org
Date:   06/30/2015 04:24 PM
Subject:Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1,
blueprint-web-1.1.1 releases



Building with -Pdev is OK now, sorry I did not update all the properties
immediately. As a side note a number of other dev properties have been
out of sync...

Thanks, Sergey
On 30/06/15 21:41, Sergey Beryozkin wrote:

I was concerned myself, then I checked the Aries release instructions
and one option listed was to make sure the (dev) profile gets updated
which is what I did. However I only updated dev properties in the
released module poms - let me check the whole trunk

Sergey



On 30/06/15 20:15, Thomas Watson wrote:

Is the intent to leave trunk broken for building while the votes are
going
on?  Right now I can no longer build trunk because it complains about

not

finding the these soon to be released artifacts.

Tom





From:   David Bosschaert david.bosscha...@gmail.com
To: dev@aries.apache.org dev@aries.apache.org
Date:   06/30/2015 01:31 PM
Subject:Re: [VOTE] blueprint-parser-1.3.1,
blueprint-noosgi-1.1.1,
blueprint-web-1.1.1 releases



+1

David

On 29 June 2015 at 16:56, Sergey Beryozkin sberyoz...@gmail.com

wrote:

Hi All

This is a vote to support the release of blueprint-parser-1.3.1,
blueprint-noosgi-1.1.1, blueprint-web 1.1.1.

The staging repository for blueprint-parser-1.3.1 is at

https://repository.apache.org/content/repositories/orgapachearies-1027

The staging repository for blueprint-noosgi-1.1.1 and

blueprint-web-1.1.1 is

at

https://repository.apache.org/content/repositories/orgapachearies-1028

The following issues have been addressed:

https://issues.apache.org/jira/browse/ARIES-1322
https://issues.apache.org/jira/browse/ARIES-1323
https://issues.apache.org/jira/browse/ARIES-1334

A servlet-based deployment of Blueprint contexts with custom namespace
handlers will work better in non OSGI environments after the release.

The vote is open for the next 72 hours, here is my +1,

Thanks, Sergey

[jira] [Resolved] (ARIES-1323) Update blueprint-web ServletContextListener to optionally register NamespaceHandlers

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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)

Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases

[Sergey Beryozkin]

I was concerned myself, then I checked the Aries release instructions 
and one option listed was to make sure the (dev) profile gets updated 
which is what I did. However I only updated dev properties in the 
released module poms - let me check the whole trunk


Sergey



On 30/06/15 20:15, Thomas Watson wrote:

Is the intent to leave trunk broken for building while the votes are going
on?  Right now I can no longer build trunk because it complains about not
finding the these soon to be released artifacts.

Tom





From:   David Bosschaert david.bosscha...@gmail.com
To: dev@aries.apache.org dev@aries.apache.org
Date:   06/30/2015 01:31 PM
Subject:Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1,
blueprint-web-1.1.1 releases



+1

David

On 29 June 2015 at 16:56, Sergey Beryozkin sberyoz...@gmail.com wrote:

Hi All

This is a vote to support the release of blueprint-parser-1.3.1,
blueprint-noosgi-1.1.1, blueprint-web 1.1.1.

The staging repository for blueprint-parser-1.3.1 is at

https://repository.apache.org/content/repositories/orgapachearies-1027

The staging repository for blueprint-noosgi-1.1.1 and

blueprint-web-1.1.1 is

at

https://repository.apache.org/content/repositories/orgapachearies-1028

The following issues have been addressed:

https://issues.apache.org/jira/browse/ARIES-1322
https://issues.apache.org/jira/browse/ARIES-1323
https://issues.apache.org/jira/browse/ARIES-1334

A servlet-based deployment of Blueprint contexts with custom namespace
handlers will work better in non OSGI environments after the release.

The vote is open for the next 72 hours, here is my +1,

Thanks, Sergey








--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: Preparing releases for blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1

[Sergey Beryozkin]

On 29/06/15 14:02, Sergey Beryozkin wrote:

Hi All,

I've started working on releasing blueprint-parser-1.2.1 [1],
blueprint-web-1.1.1 [2] and blueprint-noosgi [3].

My apologies, *blueprint-parser-1.3.1*


The minor updates which I've referred to earlier on the dev list and
in the linked JIRAs are about making it simpler to reuse Blueprint
contexts which depend on custom NamespaceHandlers in No Osgi deployments.
[1] introduces Namespaces annotation that custom handlers may be
optionally annotated with, [2] has a blueprint-web context listener
checking for these annotations on the classpath, finally [3] has
SimpleNamespaceHandlerSet attempting to resolve relative schema URIs
(xsd:include) against the available URIs.
Changes are simple but can help with making Blueprint more
visible/accessible to non OSGI developers

Hope everyone is fine with the above, I'll send a VOTE message later on

Thanks, Sergey

[1] https://issues.apache.org/jira/browse/ARIES-1322
[2] https://issues.apache.org/jira/browse/ARIES-1323
[3] https://issues.apache.org/jira/browse/ARIES-1334




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Preparing releases for blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1

[Sergey Beryozkin]

Hi All,

I've started working on releasing blueprint-parser-1.2.1 [1], 
blueprint-web-1.1.1 [2] and blueprint-noosgi [3].


The minor updates which I've referred to earlier on the dev list and
in the linked JIRAs are about making it simpler to reuse Blueprint 
contexts which depend on custom NamespaceHandlers in No Osgi deployments.
[1] introduces Namespaces annotation that custom handlers may be 
optionally annotated with, [2] has a blueprint-web context listener 
checking for these annotations on the classpath, finally [3] has 
SimpleNamespaceHandlerSet attempting to resolve relative schema URIs 
(xsd:include) against the available URIs.
Changes are simple but can help with making Blueprint more 
visible/accessible to non OSGI developers


Hope everyone is fine with the above, I'll send a VOTE message later on

Thanks, Sergey

[1] https://issues.apache.org/jira/browse/ARIES-1322
[2] https://issues.apache.org/jira/browse/ARIES-1323
[3] https://issues.apache.org/jira/browse/ARIES-1334

[jira] [Updated] (ARIES-1322) Introduce Namespaces annotation

[Sergey Beryozkin (JIRA)]

 [ 
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)

[VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases

[Sergey Beryozkin]

Hi All

This is a vote to support the release of blueprint-parser-1.3.1, 
blueprint-noosgi-1.1.1, blueprint-web 1.1.1.


The staging repository for blueprint-parser-1.3.1 is at

https://repository.apache.org/content/repositories/orgapachearies-1027

The staging repository for blueprint-noosgi-1.1.1 and 
blueprint-web-1.1.1 is at


https://repository.apache.org/content/repositories/orgapachearies-1028

The following issues have been addressed:

https://issues.apache.org/jira/browse/ARIES-1322
https://issues.apache.org/jira/browse/ARIES-1323
https://issues.apache.org/jira/browse/ARIES-1334

A servlet-based deployment of Blueprint contexts with custom namespace 
handlers will work better in non OSGI environments after the release.


The vote is open for the next 72 hours, here is my +1,

Thanks, Sergey

Re: [VOTE] Release Aries subsystem-api, subsystem-core and subsystem-bundle 2.0.1

[Sergey Beryozkin]

+1

Sergey
On 24/06/15 12:15, dav...@apache.org wrote:

Hi,

I'm calling a vote on the following Aries Subsystem modules:

subsystem-api 2.0.1
subsystem-core 2.0.1
subsystem-bundle 2.0.1

The main new feature of this release is compliance with the OSGi R6
Enterprise Subsystems specification (currently under vote, available
as proposed final draft: http://www.osgi.org/Specifications/Drafts).

Additionally the following bug was fixed:
ARIES-1307 - mandatory matching directive on exported packages cause
all importers to fail

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1026

More information about Aries Subsystems:
http://aries.apache.org/modules/subsystems.html

Please vote:

  +1 Approve the release
  -1 Do not approve the release (please explain why)

This vote will be open for at least 72 hours.

Best regards,

David Bosschaert




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

[jira] [Updated] (ARIES-1323) Update blueprint-web ServletContextListener to optionally register NamespaceHandlers

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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)

Re: Namespaces annotation in blueprint-parser

[Sergey Beryozkin]

Did one more update to a blueprint-web listener - it also check for 
META-INF/blueprint.handlers.
blueprint.handlers is a more effective way of listing the handlers 
compared to a similar Spring alternative involving two files due to 
Blueprint NamespaceHandler ability to pull a resource based on a schema 
URI plus the recently introduced Namespaces annotation that the handlers 
can be optionally annotated with...


Exploring a servlet container initializer is still an option but I guess 
we have quite a good coverage now for supporting Blueprint handlers in 
no osgi contexts


Sergey
On 18/05/15 17:46, Sergey Beryozkin wrote:

See r1680054 (same as in the patch),

any concerns - let me know please; hope this little feature would be of
interest

Sergey

On 18/05/15 17:09, Sergey Beryozkin wrote:

See a patch to
https://issues.apache.org/jira/browse/ARIES-1323

The description of ARIES-1323 shows the example.

I've updated blueprint-web BlueprintContextListener to load the handlers
itself if a contextual property is available. This is not an ultimate
solution but makes it much simpler to continue experimenting with
blueprint-web + blueprint-noosgi. As I said, the servlet initializer
using the auto-discovered handles can also be created at a later stage.

Perhaps the only possible concern is that I've changed a signature in a
protected BlueprintContextListener method, from

protected NamespaceHandlerSet getNamespaceHandlerSet(ClassLoader tccl)
to
protected NamespaceHandlerSet getNamespaceHandlerSet(ServletContext
servletContext, ClassLoader tccl);

as the default implementation needs a reference to ServletContext.
I've added the previous signature so I honestly do not expect anyone has
already tried overriding it and I guess it is better to do it right
later rather than never, but I can easily update
BlueprintContextListener to keep that original signature if someone feel
strongly about getting it changed

Thanks, Sergey

On 18/05/15 16:30, Sergey Beryozkin wrote:

Hi

See in revision 1680044.
Going to update the list shortly about the minor updates to
blueprint-web which utilize a new Namespaces annotation

Thanks, Sergey
On 18/05/15 14:09, Sergey Beryozkin wrote:

Hi All,

We've been experimenting recently with registering custom namespace
handlers manually in a non-OSGI environment, with blueprint-web and
blueprint-noosgi components.
It works quite well but as soon as it started working it became obvious
it can be tricky for users to do the manual registration, and it would
be good to have some basic automation support around it.

At the moment Aries NamespaceHandler does have a way to tell what
namespaces it supports. I opened [1] to have a new annotation added for
namespace handler implementations optionally advertise the supported
namespaces.

I've updated a Blueprint Web listener locally that checks a context
property listing the required handler classes only, and the CXF test
that depends on the local updated snapshot is now looking very neat.

The other possible enhancement going forward, once Namespaces is in
blueprint-parsers, would be to ship an optional
ServletContainerInitializer.

But the 1st step is to get the annotation shipped. Hope the above and
the comments at [1] makes sense

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1322










--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: Namespaces annotation in blueprint-parser

[Sergey Beryozkin]

Hi

See in revision 1680044.
Going to update the list shortly about the minor updates to 
blueprint-web which utilize a new Namespaces annotation


Thanks, Sergey
On 18/05/15 14:09, Sergey Beryozkin wrote:

Hi All,

We've been experimenting recently with registering custom namespace
handlers manually in a non-OSGI environment, with blueprint-web and
blueprint-noosgi components.
It works quite well but as soon as it started working it became obvious
it can be tricky for users to do the manual registration, and it would
be good to have some basic automation support around it.

At the moment Aries NamespaceHandler does have a way to tell what
namespaces it supports. I opened [1] to have a new annotation added for
namespace handler implementations optionally advertise the supported
namespaces.

I've updated a Blueprint Web listener locally that checks a context
property listing the required handler classes only, and the CXF test
that depends on the local updated snapshot is now looking very neat.

The other possible enhancement going forward, once Namespaces is in
blueprint-parsers, would be to ship an optional
ServletContainerInitializer.

But the 1st step is to get the annotation shipped. Hope the above and
the comments at [1] makes sense

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1322

[jira] [Created] (ARIES-1322) Introduce Namespaces annotation

[Sergey Beryozkin (JIRA)]

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)

Namespaces annotation in blueprint-parser

[Sergey Beryozkin]

Hi All,

We've been experimenting recently with registering custom namespace 
handlers manually in a non-OSGI environment, with blueprint-web and 
blueprint-noosgi components.
It works quite well but as soon as it started working it became obvious 
it can be tricky for users to do the manual registration, and it would 
be good to have some basic automation support around it.


At the moment Aries NamespaceHandler does have a way to tell what 
namespaces it supports. I opened [1] to have a new annotation added for 
namespace handler implementations optionally advertise the supported 
namespaces.


I've updated a Blueprint Web listener locally that checks a context 
property listing the required handler classes only, and the CXF test 
that depends on the local updated snapshot is now looking very neat.


The other possible enhancement going forward, once Namespaces is in 
blueprint-parsers, would be to ship an optional ServletContainerInitializer.


But the 1st step is to get the annotation shipped. Hope the above and 
the comments at [1] makes sense


Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1322

[jira] [Commented] (ARIES-1322) Introduce Namespaces annotation

[Sergey Beryozkin (JIRA)]

[ 
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)

Re: Namespaces annotation in blueprint-parser

[Sergey Beryozkin]

See a patch to
https://issues.apache.org/jira/browse/ARIES-1323

The description of ARIES-1323 shows the example.

I've updated blueprint-web BlueprintContextListener to load the handlers 
itself if a contextual property is available. This is not an ultimate 
solution but makes it much simpler to continue experimenting with 
blueprint-web + blueprint-noosgi. As I said, the servlet initializer 
using the auto-discovered handles can also be created at a later stage.


Perhaps the only possible concern is that I've changed a signature in a 
protected BlueprintContextListener method, from


protected NamespaceHandlerSet getNamespaceHandlerSet(ClassLoader tccl)
to
protected NamespaceHandlerSet getNamespaceHandlerSet(ServletContext 
servletContext, ClassLoader tccl);


as the default implementation needs a reference to ServletContext.
I've added the previous signature so I honestly do not expect anyone has 
already tried overriding it and I guess it is better to do it right 
later rather than never, but I can easily update 
BlueprintContextListener to keep that original signature if someone feel 
strongly about getting it changed


Thanks, Sergey

On 18/05/15 16:30, Sergey Beryozkin wrote:

Hi

See in revision 1680044.
Going to update the list shortly about the minor updates to
blueprint-web which utilize a new Namespaces annotation

Thanks, Sergey
On 18/05/15 14:09, Sergey Beryozkin wrote:

Hi All,

We've been experimenting recently with registering custom namespace
handlers manually in a non-OSGI environment, with blueprint-web and
blueprint-noosgi components.
It works quite well but as soon as it started working it became obvious
it can be tricky for users to do the manual registration, and it would
be good to have some basic automation support around it.

At the moment Aries NamespaceHandler does have a way to tell what
namespaces it supports. I opened [1] to have a new annotation added for
namespace handler implementations optionally advertise the supported
namespaces.

I've updated a Blueprint Web listener locally that checks a context
property listing the required handler classes only, and the CXF test
that depends on the local updated snapshot is now looking very neat.

The other possible enhancement going forward, once Namespaces is in
blueprint-parsers, would be to ship an optional
ServletContainerInitializer.

But the 1st step is to get the annotation shipped. Hope the above and
the comments at [1] makes sense

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1322

[jira] [Updated] (ARIES-1323) Update blueprint-web ServletContextListener to register NamespaceHandlers if a blueprintNamespaceHandlers property is set

[Sergey Beryozkin (JIRA)]

 [ 
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 (JIRA)]

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)

Re: Namespaces annotation in blueprint-parser

[Sergey Beryozkin]

See r1680054 (same as in the patch),

any concerns - let me know please; hope this little feature would be of 
interest


Sergey

On 18/05/15 17:09, Sergey Beryozkin wrote:

See a patch to
https://issues.apache.org/jira/browse/ARIES-1323

The description of ARIES-1323 shows the example.

I've updated blueprint-web BlueprintContextListener to load the handlers
itself if a contextual property is available. This is not an ultimate
solution but makes it much simpler to continue experimenting with
blueprint-web + blueprint-noosgi. As I said, the servlet initializer
using the auto-discovered handles can also be created at a later stage.

Perhaps the only possible concern is that I've changed a signature in a
protected BlueprintContextListener method, from

protected NamespaceHandlerSet getNamespaceHandlerSet(ClassLoader tccl)
to
protected NamespaceHandlerSet getNamespaceHandlerSet(ServletContext
servletContext, ClassLoader tccl);

as the default implementation needs a reference to ServletContext.
I've added the previous signature so I honestly do not expect anyone has
already tried overriding it and I guess it is better to do it right
later rather than never, but I can easily update
BlueprintContextListener to keep that original signature if someone feel
strongly about getting it changed

Thanks, Sergey

On 18/05/15 16:30, Sergey Beryozkin wrote:

Hi

See in revision 1680044.
Going to update the list shortly about the minor updates to
blueprint-web which utilize a new Namespaces annotation

Thanks, Sergey
On 18/05/15 14:09, Sergey Beryozkin wrote:

Hi All,

We've been experimenting recently with registering custom namespace
handlers manually in a non-OSGI environment, with blueprint-web and
blueprint-noosgi components.
It works quite well but as soon as it started working it became obvious
it can be tricky for users to do the manual registration, and it would
be good to have some basic automation support around it.

At the moment Aries NamespaceHandler does have a way to tell what
namespaces it supports. I opened [1] to have a new annotation added for
namespace handler implementations optionally advertise the supported
namespaces.

I've updated a Blueprint Web listener locally that checks a context
property listing the required handler classes only, and the CXF test
that depends on the local updated snapshot is now looking very neat.

The other possible enhancement going forward, once Namespaces is in
blueprint-parsers, would be to ship an optional
ServletContainerInitializer.

But the 1st step is to get the annotation shipped. Hope the above and
the comments at [1] makes sense

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1322







--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: [VOTE] Release aries-transaction-jdbc-2.1.1

[Sergey Beryozkin]

+1

Sergey
On 03/03/15 12:18, Guillaume Nodet wrote:

I've uploaded a release candidate for aries-transaction-jdbc-2.1.1 at
https://repository.apache.org/content/repositories/orgapachearies-1018

Tag:

http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.jdbc-2.1.1/

Please review and vote

Cheers,
Guillaume Nodet

[jira] [Resolved] (ARIES-1300) NoOsgi BlueprintContextImpl should accept custom namespace handler sets

[Sergey Beryozkin (JIRA)]

 [ 
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)

Re: Release blueprint-nosgi....

[Sergey Beryozkin]

I've been planning to do some basic modifications around

https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L85

as we've had a requirement to get (CXF) blueprint declarations supported 
in Tomcat and it is impossible right now to register custom namespace 
handlers.


Let me just make sure BlueprintContainerImpl can use a custom handler 
set for a start. Will work on it now


Thanks, Sergey

I've been planning to do some update
On 23/02/15 21:36, Christian Schneider wrote:

Maybe we can release the fixed blueprint-maven-plugin. Lets chat about
that tomorrow.

Christian

Am 23.02.2015 um 20:59 schrieb Daniel Kulp:

I’m planning to do a release of blueprint-noosgi tomorrow.   It
contains some fixes and enhancements that will allow it to be more
usable for some unit tests I’ve written for Geronimo-xbean.

Any additions/objections/etc… please let me know ASAP!

Thanks!







--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

[jira] [Created] (ARIES-1300) NoOsgi BlueprintContextImpl should accept custom namespace handler sets

[Sergey Beryozkin (JIRA)]

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

[Sergey Beryozkin (JIRA)]

 [ 
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)

Re: Release blueprint-nosgi....

[Sergey Beryozkin]

I've attached a basic patch at

https://issues.apache.org/jira/browse/ARIES-1300

It simply makes it possible to 'inject' a custom NamespaceHandlerSet by 
either extending BlueprintContextImpl or by passing it to its 
constructor, example, from blueprint-web/BlueprintContextListener.


This would let us experiment with providing a custom
BlueprintContextListener that would use SimpleNamespaceHandlerSet with 
few more namespace handlers added in.


I guess at a next stage a listener would scan for some class path 
resources (to be discussed), but for now it is a simple step forward IMHO.


Dan, can you please give me a favor and get blueprint-web released too 
if the team does not object to the patch ? I could apply it myself a bit 
later on


Thanks, Sergey


On 24/02/15 10:05, Sergey Beryozkin wrote:

I've been planning to do some basic modifications around

https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L85


as we've had a requirement to get (CXF) blueprint declarations supported
in Tomcat and it is impossible right now to register custom namespace
handlers.

Let me just make sure BlueprintContainerImpl can use a custom handler
set for a start. Will work on it now

Thanks, Sergey

I've been planning to do some update
On 23/02/15 21:36, Christian Schneider wrote:

Maybe we can release the fixed blueprint-maven-plugin. Lets chat about
that tomorrow.

Christian

Am 23.02.2015 um 20:59 schrieb Daniel Kulp:

I’m planning to do a release of blueprint-noosgi tomorrow.   It
contains some fixes and enhancements that will allow it to be more
usable for some unit tests I’ve written for Geronimo-xbean.

Any additions/objections/etc… please let me know ASAP!

Thanks!

Re: Release blueprint-nosgi....

[Sergey Beryozkin]

Hi All

I've just applied this change (r1662008 and r1662008 - forgot SVN does 
not pick up the sibling module changes :-)) - hope everyone is OK with it.


Sergey

On 24/02/15 12:29, Sergey Beryozkin wrote:

I've attached a basic patch at

https://issues.apache.org/jira/browse/ARIES-1300

It simply makes it possible to 'inject' a custom NamespaceHandlerSet by
either extending BlueprintContextImpl or by passing it to its
constructor, example, from blueprint-web/BlueprintContextListener.

This would let us experiment with providing a custom
BlueprintContextListener that would use SimpleNamespaceHandlerSet with
few more namespace handlers added in.

I guess at a next stage a listener would scan for some class path
resources (to be discussed), but for now it is a simple step forward IMHO.

Dan, can you please give me a favor and get blueprint-web released too
if the team does not object to the patch ? I could apply it myself a bit
later on

Thanks, Sergey


On 24/02/15 10:05, Sergey Beryozkin wrote:

I've been planning to do some basic modifications around

https://github.com/apache/aries/blob/trunk/blueprint/blueprint-noosgi/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L85



as we've had a requirement to get (CXF) blueprint declarations supported
in Tomcat and it is impossible right now to register custom namespace
handlers.

Let me just make sure BlueprintContainerImpl can use a custom handler
set for a start. Will work on it now

Thanks, Sergey

I've been planning to do some update
On 23/02/15 21:36, Christian Schneider wrote:

Maybe we can release the fixed blueprint-maven-plugin. Lets chat about
that tomorrow.

Christian

Am 23.02.2015 um 20:59 schrieb Daniel Kulp:

I’m planning to do a release of blueprint-noosgi tomorrow.   It
contains some fixes and enhancements that will allow it to be more
usable for some unit tests I’ve written for Geronimo-xbean.

Any additions/objections/etc… please let me know ASAP!

Thanks!

Re: [VOTE] Release some blueprint updates

[Sergey Beryozkin]

+1

Cheers, Sergey
On 19/02/15 16:56, Daniel Kulp wrote:

This is a vote to release:

blueprint-core-1.4.3
blueprint-cm-1.0.6
blueprint-maven-plugin 1.0.1

This is mostly just to release some of the bug fixes and updates we’ve been 
working on instead of letting them languish in the repo.   Release 
early/often/etc…   :-)


Staging areas:
https://repository.apache.org/content/repositories/orgapachearies-1015/
https://repository.apache.org/content/repositories/orgapachearies-1016/

Tags:
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.4.3/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.cm-1.0.6/

Here is my +1.

Re: [VOTE] Release aries blueprint-authz 1.0.0 and blueprint-maven-plugin 1.0.0

[Sergey Beryozkin]

+1

Sergey
On 10/11/14 16:44, Christian Schneider wrote:

As discussed previously, I staged releases for two new blueprint modules:

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1014

Content:
blueprint-maven-plugin 1.0.0
org.apache.aries.blueprint-authz 1.0.0

https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARIES%20AND%20fixVersion%20%3D%20%22blueprint-authz-1.0.0


https://issues.apache.org/jira/browse/ARIES/fixforversion/12328945

In sum there are only these two issues:
https://issues.apache.org/jira/browse/ARIES-1269
Add blueprint maven plugin

https://issues.apache.org/jira/browse/ARIES-1226
JAAS and JEE annotation based authorization


maven-blueprint-plugin
--
For the blueprint maven plugin there is an example project at:
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-cdi

The issue above also contains some more details.

The plugin creates blueprint.xml from JEE as well as from spring
annotations. The number of supported annotations is limited but enough
to create even mid size projects. I plan to add documentation about the
plugin to the aries website.

blueprint-authz

Is a blueprint extension that can be enabled using a simple
authz:enabled/ element in blueprint. The namespace is
http://aries.apache.org/xmlns/authorization/v1.0.0

When authorization is enabled then beans are scanned for @RolesAllowed
and @DenyAll annotations. If any are found then an interceptor is
installed that checks access to the beans using a JAAS context.

There is a test in blueprint itests that shows the usage:
http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-itests/src/test/java/org/apache/aries/blueprint/itests/authz/testbundle/impl/SecuredServiceImpl.java

http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-itests/src/test/java/org/apache/aries/blueprint/itests/authz/AuthorizationTest.java

http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-itests/src/test/resources/authz.xml



Please review and vote
[ ] +1 Release those bundles
[ ] -1 Do not

Here is my +1 (non binding)

Cheers,
Christian

Re: [VOTE] Release transaction / jndi / esa-maven-plugin bundles

[Sergey Beryozkin]

+1

Sergey
On 15/10/14 17:12, Guillaume Nodet wrote:

As discussed previously, I've staged a few releases:

Staging repository:
   https://repository.apache.org/content/repositories/orgapachearies-1012

Content:
   esa-maven-plugin 1.0.0
   jndi-core 1.0.2
   jndi-url 1.1.0
   transaction-manager 1.1.1
   transaction-blueprint 1.0.2
   transaction-jdbc 2.1.0
   transaction-jms 2.0.0

esa-maven-plugin 1.0.0 change log:
** Bug
 * [ARIES-1255] - esa-maven-plugin generates Subsystem-Content with
version range for composite subsystems

jndi-core 1.0.2 change log
** Bug
 * [ARIES-1085] - Rare NPE in jndi
ContextHelper.getInitialContextUsingBuilder()
 * [ARIES-1117] - JNDI Environment Augmentation can cause problems with
JNDI providers
 * [ARIES-1242] - Poor JNDI performance using Oracle DSML
 * [ARIES-1243] - NPE in
ObjectFactoryHelper.getObjectInstanceViaContextDotObjectFactories
** Improvement
 * [ARIES-822] - Add support for Context.OBJECT_FACTORIES to jndi.core

jndi-url 1.1.0 change log
** Bug
 * [ARIES-971] - ServiceHelper.CacheClearoutListener.add(BundleContext,
ServiceKey) causes NPE if system bundle is hidden
 * [ARIES-1095] - jndi-url problem when Bundles export services on
interfaces they cannot load
 * [ARIES-1117] - JNDI Environment Augmentation can cause problems with
JNDI providers
 * [ARIES-1170] - Jndi/Url activator should not print a stack trace to
stderr
** Improvement
 * [ARIES-1183] - Small refactorings

transaction-manager 1.1.1 change log
** Bug
 * [ARIES-1002] - Missing export-service directive for
PlatformTransactionManager
 * [ARIES-1266] - Aries Transaction Manager can't use spring 4.x
PlatformTransactionManager
** Improvement
 * [ARIES-1262] - Use generic capabilities and requirements for services

transaction-blueprint 1.0.2 change log
** Improvement
 * [ARIES-1262] - Use generic capabilities and requirements for services

transaction-jdbc 2.1.0 change log
** Bug
 * [ARIES-924] - Deadlock in transaction wrappers BundleActivator
 * [ARIES-1202] - Aries Transaction JDBC not runable on ServiceMix
 * [ARIES-1246] - ConnectionManagerFactory does not honor aries.xa.name
service property
 * [ARIES-1250] - Ability to manage non XA DataSource
 * [ARIES-1259] - Namespacehandler still identifies as 2.0 rather than
2.1
** Improvement
 * [ARIES-1150] - Add support for creating non xa DataSource
 * [ARIES-1262] - Use generic capabilities and requirements for services

transaction-jms 2.0.0 change log
** Bug
 * [ARIES-1158] - XAConnectionFactory not recoverable
** Improvement
 * [ARIES-1261] - Remove blueprint dependency from aries transaction jms
 * [ARIES-1262] - Use generic capabilities and requirements for services

Please review and vote
[ ] +1 Release those bundles
[ ] -1 Do not

Cheers,
Guillaume Nodet

Re: [VOTE] blueprint-cm 1.0.5

[Sergey Beryozkin]

+1

Cheers, Sergey
On 07/10/14 15:48, Daniel Kulp wrote:


There is a bug in blueprint-cm that is a critical blocker to getting a Karaf 
release out:
https://issues.apache.org/jira/browse/KARAF-3151
https://issues.apache.org/jira/browse/ARIES-1257
JB fixed it yesterday and I’d like to get the release done so they aren’t 
blocked by us.

The only change is that fix.

Staging repo:
https://repository.apache.org/content/repositories/orgapachearies-1011/

Tag:
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.cm-1.0.5/

Here is my +1

Re: [VOTE] Release Spi-Fly 1.0.1

[Sergey Beryozkin]

+1

Cheers, Sergey
On 09/07/14 15:17, Jean-Baptiste Onofré wrote:

+1 (non binding)

Regards
JB

On 07/09/2014 10:31 AM, Guillaume Nodet wrote:

I'm starting a vote to release the spi-fly 1.0.1 bundles:
org.apache.aries.spifly.core-internal
org.apache.aries.spifly.dynamic.bundle
org.apache.aries.spifly.static.bundle
org.apache.aries.spifly.static.tool
org.apache.aries.spifly.weaver-internal

Staging repository:

https://repository.apache.org/content/repositories/orgapachearies-1006/org/apache/aries/spifly/

Change log: Upgrade all modules to the released parent Change parent
version to 2.0.0-SNAPSHOT [ARIES-1192] Upgrade to maven-bundle-plugin
2.4.1-SNAPSHOT [ARIES-1185] SPI Fly does not work with Java 8 Define the
versioning plugin as an execution in the parent pom. It can thus be
removed
from ALL the other poms. Fix spi-fly tests spy fly build with java6,
maven
3.2.1 [ARIES-1006] Upgrade to the new parent pom and OSGi 4.3.1 Convert
file to use unix line delimiters. [ARIES-1156] SPI-Fly static tool
does not
work with Require-Capability bundles [ARIES-1156] SPI Fly fix syntax
errors
with static tool Manifest generation [SPI Fly] Fix for NPE. Additional
example that shows a single bundle being a provider and consumer at the
same time. Add Aries Versioning Plugin for the bundles in this project.

Please review and vote,

Cheers,
Guillaume

Re: [VOTE] Release Aries Proxy Api 1.0.1 and Impl 1.0.3

[Sergey Beryozkin]

+1 to this,

Thanks, Sergey




On 01/07/14 08:44, Guillaume Nodet wrote:

Jira is not really helpful for that.
Here's a list extract from the svn log

API
===
 Change parent version to 2.0.0-SNAPSHOT
 More updates to latest version plugin
 [ARIES-1006] Upgrade to the new parent pom in proxy modules
 [aries-1006] Point poms back to version 1.0.0 of java5-parent.
 ARIES-1006 : Get Aries building on JDK 7 - fixes for Aries proxy
 ARIES-1006 : Get Aries building on JDK 7 - fixes for Aries proxy
 Update to the release version of the plugin
 ARIES-979: Integrate semantic versioning maven plugin in aries modules

Core

[ARIES-1220] Fix required and provided services for ProxyManager
Change parent version to 2.0.0-SNAPSHOT
  Fix proxy-impl test compilation
Aries-1217: ProxySubclassGenerator doesn't compile
[ARIES-1216] Error when creating proxies with an invisible super class in
the hierarchy
  Extend the version range of the slf4j import and set it optional in proxy
Use asm-debug-all for easier debugging
  More updates to latest version plugin
Get Java6 builds working again
Fix proxy integration tests
  [ARIES-1006] Upgrade to the new parent pom in proxy modules
Remove debug qualifier
[ARIES-1186] Support Java 8 with ASM 5.0.2 in Aries Proxy
  Update version for checker




2014-07-01 9:25 GMT+02:00 David Bosschaert david.bosscha...@gmail.com:


Hi Guillaume,

I'm kinda missing in this vote (and in the others in the set) what has
been changed since the last release.

Also, I was wondering whether we should be using the odd-even release
number scheme that is in use in the Felix project. That ensures that
version ordering between snapshots and release ordering is always
right regardless of the context...

Thanks,

David

On 30 June 2014 19:11, Guillaume Nodet gno...@apache.org wrote:

Second release vote ...
This one contains the proxy api and impl.
Staging repo at


https://repository.apache.org/content/repositories/orgapachearies-1003


[ ] +1 Release Aries Proxy 1.0.1 and Impl 1.0.3
[ ] -1 Do not

Cheers,
Guillaume Nodet

Re: [VOTE] Release JMX Api 1.1.1 and Core 1.1.2

[Sergey Beryozkin]

+1

Thanks, Sergey
On 30/06/14 19:14, Guillaume Nodet wrote:

4th set ...
This release contains:
   * JMX Api 1.1.1
   * JMX Core 1.1.2

[ ] +1 Release those 2 bundles
[ ] -1 Do not

Cheers,
Guillaume Nodet

Re: [VOTE] Versioning plugin 0.3.0

[Sergey Beryozkin]

+1

Cheers, Sergey
On 11/06/14 18:00, Daniel Kulp wrote:


This is a vote to release 0.3.0 of the versioning plugin.

The two major changes for this version are:

1) Update to support Java 8
2) Update to provide “skip” functionality/option and only to compare bundle 
package types so the plugin can be easily added to the parent pom.


Staging are:
https://repository.apache.org/content/repositories/orgapachearies-1001/

Tags:
https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning.checker-0.3.0/
https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning.plugin-0.3.0/

Here is my +1

Re: [VOTE] Versioning plugin 0.2.0

[Sergey Beryozkin]

+1

Cheers, Sergey
On 19/05/14 18:15, Daniel Kulp wrote:


This is a vote to release 0.2.0 of the versioning plugin.

The main change for this plugin is to support both Maven 3.0.x and 3.1.x/3.2.x 
by flipping from using Aether directly to using the Maven provided API’s.   
When released and rolled out throughout the rest of the build, we should 
hopefully be able to build Aries with a more modern version of Maven.


Tag:
https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning-0.2.0/

Staging repo:
https://repository.apache.org/content/repositories/orgapachearies-1000/org/apache/aries/versioning/

[jira] [Commented] (ARIES-1160) Hibernate JPA: EntityManagerFactoryManager failed to create EntityManagerFactories by Bundle.RESOLVED

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

[ 
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)

Re: Vote to release bluepprint-web-osgi 1.0.1

[Sergey Beryozkin]

Hi Again,

We've had 3 binding and 4 non-binding +1 votes, and no objections.
I'm going to promote it shortly.

Thanks all,
Cheers, Sergey

On 05/11/13 11:29, Sergey Beryozkin wrote:

Hi All,

I'd like to start a vote to get blueprint-web-osgi 1.0.1 released.

This release fixes the issue at [1] to do with blueprint-web-osgi 1.0.0
depending on blueprint-core 1.3.0 and having a related import version
range with the lower bound of 1.3, while blueprint-core 1.3.0 actually
ended up exporting with the version 1.2.

The mismatch between the versions of blueprint-core itself and its
exported packages is not ideal, see [2], though blueprint-core 1.3.0 was
'correct' in preserving the earlier pattern.

As such, this blueprint-web-osgi release is about making sure it
actually works with the released blueprint-core 1.3.0. Addressing [2]
may take the time and some consideration and can be fixed independently.

The staging repository is at [3], the vote will be open for at least 72
hours, and here is my +1.

Thank you
Sergey



[1] https://issues.apache.org/jira/browse/ARIES-1131
[2] https://issues.apache.org/jira/browse/ARIES-1132

[3] https://repository.apache.org/content/repositories/orgapachearies-079/

Vote to release bluepprint-web-osgi 1.0.1

[Sergey Beryozkin]

Hi All,

I'd like to start a vote to get blueprint-web-osgi 1.0.1 released.

This release fixes the issue at [1] to do with blueprint-web-osgi 1.0.0 
depending on blueprint-core 1.3.0 and having a related import version 
range with the lower bound of 1.3, while blueprint-core 1.3.0 actually 
ended up exporting with the version 1.2.


The mismatch between the versions of blueprint-core itself and its 
exported packages is not ideal, see [2], though blueprint-core 1.3.0 was 
'correct' in preserving the earlier pattern.


As such, this blueprint-web-osgi release is about making sure it 
actually works with the released blueprint-core 1.3.0. Addressing [2] 
may take the time and some consideration and can be fixed independently.


The staging repository is at [3], the vote will be open for at least 72 
hours, and here is my +1.


Thank you
Sergey



[1] https://issues.apache.org/jira/browse/ARIES-1131
[2] https://issues.apache.org/jira/browse/ARIES-1132

[3] https://repository.apache.org/content/repositories/orgapachearies-079/

[jira] [Commented] (ARIES-1131) Extend blueprint.service import version range in blueprint.webosgi bundle

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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

[Sergey Beryozkin (JIRA)]

 [ 
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)

GPG and Maven release plugin issue

[Sergey Beryozkin]

Hi All,

I'm trying to do a blueprint-web-osgi 1.0.1 release to address a 
blueprint-core related Import-Package issue.


I'm getting stuck while doing release:prepare, it hangs at

[INFO] [INFO] --- maven-gpg-plugin:1.0-alpha-4:sign (default) @ 
org.apache.aries.blueprint.webosgi ---



Apparently it is a well-known issue, and while I did not see it before, 
it is happening to me now,


The workaround is documented at [1] and is about explicitly configuring 
a maven release plugin and adding


mavenExecutorIdforked-path/mavenExecutorId

to its configuration.

Would you be OK with me adding this kind of configuration to 
parent/pom.xml ?


Or I can update only blueprint-web-osgi/pom.xml just to get past this 
issue.


Comments are welcome
Thanks, Sergey


[1] 
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven 

Re: [VOTE] Aries proxy-impl/blueprint-core/blueprint-cm/blueprint-web-osgi

[Sergey Beryozkin]

+1

Thanks, Sergey

On 22/10/13 17:20, Daniel Kulp wrote:

This is a vote to release some more artifacts to get some more fixes and 
enhancements available for Karaf 3.x:

proxy-impl  1.0.2:
Fixes a bunch of problems if the WovenClass passed in has a null BundleWiring.  
The resulting NPE can result in bundles not starting.

blueprint-core/blueprint-webosgi:
Fixes a potential problem of looking up the container and such resulting in an 
not-found exception during refresh
Adds support for the webosgi module

blueprint-cm:
Expands the import range from [1.0,1.3) to [1.0,2.0) to support enhancements to 
the blueprint-core without needed to release this every time in the future.


Staging area:
https://repository.apache.org/content/repositories/orgapachearies-022/

Tags:
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.proxy.impl-1.0.2/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.3.0/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.cm-1.0.3/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.webosgi-1.0.0/


Here is my +1.   Vote will be open for at least 72 hours.

Re: New Blueprint Web OSGI module and BlueprintExtenderService

[Sergey Beryozkin]

Hi All,

I've committed an initial code for addressing [1], please review it 
again now that it is in the code, if you have any additional comments 
then let me know please, also, if someone would like to tune JavaDocs a 
bit - please go ahead.


Thanks, Sergey

[1] https://issues.apache.org/jira/browse/ARIES-1121

On 08/10/13 14:24, David Bosschaert wrote:

Thanks Sergey,
sounds reasonable to me...

Cheers,

David

On 8 October 2013 11:01, Sergey Beryozkin sberyoz...@gmail.com wrote:

Hi David

Thanks for the feedback,

On 08/10/13 09:34, David Bosschaert wrote:


Hi Sergey,

I think I understand what you are proposing for [1]. A programmatic
API to create Blueprint Containers. Once you have such container, can
you then also programmatically add beans etc? In other words will you
be able to do via code all the things that you would normally do in a
blueprint.xml?



Not really. This enhancement is simply about making it possible to use
BlueprintExtender to get BlueprintContainer this Extender may've already
created for a given bundle or request Extender to create a new container if
the bundle metadata has no Blueprint-specific instructions or annotations,
example, when a Blueprint context path is set as ServletContext parameter.

Once the consumer gets BlueprintContainer it will get from it a component it
needs.




Regarding [2] I'm not seeing the full picture here yet. One thing that
is being worked on in the OSGi Alliance is whiteboard pattern support
for the HTTP Service, which means that you can register Servlets in
the service registry to make them part of your webapp. This should
make it a lot easier as well to create webapps using blueprint. I
believe that Apache Felix has already an implementation of such a HTTP
Service... But then, maybe your are trying to do something completely
different...



I'd like to do a webbundle: protocol deployment where a bundle containing
only WEB-INF/web.xml and Blueprint contexts is deployed (with no embedded
libs).

AFAIK it is supported by Pax-Web, possibly by other stacks too. Internally
Pax-Web registers a custom servlet referenced in web.xml with HttpService
under a context path specified via Web-ContextPath bundle instruction.

We like this option because it lets us support the same light-weight bundle
deployment we work with but still get a War-aware/full ServletContext.
AFAIK, the default ServletContext created via the white-board pattern will
be limited in its capabilities, example it won't support Servlet
RequestDispatcher, etc.

Right now I can do it with Spring DM but not with Blueprint. The new
blueprint-web-osgi is very light-weight and will simply adds another option
for utilizing Blueptint contexts.

FYI, I've linked an Apache CXF issue to Aries-1122, please have a look there
at CXFBlueprintServlet code and a custom web.xml.
To be honest I can even push the code which I hope will actually live in
blueprint-web-osgi to CXFBlueprintServlet, it will work just fine, I'd still
need Aries-1121 done.

However blueprint-web-osgi does some boiler-plate code to do with getting
the right BlueprintContainer, so IMHO it may be of help to other Aries users

Thanks,
Sergey




Cheers,

David

[3] https://github.com/osgi/design/tree/master/rfcs/rfc0189

On 7 October 2013 17:19, Sergey Beryozkin sberyoz...@gmail.com wrote:


Hi All,

I did some initial work on enhancing BlueprintExtender to make it easier
to
deal with BlueprintContainers externally [1] and introducing a new
blueprint-web-osgi module [2].

I've commented at [1]  [2] so hopefully the reason behind these minor
but
also IMHO useful enhancements is clear.
We'd like to be able to use Blueprint contexts within light-weight war
bundles, examples, in those installed via a webbundle: protocol and
drive
the creation of web context paths from custom servlets; I believe it can
be
of general use for OSGI Blueprint developers too.

Comments to the proposed patches are welcome

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1121
[2] https://issues.apache.org/jira/browse/ARIES-1122






--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: New Blueprint Web OSGI module and BlueprintExtenderService

[Sergey Beryozkin]

Hi Again

The other thing I've been thinking a lot about is whether it makes sense 
to wait with introducing blueprint-web-osgi [2] to the trunk or wait 
till some later time.


As I said earlier and as you can see from the patch it is a very light 
weight module; what it does now I can easily do in meantime in Apache 
CXF Blueprint servlet (or indeed one can do the same in any other custom 
servlet which would need such a feature).


That said, given that Dan is now working on other few releases, I wonder 
if it is an opportunity to miss. For example, adding it now would let 
Karaf 3.0 introduce a blueprint-web (osgi) feature, it will all work out 
quite neatly really.


Basically, I'm for merging it tomorrow morning, please review that patch 
again, hope you all are OK with it. It's already been up for the review 
for the last 2 weeks.


I'd also like the team to appreciate that I'm not trying to push this 
feature too fast; I honestly think it is a simple yet useful 
enhancement, but I'm also going to some extra length to justify it given 
that I've not been active on this list at all


Thanks, Sergey

[2] https://issues.apache.org/jira/browse/ARIES-1122


On 21/10/13 17:13, Sergey Beryozkin wrote:

Hi All,

I've committed an initial code for addressing [1], please review it
again now that it is in the code, if you have any additional comments
then let me know please, also, if someone would like to tune JavaDocs a
bit - please go ahead.

Thanks, Sergey

[1] https://issues.apache.org/jira/browse/ARIES-1121

On 08/10/13 14:24, David Bosschaert wrote:

Thanks Sergey,
sounds reasonable to me...

Cheers,

David

On 8 October 2013 11:01, Sergey Beryozkin sberyoz...@gmail.com wrote:

Hi David

Thanks for the feedback,

On 08/10/13 09:34, David Bosschaert wrote:


Hi Sergey,

I think I understand what you are proposing for [1]. A programmatic
API to create Blueprint Containers. Once you have such container, can
you then also programmatically add beans etc? In other words will you
be able to do via code all the things that you would normally do in a
blueprint.xml?



Not really. This enhancement is simply about making it possible to use
BlueprintExtender to get BlueprintContainer this Extender may've already
created for a given bundle or request Extender to create a new
container if
the bundle metadata has no Blueprint-specific instructions or
annotations,
example, when a Blueprint context path is set as ServletContext
parameter.

Once the consumer gets BlueprintContainer it will get from it a
component it
needs.




Regarding [2] I'm not seeing the full picture here yet. One thing that
is being worked on in the OSGi Alliance is whiteboard pattern support
for the HTTP Service, which means that you can register Servlets in
the service registry to make them part of your webapp. This should
make it a lot easier as well to create webapps using blueprint. I
believe that Apache Felix has already an implementation of such a HTTP
Service... But then, maybe your are trying to do something completely
different...



I'd like to do a webbundle: protocol deployment where a bundle
containing
only WEB-INF/web.xml and Blueprint contexts is deployed (with no
embedded
libs).

AFAIK it is supported by Pax-Web, possibly by other stacks too.
Internally
Pax-Web registers a custom servlet referenced in web.xml with
HttpService
under a context path specified via Web-ContextPath bundle instruction.

We like this option because it lets us support the same light-weight
bundle
deployment we work with but still get a War-aware/full ServletContext.
AFAIK, the default ServletContext created via the white-board pattern
will
be limited in its capabilities, example it won't support Servlet
RequestDispatcher, etc.

Right now I can do it with Spring DM but not with Blueprint. The new
blueprint-web-osgi is very light-weight and will simply adds another
option
for utilizing Blueptint contexts.

FYI, I've linked an Apache CXF issue to Aries-1122, please have a
look there
at CXFBlueprintServlet code and a custom web.xml.
To be honest I can even push the code which I hope will actually live in
blueprint-web-osgi to CXFBlueprintServlet, it will work just fine,
I'd still
need Aries-1121 done.

However blueprint-web-osgi does some boiler-plate code to do with
getting
the right BlueprintContainer, so IMHO it may be of help to other
Aries users

Thanks,
Sergey




Cheers,

David

[3] https://github.com/osgi/design/tree/master/rfcs/rfc0189

On 7 October 2013 17:19, Sergey Beryozkin sberyoz...@gmail.com wrote:


Hi All,

I did some initial work on enhancing BlueprintExtender to make it
easier
to
deal with BlueprintContainers externally [1] and introducing a new
blueprint-web-osgi module [2].

I've commented at [1]  [2] so hopefully the reason behind these minor
but
also IMHO useful enhancements is clear.
We'd like to be able to use Blueprint contexts within light-weight war
bundles, examples, in those installed via a webbundle: protocol and
drive

Re: Couple more releases early next week….

[Sergey Beryozkin]

Hi Dan, All,
On 18/10/13 20:34, Daniel Kulp wrote:


I'm planning to do a proxy-impl release early next week to get a fix for a 
serious startup problem out.I'll likely do another blueprint-core release 
at the same time to get the single fix I did there in as well. If anyone 
has any more fixes for either of them, please get them in ASAP!



I was thinking of merging the patch I attached to

https://issues.apache.org/jira/browse/ARIES-1121

(for the review) next week; I've tried to clarify as much as possible 
the idea behind it, only David has commented so far, but I guess no 
objections exist.


I can wait till you get the blueprint-core released, as ARIES-1121 is 
not a bug fix; at the same time it is pretty simple and really neutral 
enhancement...


Thanks, Sergey

[jira] [Commented] (ARIES-1121) Introduce BlueprintExtenderService to simplify managing BlueprintContainers from the code

[Sergey Beryozkin (JIRA)]

[ 
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)

Re: New Blueprint Web OSGI module and BlueprintExtenderService

[Sergey Beryozkin]

Hi David

Thanks for the feedback,
On 08/10/13 09:34, David Bosschaert wrote:


Hi Sergey,

I think I understand what you are proposing for [1]. A programmatic
API to create Blueprint Containers. Once you have such container, can
you then also programmatically add beans etc? In other words will you
be able to do via code all the things that you would normally do in a
blueprint.xml?


Not really. This enhancement is simply about making it possible to use 
BlueprintExtender to get BlueprintContainer this Extender may've already 
created for a given bundle or request Extender to create a new container 
if the bundle metadata has no Blueprint-specific instructions or 
annotations, example, when a Blueprint context path is set as 
ServletContext parameter.


Once the consumer gets BlueprintContainer it will get from it a 
component it needs.




Regarding [2] I'm not seeing the full picture here yet. One thing that
is being worked on in the OSGi Alliance is whiteboard pattern support
for the HTTP Service, which means that you can register Servlets in
the service registry to make them part of your webapp. This should
make it a lot easier as well to create webapps using blueprint. I
believe that Apache Felix has already an implementation of such a HTTP
Service... But then, maybe your are trying to do something completely
different...


I'd like to do a webbundle: protocol deployment where a bundle 
containing only WEB-INF/web.xml and Blueprint contexts is deployed (with 
no embedded libs).


AFAIK it is supported by Pax-Web, possibly by other stacks too. 
Internally Pax-Web registers a custom servlet referenced in web.xml with 
HttpService under a context path specified via Web-ContextPath bundle 
instruction.


We like this option because it lets us support the same light-weight 
bundle deployment we work with but still get a War-aware/full 
ServletContext. AFAIK, the default ServletContext created via the 
white-board pattern will be limited in its capabilities, example it 
won't support Servlet RequestDispatcher, etc.


Right now I can do it with Spring DM but not with Blueprint. The new 
blueprint-web-osgi is very light-weight and will simply adds another 
option for utilizing Blueptint contexts.


FYI, I've linked an Apache CXF issue to Aries-1122, please have a look 
there at CXFBlueprintServlet code and a custom web.xml.
To be honest I can even push the code which I hope will actually live in 
blueprint-web-osgi to CXFBlueprintServlet, it will work just fine, I'd 
still need Aries-1121 done.


However blueprint-web-osgi does some boiler-plate code to do with 
getting the right BlueprintContainer, so IMHO it may be of help to other 
Aries users


Thanks,
Sergey



Cheers,

David

[3] https://github.com/osgi/design/tree/master/rfcs/rfc0189

On 7 October 2013 17:19, Sergey Beryozkin sberyoz...@gmail.com wrote:

Hi All,

I did some initial work on enhancing BlueprintExtender to make it easier to
deal with BlueprintContainers externally [1] and introducing a new
blueprint-web-osgi module [2].

I've commented at [1]  [2] so hopefully the reason behind these minor but
also IMHO useful enhancements is clear.
We'd like to be able to use Blueprint contexts within light-weight war
bundles, examples, in those installed via a webbundle: protocol and drive
the creation of web context paths from custom servlets; I believe it can be
of general use for OSGI Blueprint developers too.

Comments to the proposed patches are welcome

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1121
[2] https://issues.apache.org/jira/browse/ARIES-1122

[jira] [Created] (ARIES-1121) Introduce BlueprintExtenderService to simplify managing BlueprintContainers from the code

[Sergey Beryozkin (JIRA)]

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 (JIRA)]

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

[Sergey Beryozkin (JIRA)]

[ 
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)

New Blueprint Web OSGI module and BlueprintExtenderService

[Sergey Beryozkin]

Hi All,

I did some initial work on enhancing BlueprintExtender to make it easier 
to deal with BlueprintContainers externally [1] and introducing a new 
blueprint-web-osgi module [2].


I've commented at [1]  [2] so hopefully the reason behind these minor 
but also IMHO useful enhancements is clear.
We'd like to be able to use Blueprint contexts within light-weight war 
bundles, examples, in those installed via a webbundle: protocol and 
drive the creation of web context paths from custom servlets; I believe 
it can be of general use for OSGI Blueprint developers too.


Comments to the proposed patches are welcome

Thanks, Sergey


[1] https://issues.apache.org/jira/browse/ARIES-1121
[2] https://issues.apache.org/jira/browse/ARIES-1122

Re: [VOTE] SPI-Fly 1.0.0

[Sergey Beryozkin]

Let me vote on this one,
+1

thanks, Sergey
On 13/02/13 17:28, Daniel Kulp wrote:


I still need one more binding vote for this…  anyone have some time to look?

Dan



On Feb 8, 2013, at 1:05 PM, Daniel Kulpdk...@apache.org  wrote:



This is a vote to release the 1.0.0 versions of all the spi-fly things.


Staging area:
https://repository.apache.org/content/repositories/orgapachearies-220/

Tags:
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.spifly.core-internal-1.0.0/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.spifly.dynamic.bundle-1.0.0/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.spifly.static.bundle-1.0.0/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.spifly.static.tool-1.0.0/
http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.spifly.weaver-internal-1.0.0/
http://svn.apache.org/repos/asf/aries/tags/spi-fly-examples-1.0.0/


Here is my +1

--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[jira] [Created] (ARIES-855) Blueprint should attempt to load static nested classes when the initial attempt to load a class has failed

[Sergey Beryozkin (JIRA)]

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

[Sergey Beryozkin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Beryozkin updated ARIES-855:
---

Attachment: aries855.txt

The proposed patch does a single recursion attempt only, given that no use 
cases for supporting the deeply nested static classes exists and also to make 
the delay in throwing the load exception very minimal.

During the single recursive call only the top level catch block will report an 
error log message, and a debug one in case of attempting a retry.

This can be extended to manage nested hierarchies if really needed


 Blueprint should attempt to load static nested classes when the initial 
 attempt to load a class has failed
 --

 Key: ARIES-855
 URL: https://issues.apache.org/jira/browse/ARIES-855
 Project: Aries
  Issue Type: Improvement
  Components: Blueprint
Reporter: Sergey Beryozkin
 Attachments: aries855.txt


 At the moment the Blueprint schema blocks the static nested class names, 
 example, trying to get SimpleBean#Nested:
 {code:java}
 public class SimpleBean {
   public static Nested {
   }
 }
 {code}
 referenced as SimpleBean#Nested in a blueprint context fails with the 
 validation error. 
 As proposed at the Osgi-dev by BJ H., the implementation should attempt to 
 load a nested class if the original load attempt fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Blueprint schema blocks nested static class names

[Sergey Beryozkin]

I've attached a simple patch to

https://issues.apache.org/jira/browse/ARIES-855

Let me know please if you think it can be committed now or expect a bit 
more work done on it.


Right now I'm thinking that retrying once only in case of the bean load 
failure is reasonable. Introducing a system property telling the catch 
block to fail immediately without a retry might make sense, but I was 
not sure it was really needed


Cheers, Sergey

On 14/05/12 11:57, Sergey Beryozkin wrote:

Hi All

I managed to click on the link leading to the subscription page :-) and
eventually forwarded the original post to the osgi-dev

Thanks, Sergey


On 11/05/12 13:49, David Bosschaert wrote:

Just for clarity, the mailing lists and bugzilla instance mentioned
before


[1] www.osgi.org/bugzilla
[2] http://www.osgi.org/MailLists/HomePage


are open to anyone. But yes, in order to post to the mailing list you
probably need to subscribe first.

Cheers,

David

On 11 May 2012 13:16, Jeremy Hugheshugh...@apache.org wrote:

Hi, in order to post, you'll need to subscribe to the list. Otherwise
you won't get any responses. Are you saying that you couldn't
subscribe either? For each list in the table there is the mailto: link
(middle column) and a link to subscribe page (left hand column).

HTH,
Jeremy

On 4 May 2012 16:10, Sergey Beryozkinsberyoz...@gmail.com wrote:

Hi Jeremy


Hi,

The blueprint.xsd is defined by the OSGi Alliance, so this would need
to be changed in the spec. The Blueprint spec doesn't mention inner
classes so there's nothing AFAICT in the spec that excludes the use of
them - so arguably you could open a bug at the OSGi Alliance [1]. It's
worth discussing first on the developers list [2].



I can not post to the

Re: Blueprint schema blocks nested static class names

[Sergey Beryozkin]

Hi All

I managed to click on the link leading to the subscription page :-) and 
eventually forwarded the original post to the osgi-dev


Thanks, Sergey


On 11/05/12 13:49, David Bosschaert wrote:

Just for clarity, the mailing lists and bugzilla instance mentioned before


[1] www.osgi.org/bugzilla
[2] http://www.osgi.org/MailLists/HomePage


are open to anyone. But yes, in order to post to the mailing list you
probably need to subscribe first.

Cheers,

David

On 11 May 2012 13:16, Jeremy Hugheshugh...@apache.org  wrote:

Hi, in order to post, you'll need to subscribe to the list. Otherwise
you won't get any responses. Are you saying that you couldn't
subscribe either? For each list in the table there is the mailto: link
(middle column) and a link to subscribe page (left hand column).

HTH,
Jeremy

On 4 May 2012 16:10, Sergey Beryozkinsberyoz...@gmail.com  wrote:

Hi Jeremy


Hi,

The blueprint.xsd is defined by the OSGi Alliance, so this would need
to be changed in the spec. The Blueprint spec doesn't mention inner
classes so there's nothing AFAICT in the spec that excludes the use of
them - so arguably you could open a bug at the OSGi Alliance [1]. It's
worth discussing first on the developers list [2].



I can not post to the

[jira] [Commented] (ARIES-847) Nullpointer exception in org.apache.aries.blueprint.container.BeanRecipe.destroy

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

[ 
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

[Sergey Beryozkin (JIRA)]

[ 
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

Re: Blueprint schema blocks nested static class names

[Sergey Beryozkin]

Hi Jeremy

 Hi,

 The blueprint.xsd is defined by the OSGi Alliance, so this would need
 to be changed in the spec. The Blueprint spec doesn't mention inner
 classes so there's nothing AFAICT in the spec that excludes the use of
 them - so arguably you could open a bug at the OSGi Alliance [1]. It's
 worth discussing first on the developers list [2].


I can not post to the Alliance dev list, I've received a failure report 
saying I'm not allowed to post. Does one have to represent an Alliance 
member to post to that list ?


 [1] www.osgi.org/bugzilla
 [2] http://www.osgi.org/MailLists/HomePage

 Cheers,
 Jeremy

P.S Here is copy of the rejected post, perhaps you can forward it to 
that list ?


Hello All,

I've recently reported an issue at the Apache Aries dev list [1] to do 
with the
Blueprint schema blocking the nested static class names and I'm moving 
the discussion to this list as recommended by Jeremy Hughes.


The fix proposed at [1] is to relax the schema for Java (or I guess 
other language VMs) to validate the class names as opposed to 
restricting the names at the higher level in Blueprint schema.


We came across the issue while working on migrating the application 
including many code-generated nested classes to Blueprint.


Any objections to me opening a bug at [2] ?

Thanks, Sergey

[1] 
http://mail-archives.apache.org/mod_mbox/aries-dev/201204.mbox/ajax/%3C4F7A03DE.4060603%40gmail.com%3E

[2] https://www.osgi.org/bugzilla/

Blueprint schema blocks nested static class names

[Sergey Beryozkin]

Hi,

The blueprint schema [1] blocks the class names containing a '$' 
character, specifically, a Tclass types expects all the Java class names 
to match the xsd:NCName pattern.


Thus attempting to load a class such as a.b.MyClass$MyNestedClass 
fails with the schema validation error which as it happens works OK in 
Spring.


I'd like to propose to drop the NCName restriction and introduce and 
xsd:string in Tclass instead.
IMHO that is the simplest solution - the Java runtime will effectively 
validate the class name anyway so trying to enforce the Java class name 
rules in the  Blueprint schema may not be ideal.


If people are OK with this proposed update then I can proceed with the 
change in the next few days


Sergey

[1] 
https://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-api/src/main/resources/org/osgi/service/blueprint/blueprint.xsd