10:52 p.m.
Hi experts,
IMHO, making Bean Validation ready for the modular world is a great thing!
A first step might be to provide the module meta-datas (OSGi headers, …). For OSGi, those
meta-datas can be added to the jar Manifest within the maven build with the
maven-bundle-plugin
(http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html). The advantage is
that the api can be deployed in an OSGi container out of the box. For JBoss Modules the
descriptor reside alongside its content but we can provide it.
WDYT?
--Kevin
10:03 a.m.
So all JARs must be OSGi-ified before they can be used? Is there any way to keep this
information outside? Do you know of any other JSR published JAR that also expose its OSGi
headers?
I'm asking because declaring dependencies means that all dependent JSRs (and the JDK)
will need to be OSGi-ified as well. I'd rather see that coordinated by the Java EE
expert group. There is also the problem of supporting them forever(tm).
On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
Hi experts,
IMHO, making Bean Validation ready for the modular world is a great thing!
A first step might be to provide the module meta-datas (OSGi headers, …). For OSGi, those
meta-datas can be added to the jar Manifest within the maven build with the
maven-bundle-plugin. The advantage is that the api can be deployed in an OSGi container
out of the box. For JBoss Modules the descriptor reside alongside its content but we can
provide it.
WDYT?
--Kevin
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:50 p.m.
Hi,
On 28 October 2011 09:03, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
So all JARs must be OSGi-ified before they can be used? Is there any
way to
keep this information outside?
Right, all JARS must be OSGi-ified before they can be deployed in an OSGi
container. By the way, it's also possible to embed jars in a bundle, but
that's not in the OSGi spirit. AFAIK, there is no way to put these
information outside the jar (JBoss Modules is less intrusive here).
Do you know of any other JSR published JAR that also expose its OSGi
headers?
JAX-RS (JSR-311) expose the OSGi headers in its
Manifest<http://grepcode.com/file/repo1.maven.org/maven2/javax.ws.rs/j...
.
I'm asking because declaring dependencies means that all
dependent JSRs
(and the JDK) will need to be OSGi-ified as well. I'd rather see that
coordinated by the Java EE expert group. There is also the problem of
supporting them forever(tm).
No need to OSGi-ified the JDK, by default it's part of every Bundle
classloader.
Currently, for BV there is no dependencies, so all packages just need to be
exported (like JAX-RS). I agree that if a dependency, non OSGi-ified, is
added to BV the interest is limited. I see two cases:
* the dependency can be OSGi-ified by the user -> OK
* the dependency cannot be OSGi-ified -> BV cannot be deployed as a bundle
(but can be embedded in the user bundle)
--Kevin
On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
Hi experts,
IMHO, making Bean Validation ready for the modular world is a great thing!
A first step might be to provide the module meta-datas (OSGi headers,
…). For OSGi, those meta-datas can be added to the jar Manifest within the
maven build with the
maven-bundle-plugin<http://felix.apache.org/site/apache-felix-maven-bu...;.
The advantage is that the api can be deployed in an OSGi container out of
the box. For JBoss Modules the descriptor reside alongside its content but
we can provide it.
WDYT?
--Kevin
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:13 p.m.
So all JARs must be OSGi-ified before they can be used? [...]
I'm asking because declaring dependencies means that all dependent JSRs (and
the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
by the Java EE expert group.
In case of BV we would have to add the OSGi headers to the JAR to make
it usable under OSGi. As Kevin says there is no relation to the JDK
here, and AFAIK the BV API doesn't have any other additional
dependencies. So adding these headers wouldn't be a problem IMO (each
OSGi bundle is still a standard JAR which can be used in any other
environment).
Another thing is the bootstrapping, i.e. how BV implementations are
found. Searching for resources such as
META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't
know about JBoss modules). This kind of things is in OSGi typically
solved using services, that means in the BV bundle would be the
definition of a service interface (we already have this with
ValidationProvider) while BV providers would register implementations
of this service. In the BV API Jar we still would need some glue
code/meta-data to obtain references to these implementations.
Personally I feel adding the headers would be ok for the "official"
API Jar as it's rather un-intrusive, but the bootstrapping stuff might
be too much. One idea might be to provide separate "enabler" modules
for the different module systems around, e.g. there could be a
bv-osgi.jar which takes the raw API jar and makes it usable under OSGi
(it could also offer j.v.Validator as OSGi service etc.).
--Gunnar
2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
So all JARs must be OSGi-ified before they can be used? Is there any
way to
keep this information outside? Do you know of any other JSR published JAR
that also expose its OSGi headers?
I'm asking because declaring dependencies means that all dependent JSRs (and
the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
by the Java EE expert group. There is also the problem of supporting them
forever(tm).
On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
Hi experts,
IMHO, making Bean Validation ready for the modular world is a great thing!
A first step might be to provide the module meta-datas (OSGi headers,
…). For OSGi, those meta-datas can be added to the jar Manifest within the
maven build with the maven-bundle-plugin. The advantage is that the api can
be deployed in an OSGi container out of the box. For JBoss Modules the
descriptor reside alongside its content but we can provide it.
WDYT?
--Kevin
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:36 p.m.
Two points.
CDI will be a dependency of Bean Validation (see topic on injection).
What does not work today in the following code in a modular environment?
Validation
.byDefaultProvider()
.providerResolver( myOSGiResolver )
.configure()
.buildValidatorFactory();
On 31 oct. 2011, at 17:13, Gunnar Morling <gunnar.morling(a)googlemail.com> wrote:
> So all JARs must be OSGi-ified before they can be used? [...]
> I'm asking because declaring dependencies means that all dependent JSRs (and
> the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
> by the Java EE expert group.
In case of BV we would have to add the OSGi headers to the JAR to make
it usable under OSGi. As Kevin says there is no relation to the JDK
here, and AFAIK the BV API doesn't have any other additional
dependencies. So adding these headers wouldn't be a problem IMO (each
OSGi bundle is still a standard JAR which can be used in any other
environment).
Another thing is the bootstrapping, i.e. how BV implementations are
found. Searching for resources such as
META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't
know about JBoss modules). This kind of things is in OSGi typically
solved using services, that means in the BV bundle would be the
definition of a service interface (we already have this with
ValidationProvider) while BV providers would register implementations
of this service. In the BV API Jar we still would need some glue
code/meta-data to obtain references to these implementations.
Personally I feel adding the headers would be ok for the "official"
API Jar as it's rather un-intrusive, but the bootstrapping stuff might
be too much. One idea might be to provide separate "enabler" modules
for the different module systems around, e.g. there could be a
bv-osgi.jar which takes the raw API jar and makes it usable under OSGi
(it could also offer j.v.Validator as OSGi service etc.).
--Gunnar
2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> So all JARs must be OSGi-ified before they can be used? Is there any way to
> keep this information outside? Do you know of any other JSR published JAR
> that also expose its OSGi headers?
> I'm asking because declaring dependencies means that all dependent JSRs (and
> the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
> by the Java EE expert group. There is also the problem of supporting them
> forever(tm).
> On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
>
> Hi experts,
> IMHO, making Bean Validation ready for the modular world is a great thing!
> A first step might be to provide the module meta-datas (OSGi headers,
> …). For OSGi, those meta-datas can be added to the jar Manifest within the
> maven build with the maven-bundle-plugin. The advantage is that the api can
> be deployed in an OSGi container out of the box. For JBoss Modules the
> descriptor reside alongside its content but we can provide it.
> WDYT?
> --Kevin
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
9:16 p.m.
What does not work today in the following code in a modular
environment?
Validation
.byDefaultProvider()
.providerResolver( myOSGiResolver )
.configure()
.buildValidatorFactory();
An OSGi-aware resolver is the way to go, but I was wondering who would
build such a resolver. Besides the resolver there would also some glue
code/meta data be required on the BV provider side registering with
the resolver.
We could leave this to end users, but IMO it would be advantageous if
there was a publicly available resolver which just everyone could use.
This was the idea behind having an bv-api-osgi.jar. Any BV
implementation interested in being usable under OSGi could register
itself with that module.
Another question is how custom validators are registered within a
modular environment (e.g. a custom validator for @Past). A module
providing such a validator could contain a constraint mapping for it,
but under OSGi there is AFAIK no way to reference this mapping file
from validation.xml contained in another module. So users of the
custom validator would have to create a constraint mapping file on
their own. This could be circumvented if the bv-api-osgi.jar would
define an "extension point" to which constraint libraries could
contribute their validators.
It also might be useful to have an OSGi-aware resource bundle locator
mechanism which defines an extension point to which constraint
libraries could contribute their message bundles.
All in all I'm unsure whether we should define these things in the
spec. Maybe it would be more appropriate to provide this in separate
project, but it's certainly a field where some improvements would be
beneficial.
--Gunnar
2011/11/1 Emmanuel Bernard <emmanuel(a)hibernate.org>:
Two points.
CDI will be a dependency of Bean Validation (see topic on injection).
What does not work today in the following code in a modular environment?
Validation
.byDefaultProvider()
.providerResolver( myOSGiResolver )
.configure()
.buildValidatorFactory();
On 31 oct. 2011, at 17:13, Gunnar Morling <gunnar.morling(a)googlemail.com>
wrote:
So all JARs must be OSGi-ified before they can be used? [...]
I'm asking because declaring dependencies means that all dependent JSRs (and
the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
by the Java EE expert group.
In case of BV we would have to add the OSGi headers to the JAR to make
it usable under OSGi. As Kevin says there is no relation to the JDK
here, and AFAIK the BV API doesn't have any other additional
dependencies. So adding these headers wouldn't be a problem IMO (each
OSGi bundle is still a standard JAR which can be used in any other
environment).
Another thing is the bootstrapping, i.e. how BV implementations are
found. Searching for resources such as
META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't
know about JBoss modules). This kind of things is in OSGi typically
solved using services, that means in the BV bundle would be the
definition of a service interface (we already have this with
ValidationProvider) while BV providers would register implementations
of this service. In the BV API Jar we still would need some glue
code/meta-data to obtain references to these implementations.
Personally I feel adding the headers would be ok for the "official"
API Jar as it's rather un-intrusive, but the bootstrapping stuff might
be too much. One idea might be to provide separate "enabler" modules
for the different module systems around, e.g. there could be a
bv-osgi.jar which takes the raw API jar and makes it usable under OSGi
(it could also offer j.v.Validator as OSGi service etc.).
--Gunnar
2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
So all JARs must be OSGi-ified before they can be used? Is there any way to
keep this information outside? Do you know of any other JSR published JAR
that also expose its OSGi headers?
I'm asking because declaring dependencies means that all dependent JSRs (and
the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
by the Java EE expert group. There is also the problem of supporting them
forever(tm).
On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
Hi experts,
IMHO, making Bean Validation ready for the modular world is a great thing!
A first step might be to provide the module meta-datas (OSGi headers,
…). For OSGi, those meta-datas can be added to the jar Manifest within the
maven build with the maven-bundle-plugin. The advantage is that the api can
be deployed in an OSGi container out of the box. For JBoss Modules the
descriptor reside alongside its content but we can provide it.
WDYT?
--Kevin
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:13 p.m.
Hi,
On 1 November 2011 15:36, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Two points.
CDI will be a dependency of Bean Validation (see topic on injection).
What does not work today in the following code in a modular environment?
Validation
.byDefaultProvider()
.providerResolver( myOSGiResolver )
.configure()
.buildValidatorFactory();
The dependency to CDI will be optional, right?
In this case that dependency should be declared as optional in the OSGi
headers. By doing that, if CDI cannot be used in an OSGI environment this
will not affect BV.
AFAIK, the following things doesn't work with that approach (not
exhaustive):
* loading of validation and constraint mapping files
* loading of ValidationMessages.properties
* I've not tested it but I think the loading of the class specified in the
xml files doesn't work
The problem here is that the implementation use the TCCL or the classloader
of one of its class to load resources or classes. That approach cannot work
in a modular environment. For example in OSGi the TCCL is not set to the
right classloader and the implementation classloader can't access another
bundle resources or classes (if they are not imported).
IMHO, BV should specify a mechanism used by implementations to load
resources and classes. The default implementation should work out of the
box in Java EE and this mechanism can be customized by users which want to
work in a modular environement.
Maybe an implementation of such mechanism can be provided for OSGi or JBoss
modules by the RI?
WDYT?
--Kevin
On 31 oct. 2011, at 17:13, Gunnar Morling <gunnar.morling(a)googlemail.com>
wrote:
So all JARs must be OSGi-ified before they can be used? [...]
I'm asking because declaring dependencies means that all dependent JSRs
(and
the JDK) will need to be OSGi-ified as well. I'd rather see that
coordinated
by the Java EE expert group.
In case of BV we would have to add the OSGi headers to the JAR to make
it usable under OSGi. As Kevin says there is no relation to the JDK
here, and AFAIK the BV API doesn't have any other additional
dependencies. So adding these headers wouldn't be a problem IMO (each
OSGi bundle is still a standard JAR which can be used in any other
environment).
Another thing is the bootstrapping, i.e. how BV implementations are
found. Searching for resources such as
META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't
know about JBoss modules). This kind of things is in OSGi typically
solved using services, that means in the BV bundle would be the
definition of a service interface (we already have this with
ValidationProvider) while BV providers would register implementations
of this service. In the BV API Jar we still would need some glue
code/meta-data to obtain references to these implementations.
Personally I feel adding the headers would be ok for the "official"
API Jar as it's rather un-intrusive, but the bootstrapping stuff might
be too much. One idea might be to provide separate "enabler" modules
for the different module systems around, e.g. there could be a
bv-osgi.jar which takes the raw API jar and makes it usable under OSGi
(it could also offer j.v.Validator as OSGi service etc.).
--Gunnar
2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
So all JARs must be OSGi-ified before they can be used? Is there any way to
keep this information outside? Do you know of any other JSR published JAR
that also expose its OSGi headers?
I'm asking because declaring dependencies means that all dependent JSRs
(and
the JDK) will need to be OSGi-ified as well. I'd rather see that
coordinated
by the Java EE expert group. There is also the problem of supporting them
forever(tm).
On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
Hi experts,
IMHO, making Bean Validation ready for the modular world is a great thing!
A first step might be to provide the module meta-datas (OSGi headers,
…). For OSGi, those meta-datas can be added to the jar Manifest within the
maven build with the maven-bundle-plugin. The advantage is that the api can
be deployed in an OSGi container out of the box. For JBoss Modules the
descriptor reside alongside its content but we can provide it.
WDYT?
--Kevin
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
5:47 p.m.
Sorry for the long slack off.
OSGi is generally not my field but here are a few comments on what Gunnar and Kevin have
said:
- we can definitely experiment with Hibernate Validator and offer some OOTB support for
OSGi and other modularity solutions.
- we can consider the API JAR provided by the RI team and add the OSGi headers if
that's the correct solution but I don't feel like adding them in the spec document
proper
- we should align with what the CDI group does wrt OSGi headers especially since CDI will
be an optional dependency of BV
- can someone flesh out a more concrete proposal and push it to
http://beanvalidation.org/proposals/BVAL-251 ? Kevin do you want to take the lead?
Emmanuel
On 3 nov. 2011, at 12:13, Kevin Pollet wrote:
Hi,
On 1 November 2011 15:36, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Two points.
CDI will be a dependency of Bean Validation (see topic on injection).
What does not work today in the following code in a modular environment?
Validation
.byDefaultProvider()
.providerResolver( myOSGiResolver )
.configure()
.buildValidatorFactory();
The dependency to CDI will be optional, right?
In this case that dependency should be declared as optional in the OSGi headers. By doing
that, if CDI cannot be used in an OSGI environment this will not affect BV.
AFAIK, the following things doesn't work with that approach (not exhaustive):
* loading of validation and constraint mapping files
* loading of ValidationMessages.properties
* I've not tested it but I think the loading of the class specified in the xml files
doesn't work
The problem here is that the implementation use the TCCL or the classloader of one of its
class to load resources or classes. That approach cannot work in a modular environment.
For example in OSGi the TCCL is not set to the right classloader and the implementation
classloader can't access another bundle resources or classes (if they are not
imported).
IMHO, BV should specify a mechanism used by implementations to load resources and
classes. The default implementation should work out of the box in Java EE and this
mechanism can be customized by users which want to work in a modular environement.
Maybe an implementation of such mechanism can be provided for OSGi or JBoss modules by
the RI?
WDYT?
--Kevin
On 31 oct. 2011, at 17:13, Gunnar Morling <gunnar.morling(a)googlemail.com> wrote:
>> So all JARs must be OSGi-ified before they can be used? [...]
>> I'm asking because declaring dependencies means that all dependent JSRs (and
>> the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
>> by the Java EE expert group.
>
> In case of BV we would have to add the OSGi headers to the JAR to make
> it usable under OSGi. As Kevin says there is no relation to the JDK
> here, and AFAIK the BV API doesn't have any other additional
> dependencies. So adding these headers wouldn't be a problem IMO (each
> OSGi bundle is still a standard JAR which can be used in any other
> environment).
>
> Another thing is the bootstrapping, i.e. how BV implementations are
> found. Searching for resources such as
> META-INF/services/j.v.ValidationProvider doesn't work in OSGi (I don't
> know about JBoss modules). This kind of things is in OSGi typically
> solved using services, that means in the BV bundle would be the
> definition of a service interface (we already have this with
> ValidationProvider) while BV providers would register implementations
> of this service. In the BV API Jar we still would need some glue
> code/meta-data to obtain references to these implementations.
>
> Personally I feel adding the headers would be ok for the "official"
> API Jar as it's rather un-intrusive, but the bootstrapping stuff might
> be too much. One idea might be to provide separate "enabler" modules
> for the different module systems around, e.g. there could be a
> bv-osgi.jar which takes the raw API jar and makes it usable under OSGi
> (it could also offer j.v.Validator as OSGi service etc.).
>
> --Gunnar
>
> 2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> So all JARs must be OSGi-ified before they can be used? Is there any way to
>> keep this information outside? Do you know of any other JSR published JAR
>> that also expose its OSGi headers?
>> I'm asking because declaring dependencies means that all dependent JSRs (and
>> the JDK) will need to be OSGi-ified as well. I'd rather see that coordinated
>> by the Java EE expert group. There is also the problem of supporting them
>> forever(tm).
>> On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
>>
>> Hi experts,
>> IMHO, making Bean Validation ready for the modular world is a great thing!
>> A first step might be to provide the module meta-datas (OSGi headers,
>> …). For OSGi, those meta-datas can be added to the jar Manifest within the
>> maven build with the maven-bundle-plugin. The advantage is that the api can
>> be deployed in an OSGi container out of the box. For JBoss Modules the
>> descriptor reside alongside its content but we can provide it.
>> WDYT?
>> --Kevin
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:13 p.m.
Hi,
On 2 January 2012 17:47, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Sorry for the long slack off.
OSGi is generally not my field but here are a few comments on what Gunnar
and Kevin have said:
- we can definitely experiment with Hibernate Validator and offer some
OOTB support for OSGi and other modularity solutions.
- we can consider the API JAR provided by the RI team and add the OSGi
headers if that's the correct solution but I don't feel like adding them in
the spec document proper
- we should align with what the CDI group does wrt OSGi headers especially
since CDI will be an optional dependency of BV
- can someone flesh out a more concrete proposal and push it to
http://beanvalidation.org/proposals/BVAL-251 ? Kevin do you want to take
the lead?
Sure.
I'll try to write a concrete proposal asap on beanvalidation.org
--Kevin
4:02 p.m.
Hi Emmanuel, Kevin :
Please find a reference on defining OSGi header and version numbers in
the manifest file of api .jars.
https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules
Thanks,
-Jagadish
On Mon, 2012-01-02 at 17:47 +0100, Emmanuel Bernard wrote:
Sorry for the long slack off.
OSGi is generally not my field but here are a few comments on what
Gunnar and Kevin have said:
- we can definitely experiment with Hibernate Validator and offer some
OOTB support for OSGi and other modularity solutions.
- we can consider the API JAR provided by the RI team and add the OSGi
headers if that's the correct solution but I don't feel like adding
them in the spec document proper
- we should align with what the CDI group does wrt OSGi headers
especially since CDI will be an optional dependency of BV
- can someone flesh out a more concrete proposal and push it
to http://beanvalidation.org/proposals/BVAL-251 ? Kevin do you want to
take the lead?
Emmanuel
On 3 nov. 2011, at 12:13, Kevin Pollet wrote:
> Hi,
>
> On 1 November 2011 15:36, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
> Two points.
>
>
> CDI will be a dependency of Bean Validation (see topic on
> injection).
>
>
> What does not work today in the following code in a modular
> environment?
>
>
> Validation
> .byDefaultProvider()
> .providerResolver( myOSGiResolver )
> .configure()
> .buildValidatorFactory();
>
>
> The dependency to CDI will be optional, right?
>
>
> In this case that dependency should be declared as optional in the
> OSGi headers. By doing that, if CDI cannot be used in an OSGI
> environment this will not affect BV.
>
>
> AFAIK, the following things doesn't work with that approach (not
> exhaustive):
>
>
> * loading of validation and constraint mapping files
> * loading of ValidationMessages.properties
> * I've not tested it but I think the loading of the class specified
> in the xml files doesn't work
>
>
> The problem here is that the implementation use the TCCL or the
> classloader of one of its class to load resources or classes. That
> approach cannot work in a modular environment. For example in OSGi
> the TCCL is not set to the right classloader and the implementation
> classloader can't access another bundle resources or classes (if
> they are not imported).
>
>
> IMHO, BV should specify a mechanism used by implementations to load
> resources and classes. The default implementation should work out of
> the box in Java EE and this mechanism can be customized by users
> which want to work in a modular environement.
>
>
> Maybe an implementation of such mechanism can be provided for OSGi
> or JBoss modules by the RI?
>
>
> WDYT?
>
>
> --Kevin
>
>
> On 31 oct. 2011, at 17:13, Gunnar Morling
> <gunnar.morling(a)googlemail.com> wrote:
>
>
>
> > > So all JARs must be OSGi-ified before they can be used?
> > > [...]
> > > I'm asking because declaring dependencies means that all
> > > dependent JSRs (and
> > > the JDK) will need to be OSGi-ified as well. I'd rather
> > > see that coordinated
> > > by the Java EE expert group.
> >
> > In case of BV we would have to add the OSGi headers to the
> > JAR to make
> > it usable under OSGi. As Kevin says there is no relation
> > to the JDK
> > here, and AFAIK the BV API doesn't have any other
> > additional
> > dependencies. So adding these headers wouldn't be a
> > problem IMO (each
> > OSGi bundle is still a standard JAR which can be used in
> > any other
> > environment).
> >
> > Another thing is the bootstrapping, i.e. how BV
> > implementations are
> > found. Searching for resources such as
> > META-INF/services/j.v.ValidationProvider doesn't work in
> > OSGi (I don't
> > know about JBoss modules). This kind of things is in OSGi
> > typically
> > solved using services, that means in the BV bundle would
> > be the
> > definition of a service interface (we already have this
> > with
> > ValidationProvider) while BV providers would register
> > implementations
> > of this service. In the BV API Jar we still would need
> > some glue
> > code/meta-data to obtain references to these
> > implementations.
> >
> > Personally I feel adding the headers would be ok for the
> > "official"
> > API Jar as it's rather un-intrusive, but the bootstrapping
> > stuff might
> > be too much. One idea might be to provide separate
> > "enabler" modules
> > for the different module systems around, e.g. there could
> > be a
> > bv-osgi.jar which takes the raw API jar and makes it
> > usable under OSGi
> > (it could also offer j.v.Validator as OSGi service etc.).
> >
> > --Gunnar
> >
> > 2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> > > So all JARs must be OSGi-ified before they can be used?
> > > Is there any way to
> > > keep this information outside? Do you know of any other
> > > JSR published JAR
> > > that also expose its OSGi headers?
> > > I'm asking because declaring dependencies means that all
> > > dependent JSRs (and
> > > the JDK) will need to be OSGi-ified as well. I'd rather
> > > see that coordinated
> > > by the Java EE expert group. There is also the problem
> > > of supporting them
> > > forever(tm).
> > > On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
> > >
> > > Hi experts,
> > > IMHO, making Bean Validation ready for the modular world
> > > is a great thing!
> > > A first step might be to provide the module meta-datas
> > > (OSGi headers,
> > > …). For OSGi, those meta-datas can be added to the jar
> > > Manifest within the
> > > maven build with the maven-bundle-plugin. The advantage
> > > is that the api can
> > > be deployed in an OSGi container out of the box. For
> > > JBoss Modules the
> > > descriptor reside alongside its content but we can
> > > provide it.
> > > WDYT?
> > > --Kevin
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
> > >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:14 p.m.
Thanks for the link.
--Kevin
On 9 January 2012 16:02, Jagadish Prasath Ramu <jagadish.ramu(a)oracle.com>wrote:
Hi Emmanuel, Kevin :
Please find a reference on defining OSGi header and version numbers in
the manifest file of api .jars.
https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules
Thanks,
-Jagadish
On Mon, 2012-01-02 at 17:47 +0100, Emmanuel Bernard wrote:
> Sorry for the long slack off.
>
>
> OSGi is generally not my field but here are a few comments on what
> Gunnar and Kevin have said:
>
>
> - we can definitely experiment with Hibernate Validator and offer some
> OOTB support for OSGi and other modularity solutions.
> - we can consider the API JAR provided by the RI team and add the OSGi
> headers if that's the correct solution but I don't feel like adding
> them in the spec document proper
> - we should align with what the CDI group does wrt OSGi headers
> especially since CDI will be an optional dependency of BV
> - can someone flesh out a more concrete proposal and push it
> to http://beanvalidation.org/proposals/BVAL-251 ? Kevin do you want to
> take the lead?
>
>
> Emmanuel
>
> On 3 nov. 2011, at 12:13, Kevin Pollet wrote:
>
> > Hi,
> >
> > On 1 November 2011 15:36, Emmanuel Bernard <emmanuel(a)hibernate.org>
> > wrote:
> > Two points.
> >
> >
> > CDI will be a dependency of Bean Validation (see topic on
> > injection).
> >
> >
> > What does not work today in the following code in a modular
> > environment?
> >
> >
> > Validation
> > .byDefaultProvider()
> > .providerResolver( myOSGiResolver )
> > .configure()
> > .buildValidatorFactory();
> >
> >
> > The dependency to CDI will be optional, right?
> >
> >
> > In this case that dependency should be declared as optional in the
> > OSGi headers. By doing that, if CDI cannot be used in an OSGI
> > environment this will not affect BV.
> >
> >
> > AFAIK, the following things doesn't work with that approach (not
> > exhaustive):
> >
> >
> > * loading of validation and constraint mapping files
> > * loading of ValidationMessages.properties
> > * I've not tested it but I think the loading of the class specified
> > in the xml files doesn't work
> >
> >
> > The problem here is that the implementation use the TCCL or the
> > classloader of one of its class to load resources or classes. That
> > approach cannot work in a modular environment. For example in OSGi
> > the TCCL is not set to the right classloader and the implementation
> > classloader can't access another bundle resources or classes (if
> > they are not imported).
> >
> >
> > IMHO, BV should specify a mechanism used by implementations to load
> > resources and classes. The default implementation should work out of
> > the box in Java EE and this mechanism can be customized by users
> > which want to work in a modular environement.
> >
> >
> > Maybe an implementation of such mechanism can be provided for OSGi
> > or JBoss modules by the RI?
> >
> >
> > WDYT?
> >
> >
> > --Kevin
> >
> >
> > On 31 oct. 2011, at 17:13, Gunnar Morling
> > <gunnar.morling(a)googlemail.com> wrote:
> >
> >
> >
> > > > So all JARs must be OSGi-ified before they can be used?
> > > > [...]
> > > > I'm asking because declaring dependencies means that all
> > > > dependent JSRs (and
> > > > the JDK) will need to be OSGi-ified as well. I'd rather
> > > > see that coordinated
> > > > by the Java EE expert group.
> > >
> > > In case of BV we would have to add the OSGi headers to the
> > > JAR to make
> > > it usable under OSGi. As Kevin says there is no relation
> > > to the JDK
> > > here, and AFAIK the BV API doesn't have any other
> > > additional
> > > dependencies. So adding these headers wouldn't be a
> > > problem IMO (each
> > > OSGi bundle is still a standard JAR which can be used in
> > > any other
> > > environment).
> > >
> > > Another thing is the bootstrapping, i.e. how BV
> > > implementations are
> > > found. Searching for resources such as
> > > META-INF/services/j.v.ValidationProvider doesn't work in
> > > OSGi (I don't
> > > know about JBoss modules). This kind of things is in OSGi
> > > typically
> > > solved using services, that means in the BV bundle would
> > > be the
> > > definition of a service interface (we already have this
> > > with
> > > ValidationProvider) while BV providers would register
> > > implementations
> > > of this service. In the BV API Jar we still would need
> > > some glue
> > > code/meta-data to obtain references to these
> > > implementations.
> > >
> > > Personally I feel adding the headers would be ok for the
> > > "official"
> > > API Jar as it's rather un-intrusive, but the bootstrapping
> > > stuff might
> > > be too much. One idea might be to provide separate
> > > "enabler" modules
> > > for the different module systems around, e.g. there could
> > > be a
> > > bv-osgi.jar which takes the raw API jar and makes it
> > > usable under OSGi
> > > (it could also offer j.v.Validator as OSGi service etc.).
> > >
> > > --Gunnar
> > >
> > > 2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> > > > So all JARs must be OSGi-ified before they can be used?
> > > > Is there any way to
> > > > keep this information outside? Do you know of any other
> > > > JSR published JAR
> > > > that also expose its OSGi headers?
> > > > I'm asking because declaring dependencies means that all
> > > > dependent JSRs (and
> > > > the JDK) will need to be OSGi-ified as well. I'd rather
> > > > see that coordinated
> > > > by the Java EE expert group. There is also the problem
> > > > of supporting them
> > > > forever(tm).
> > > > On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
> > > >
> > > > Hi experts,
> > > > IMHO, making Bean Validation ready for the modular world
> > > > is a great thing!
> > > > A first step might be to provide the module meta-datas
> > > > (OSGi headers,
> > > > …). For OSGi, those meta-datas can be added to the jar
> > > > Manifest within the
> > > > maven build with the maven-bundle-plugin. The advantage
> > > > is that the api can
> > > > be deployed in an OSGi container out of the box. For
> > > > JBoss Modules the
> > > > descriptor reside alongside its content but we can
> > > > provide it.
> > > > WDYT?
> > > > --Kevin
> > > >
> > > > _______________________________________________
> > > > beanvalidation-dev mailing list
> > > > beanvalidation-dev(a)lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > beanvalidation-dev mailing list
> > > > beanvalidation-dev(a)lists.jboss.org
> > > >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > >
> > > >
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
1:37 p.m.
Hi all,
I just wanted to revive this thread dealing with Bean Validation and OSGi - BVAL-251 [1]
I think there are several things we are discussing:
1. Adding OSGi meta information to META-INF (aka which packages are imported and
exported)
2. Exporting ValidatorFactory (and Validator) as OSGi services
3. Providing additional extension points to allow OSGi for example to e.g. register
custom constraint implementations
Regarding #1 we have so far been talking about just adding the OSGi header information to
the BV API jar. Given that it just exports its API and has no other dependencies that
should be fine.
I think most agree that we can just add this information.
We never discussed, though, whether it should be a requirement for BV implementations to
also add this
meta information? Is this taking a step too far?
Regarding #2 AFAIU the biggest problem is that it requires some OSGi specific code
in the BV API jar. Basically, BV implementations would need to be able to register their
implementation
and BV would need to then make them available. This enabling code could can either be in
the API jar itself or
be made available in a separate jar. Gunnar has already summed this up in a previous mail.
There is also a very recent discussion on HV-570 [2] about this.
I think the first step is to decide whether BV should really specify this. For me the
only sensible approach would be
an additional ODGI enabling jar. Is this something the BV spec can and should address and
provide? Or do we
leave this up to the BV implementations.
Emmanuel, you mentioned that we might align CDI in regards to OSGi. Are there any news
there?
--Hardy
[1] https://hibernate.onjira.com/browse/BVAL-251
[2] https://hibernate.onjira.com/browse/HV-570
On Jan 9, 2012, at 4:02 PM, Jagadish Prasath Ramu wrote:
Hi Emmanuel, Kevin :
Please find a reference on defining OSGi header and version numbers in
the manifest file of api .jars.
https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules
Thanks,
-Jagadish
On Mon, 2012-01-02 at 17:47 +0100, Emmanuel Bernard wrote:
> Sorry for the long slack off.
>
>
> OSGi is generally not my field but here are a few comments on what
> Gunnar and Kevin have said:
>
>
> - we can definitely experiment with Hibernate Validator and offer some
> OOTB support for OSGi and other modularity solutions.
> - we can consider the API JAR provided by the RI team and add the OSGi
> headers if that's the correct solution but I don't feel like adding
> them in the spec document proper
> - we should align with what the CDI group does wrt OSGi headers
> especially since CDI will be an optional dependency of BV
> - can someone flesh out a more concrete proposal and push it
> to http://beanvalidation.org/proposals/BVAL-251 ? Kevin do you want to
> take the lead?
>
>
> Emmanuel
>
> On 3 nov. 2011, at 12:13, Kevin Pollet wrote:
>
>> Hi,
>>
>> On 1 November 2011 15:36, Emmanuel Bernard <emmanuel(a)hibernate.org>
>> wrote:
>> Two points.
>>
>>
>> CDI will be a dependency of Bean Validation (see topic on
>> injection).
>>
>>
>> What does not work today in the following code in a modular
>> environment?
>>
>>
>> Validation
>> .byDefaultProvider()
>> .providerResolver( myOSGiResolver )
>> .configure()
>> .buildValidatorFactory();
>>
>>
>> The dependency to CDI will be optional, right?
>>
>>
>> In this case that dependency should be declared as optional in the
>> OSGi headers. By doing that, if CDI cannot be used in an OSGI
>> environment this will not affect BV.
>>
>>
>> AFAIK, the following things doesn't work with that approach (not
>> exhaustive):
>>
>>
>> * loading of validation and constraint mapping files
>> * loading of ValidationMessages.properties
>> * I've not tested it but I think the loading of the class specified
>> in the xml files doesn't work
>>
>>
>> The problem here is that the implementation use the TCCL or the
>> classloader of one of its class to load resources or classes. That
>> approach cannot work in a modular environment. For example in OSGi
>> the TCCL is not set to the right classloader and the implementation
>> classloader can't access another bundle resources or classes (if
>> they are not imported).
>>
>>
>> IMHO, BV should specify a mechanism used by implementations to load
>> resources and classes. The default implementation should work out of
>> the box in Java EE and this mechanism can be customized by users
>> which want to work in a modular environement.
>>
>>
>> Maybe an implementation of such mechanism can be provided for OSGi
>> or JBoss modules by the RI?
>>
>>
>> WDYT?
>>
>>
>> --Kevin
>>
>>
>> On 31 oct. 2011, at 17:13, Gunnar Morling
>> <gunnar.morling(a)googlemail.com> wrote:
>>
>>
>>
>>>> So all JARs must be OSGi-ified before they can be used?
>>>> [...]
>>>> I'm asking because declaring dependencies means that all
>>>> dependent JSRs (and
>>>> the JDK) will need to be OSGi-ified as well. I'd rather
>>>> see that coordinated
>>>> by the Java EE expert group.
>>>
>>> In case of BV we would have to add the OSGi headers to the
>>> JAR to make
>>> it usable under OSGi. As Kevin says there is no relation
>>> to the JDK
>>> here, and AFAIK the BV API doesn't have any other
>>> additional
>>> dependencies. So adding these headers wouldn't be a
>>> problem IMO (each
>>> OSGi bundle is still a standard JAR which can be used in
>>> any other
>>> environment).
>>>
>>> Another thing is the bootstrapping, i.e. how BV
>>> implementations are
>>> found. Searching for resources such as
>>> META-INF/services/j.v.ValidationProvider doesn't work in
>>> OSGi (I don't
>>> know about JBoss modules). This kind of things is in OSGi
>>> typically
>>> solved using services, that means in the BV bundle would
>>> be the
>>> definition of a service interface (we already have this
>>> with
>>> ValidationProvider) while BV providers would register
>>> implementations
>>> of this service. In the BV API Jar we still would need
>>> some glue
>>> code/meta-data to obtain references to these
>>> implementations.
>>>
>>> Personally I feel adding the headers would be ok for the
>>> "official"
>>> API Jar as it's rather un-intrusive, but the bootstrapping
>>> stuff might
>>> be too much. One idea might be to provide separate
>>> "enabler" modules
>>> for the different module systems around, e.g. there could
>>> be a
>>> bv-osgi.jar which takes the raw API jar and makes it
>>> usable under OSGi
>>> (it could also offer j.v.Validator as OSGi service etc.).
>>>
>>> --Gunnar
>>>
>>> 2011/10/28 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>> So all JARs must be OSGi-ified before they can be used?
>>>> Is there any way to
>>>> keep this information outside? Do you know of any other
>>>> JSR published JAR
>>>> that also expose its OSGi headers?
>>>> I'm asking because declaring dependencies means that all
>>>> dependent JSRs (and
>>>> the JDK) will need to be OSGi-ified as well. I'd rather
>>>> see that coordinated
>>>> by the Java EE expert group. There is also the problem
>>>> of supporting them
>>>> forever(tm).
>>>> On 27 oct. 2011, at 22:52, Kevin Pollet wrote:
>>>>
>>>> Hi experts,
>>>> IMHO, making Bean Validation ready for the modular world
>>>> is a great thing!
>>>> A first step might be to provide the module meta-datas
>>>> (OSGi headers,
>>>> …). For OSGi, those meta-datas can be added to the jar
>>>> Manifest within the
>>>> maven build with the maven-bundle-plugin. The advantage
>>>> is that the api can
>>>> be deployed in an OSGi container out of the box. For
>>>> JBoss Modules the
>>>> descriptor reside alongside its content but we can
>>>> provide it.
>>>> WDYT?
>>>> --Kevin
12:11 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
Hi,
Seems everyone is tired of OSGi? Maybe adding the OSGi header is as far as we should go.
However, I would like to use this thread to a related question - class loading.
At several occasions Hibernate Validator needs to do some class loading or at least needs
a class loader
(e.g. loading classes specified in the xml configuration, detecting whether JPA is on the
classpath in the case
of TraversableResolver, loading resource bundles).
The spec does not define which class loader should be used in these cases. Hibernate
Validator for example
first tries the context and then the current class loader. The question is whether there
is a need to specify which
class loader should be used or should there even be a ClassLoaderService:
public interface ClassLoaderService {
public <T> Class<T> classForName(String className);
// potentially more class loader related methods
….
}
An implementation of such a service could be passed if we add
javax.validation.Configuration#classLoaderService(ClassLoaderService).
WDYT?
--Hardy
On Apr 24, 2012, at 10:07 AM, Emmanuel Bernard wrote:
On 13 avr. 2012, at 13:37, Hardy Ferentschik wrote:
> Emmanuel, you mentioned that we might align CDI in regards to OSGi. Are there any
news there?
Not that I know of.
12:56 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
Hi,
Seems everyone is tired of OSGi? Maybe adding the OSGi header is as
far as we should go.
It has been a while since I've played around a bit with BVAL-251. I
still think some (standardized) OSGi support would be a good thing.
I've worked on the basic discovery (there are branches for the API [1]
and HV [2]) and I definitely would like to investigate the area a bit
more (would we need special message interpolators etc.), but since
then I just haven't found enough time to continue with the issue. I
hope I can continue with that within the next time. Maybe Kevin has
also some news on that.
Regarding the class loader service, this might be a good idea. I think
we should see which specific use cases there are (which related
problems currently exist etc.) in order to come up with a solution. It
would also be interesting to know how Apache Validation does class
loading. OSGi of course could be an area where such a service might be
very beneficial.
--Gunnar
[1] https://github.com/gunnarmorling/beanvalidation-api/tree/BVAL-251
[2] https://github.com/gunnarmorling/hibernate-validator/tree/BVAL-251
2012/5/4 Hardy Ferentschik <hardy(a)hibernate.org>:
> Hi,
>
Seems everyone is tired of OSGi? Maybe adding the OSGi header is as
far as we should go.
>
> However, I would like to use this thread to a related question - class loading.
> At several occasions Hibernate Validator needs to do some class loading or at least
needs a class loader
> (e.g. loading classes specified in the xml configuration, detecting whether JPA is
on the classpath in the case
> of TraversableResolver, loading resource bundles).
>
> The spec does not define which class loader should be used in these cases. Hibernate
Validator for example
> first tries the context and then the current class loader. The question is whether
there is a need to specify which
> class loader should be used or should there even be a ClassLoaderService:
>
> public interface ClassLoaderService {
> public <T> Class<T> classForName(String className);
>
> // potentially more class loader related methods
> ….
> }
>
> An implementation of such a service could be passed if we add
javax.validation.Configuration#classLoaderService(ClassLoaderService).
>
> WDYT?
>
> --Hardy
>
>
> On Apr 24, 2012, at 10:07 AM, Emmanuel Bernard wrote:
>
>>
>> On 13 avr. 2012, at 13:37, Hardy Ferentschik wrote:
>>
>>> Emmanuel, you mentioned that we might align CDI in regards to OSGi. Are there
any news there?
>>
>> Not that I know of.
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
5:06 p.m.
On May 4, 2012, at 12:56 PM, Gunnar Morling wrote:
> Seems everyone is tired of OSGi? Maybe adding the OSGi header is
as far as we should go.
It has been a while since I've played around a bit with BVAL-251. I
still think some (standardized) OSGi support would be a good thing.
I've worked on the basic discovery (there are branches for the API [1]
and HV [2]) and I definitely would like to investigate the area a bit
more (would we need special message interpolators etc.), but since
then I just haven't found enough time to continue with the issue. I
hope I can continue with that within the next time. Maybe Kevin has
also some news on that.
I guess I am most concerned about the explicit dependency to org.osgi artifacts.
In this case I would prefer a separate activator jar (we discussed this before).
Question is, is it really the responsibility of the spec to provide such a thing.
Regarding the class loader service, this might be a good idea. I
think
we should see which specific use cases there are (which related
problems currently exist etc.) in order to come up with a solution.
I created https://hibernate.onjira.com/browse/BVAL-286. I really think such a service
is beneficial outside the OSGi scope, but even there it is useful.
Atm I see two main use cases - loading classes and leading resource bundles
<T> Class<T> classForName(String className);
ResourceBundle loadBundle(String bundleName, Locale locale);
It would also be interesting to know how Apache Validation does
class
loading.
Anyone? I would be interested as well :-)
--Hardy
9:16 a.m.
New subject: [BVAL-286] Class loading service
Hi,
Gunnar pointed just out the following blog post to me -
http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
It explains nicely some problems around class loading and discusses some solutions.
Independent of BVAL-251 it makes sense to define such a service.
--Hardy
On May 8, 2012, at 5:06 PM, Hardy Ferentschik wrote:
I created https://hibernate.onjira.com/browse/BVAL-286. I really
think such a service
is beneficial outside the OSGi scope, but even there it is useful.
Atm I see two main use cases - loading classes and leading resource bundles
<T> Class<T> classForName(String className);
ResourceBundle loadBundle(String bundleName, Locale locale);
> It would also be interesting to know how Apache Validation does class
> loading.
Anyone? I would be interested as well :-)
5:09 a.m.
New subject: [BVAL-286] Class loading service
Be very careful if you do this. Hibernate has implemented it and it
has brought more issues than solved...
Regards,
Michael
On Sun, May 13, 2012 at 4:16 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Hi,
Gunnar pointed just out the following blog post to me -
http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
It explains nicely some problems around class loading and discusses some solutions.
Independent of BVAL-251 it makes sense to define such a service.
--Hardy
On May 8, 2012, at 5:06 PM, Hardy Ferentschik wrote:
> I created https://hibernate.onjira.com/browse/BVAL-286. I really think such a
service
> is beneficial outside the OSGi scope, but even there it is useful.
>
> Atm I see two main use cases - loading classes and leading resource bundles
>
> <T> Class<T> classForName(String className);
> ResourceBundle loadBundle(String bundleName, Locale locale);
>
>> It would also be interesting to know how Apache Validation does class
>> loading.
>
> Anyone? I would be interested as well :-)
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
9:51 a.m.
New subject: [BVAL-286] Class loading service
Hi,
Can you elaborate on the issues that it has brought?
On 14 mai 2012, at 05:09, Michael Nascimento wrote:
Be very careful if you do this. Hibernate has implemented it and it
has brought more issues than solved...
Regards,
Michael
On Sun, May 13, 2012 at 4:16 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> Hi,
>
> Gunnar pointed just out the following blog post to me -
http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
> It explains nicely some problems around class loading and discusses some solutions.
>
> Independent of BVAL-251 it makes sense to define such a service.
>
> --Hardy
>
>
> On May 8, 2012, at 5:06 PM, Hardy Ferentschik wrote:
>
>> I created https://hibernate.onjira.com/browse/BVAL-286. I really think such a
service
>> is beneficial outside the OSGi scope, but even there it is useful.
>>
>> Atm I see two main use cases - loading classes and leading resource bundles
>>
>> <T> Class<T> classForName(String className);
>> ResourceBundle loadBundle(String bundleName, Locale locale);
>>
>>> It would also be interesting to know how Apache Validation does class
>>> loading.
>>
>> Anyone? I would be interested as well :-)
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:01 a.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
I'm not sure if that should be as classForName or by passing the classloader but I see
the following needs:
What:
- load a resource (XML)
- load a class and package
- all validation provides available - see provider resolver
From where:
- from the user application or from the module depending on BV
- from a dependency of the application or module depending on BV
The second case is interesting, we need to know for example:
- if JPA is a dependency of the application
- find constraints and constraint validators contained in either the application directly
or in a dependency of the application
I am not sure how to do that in various modular environments. I also wonder if all of this
should be masked behind a contract like your describe, or if the list of classloaders
should be exposed to BV and processed. I am also not sure of the impact of object
lifecycle.
Emmanuel
On 4 mai 2012, at 12:11, Hardy Ferentschik wrote:
Hi,
Seems everyone is tired of OSGi? Maybe adding the OSGi header is as far as we should go.
However, I would like to use this thread to a related question - class loading.
At several occasions Hibernate Validator needs to do some class loading or at least needs
a class loader
(e.g. loading classes specified in the xml configuration, detecting whether JPA is on
the classpath in the case
of TraversableResolver, loading resource bundles).
The spec does not define which class loader should be used in these cases. Hibernate
Validator for example
first tries the context and then the current class loader. The question is whether there
is a need to specify which
class loader should be used or should there even be a ClassLoaderService:
public interface ClassLoaderService {
public <T> Class<T> classForName(String className);
// potentially more class loader related methods
….
}
An implementation of such a service could be passed if we add
javax.validation.Configuration#classLoaderService(ClassLoaderService).
WDYT?
--Hardy
On Apr 24, 2012, at 10:07 AM, Emmanuel Bernard wrote:
>
> On 13 avr. 2012, at 13:37, Hardy Ferentschik wrote:
>
>> Emmanuel, you mentioned that we might align CDI in regards to OSGi. Are there any
news there?
>
> Not that I know of.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:31 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On May 14, 2012, at 10:01 AM, Emmanuel Bernard wrote:
I'm not sure if that should be as classForName or by passing the
classloader but I see the following needs:
The benefit of ClassLoaderService#classForName is that an implementation still could
decide to implement strategies like
first trying the context and the the current class loader.
> From where:
- from the user application or from the module depending on BV
I am also trying to understand what a modular environment means for a shared
ValidatorFactory.
If a user application depends on BV and also uses custom constraints, does it not mean the
application
would need to build its own ValidatorFactory via
ValidatorFactory#usingContext()#classLoaderService(classLoaderService).
I also wonder if all of this should be masked behind a contract like
your describe, or if the list of classloaders should be exposed to BV and processed.
How would the latter latter look like?
I am also not sure of the impact of object lifecycle.
What exactly do you mean here?
--Hardy
4:57 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On 14 mai 2012, at 12:31, Hardy Ferentschik wrote:
On May 14, 2012, at 10:01 AM, Emmanuel Bernard wrote:
> I'm not sure if that should be as classForName or by passing the classloader but
I see the following needs:
The benefit of ClassLoaderService#classForName is that an implementation still could
decide to implement strategies like
first trying the context and the the current class loader.
You can do the same if a list of classloaders is returned.
>> From where:
>
> - from the user application or from the module depending on BV
I am also trying to understand what a modular environment means for a shared
ValidatorFactory.
If a user application depends on BV and also uses custom constraints, does it not mean
the application
would need to build its own ValidatorFactory via
ValidatorFactory#usingContext()#classLoaderService(classLoaderService).
That would sucks balls!
> I also wonder if all of this should be masked behind a contract like your describe,
or if the list of classloaders should be exposed to BV and processed.
How would the latter latter look like?
Something like that
interface ClassloaderService {
/** Return an ordered list of classloaders to load classes and resources.
* BV providers should use these classlaoders in order as this reflect the
* application preference
*/
List<Classloader> getClassloaders();
}
Note that neither your nor my solution differentiate classloading depending on what ought
to be loaded.
> I am also not sure of the impact of object lifecycle.
What exactly do you mean here?
For example, does a module means that it has an independent bootstrap lifecycle and that
all apps depending on the BV app will reuse the same ValidatorFactory?
5:19 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On May 14, 2012, at 4:57 PM, Emmanuel Bernard wrote:
On 14 mai 2012, at 12:31, Hardy Ferentschik wrote:
>
> On May 14, 2012, at 10:01 AM, Emmanuel Bernard wrote:
>
>> I'm not sure if that should be as classForName or by passing the classloader
but I see the following needs:
>
> The benefit of ClassLoaderService#classForName is that an implementation still could
decide to implement strategies like
> first trying the context and the the current class loader.
You can do the same if a list of classloaders is returned.
Right a list of class loaders would work
>>> From where:
>>
>> - from the user application or from the module depending on BV
>
> I am also trying to understand what a modular environment means for a shared
ValidatorFactory.
> If a user application depends on BV and also uses custom constraints, does it not
mean the application
> would need to build its own ValidatorFactory via
ValidatorFactory#usingContext()#classLoaderService(classLoaderService).
That would sucks balls!
How else do you ensure class visibility (mind you I am just trying to understand how these
environments work)
>> I also wonder if all of this should be masked behind a
contract like your describe, or if the list of classloaders should be exposed to BV and
processed.
>
> How would the latter latter look like?
Something like that
interface ClassloaderService {
/** Return an ordered list of classloaders to load classes and resources.
* BV providers should use these classlaoders in order as this reflect the
* application preference
*/
List<Classloader> getClassloaders();
}
Note that neither your nor my solution differentiate classloading depending on what ought
to be loaded.
On https://hibernate.onjira.com/browse/BVAL-286 I also suggested a
ResourceBundle loadBundle(String bundleName, Locale locale);
But you are right, so far we did not take this up. We could just have the suggested
ClassloaderService#getClassLoaders and
use these class loaders for everything or we decide to already differentiate in the
service itself (e.g. class loading via resource/bundle
loading)
>> I am also not sure of the impact of object lifecycle.
>
> What exactly do you mean here?
For example, does a module means that it has an independent bootstrap lifecycle and that
all apps depending on the BV app will reuse the same ValidatorFactory?
Seems to be similar to my question above. To be honest I am not sure.
--Hardy
5:43 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On 14 mai 2012, at 17:19, Hardy Ferentschik wrote:
>>>>
>>>> From where:
>>>
>>> - from the user application or from the module depending on BV
>>
>> I am also trying to understand what a modular environment means for a shared
ValidatorFactory.
>> If a user application depends on BV and also uses custom constraints, does it not
mean the application
>> would need to build its own ValidatorFactory via
ValidatorFactory#usingContext()#classLoaderService(classLoaderService).
>
> That would sucks balls!
How else do you ensure class visibility (mind you I am just trying to understand how
these environments work)
I'm unclear too. I wish to OSGi semi-gods would step in. But I imagine that OSGi
imposing these string would lead to a custom way to initialize the ValidatorFactory. Some
kind of bootstrapper class at the module level would have to be implemented to wire things
up together. The bootstrapper class would be responsible from providing the
ClassloaderService impl as well as ConstraintValidatorFactory etc.
As I said that's guesstimate on my part but every time I tried to ask this question,
people started to walk the other direction or for the bravest going full stream
theoretical and conceptual ;)
9:06 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
2012/5/14 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 14 mai 2012, at 17:19, Hardy Ferentschik wrote:
>>>>>
>>>>> From where:
>>>>
>>>> - from the user application or from the module depending on BV
>>>
>>> I am also trying to understand what a modular environment means for a shared
ValidatorFactory.
>>> If a user application depends on BV and also uses custom constraints, does it
not mean the application
>>> would need to build its own ValidatorFactory via
ValidatorFactory#usingContext()#classLoaderService(classLoaderService).
>>
>> That would sucks balls!
>
> How else do you ensure class visibility (mind you I am just trying to understand how
these environments work)
I'm unclear too. I wish to OSGi semi-gods would step in. But I imagine that OSGi
imposing these string would lead to a custom way to initialize the ValidatorFactory. Some
kind of bootstrapper class at the module level would have to be implemented to wire things
up together. The bootstrapper class would be responsible from providing the
ClassloaderService impl as well as ConstraintValidatorFactory etc.
That's my understanding of how it should work on OSGi.
The bootstrapper class you're mentioning would be a bundle activator
in OSGi. The bundle and its activator (and thus its class loader)
should be able to see all resources (descriptors, custom constraints
etc.) provided by the application. Within the activator the validator
factory could be bootstrapped (passing the bundle class loader to BV)
and for instance be registered as OSGi service.
If the application is made up of several modules, the activator of
some application module (having dependencies to all other modules and
thus seeing all their exported resources) should be in charge of
bootstrapping the factory.
I thought of simply passing a class loader during bootstrapping like
this (option #3 in Neil Bartlett's post which Hardy mentioned [1]):
ClassLoader cl = obtainRightClassLoaderForLoadingApplicationResources();
Validation
.byDefaultProvider()
.configure()
.userClassLoader( cl )
.buildValidatorFactory();
AFAIU at least in OSGi there should be one CL which is able to load
all user resources (not sure about other modular environments). BV
would use this class loader to load all user provided resources. If no
CL is provided this way the TCCL could be used as fallback.
I'm trying to prototype something along these lines at the moment and
will hopefully be able to report on the findings soon.
--Gunnar
[1] http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
As I said that's guesstimate on my part but every time I tried to ask this question,
people started to walk the other direction or for the bravest going full stream
theoretical and conceptual ;)
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:42 a.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On 14 mai 2012, at 21:06, Gunnar Morling wrote:
If the application is made up of several modules, the activator of
some application module (having dependencies to all other modules and
thus seeing all their exported resources) should be in charge of
bootstrapping the factory.
Can you detail what you mean by that?
Should the application developer write a module that will bootstrap Bean Validation? That
the thing I want to avoid, having the user do useless heavy lifting.
10:51 a.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On May 15, 2012, at 10:42 AM, Emmanuel Bernard wrote:
> If the application is made up of several modules, the activator
of
> some application module (having dependencies to all other modules and
> thus seeing all their exported resources) should be in charge of
> bootstrapping the factory.
Can you detail what you mean by that?
Should the application developer write a module that will bootstrap Bean Validation? That
the thing I want to avoid, having the user do useless heavy lifting.
I think this is what it all comes down to in a modular environment. Once upon a time I
thought you would have one ValidatorFactory within a container and all
modules/apps. But due to class loading and encapsulation of modules/app you effectively
need to create a ValidatorFactory for each module/app.
Is this not also what JBoss AS does? If you deploy an app using for example JPA as per
J2EE spec Bean Validation gets enabled and a ValiatorFactory
gets created.
In the end it is up to the framework providers to make it as simple as possible to use
Bean Validation for modules/apps running within the framework.
All Bean Validation needs to provide is a way to set the class loader.
--Hardy
11:03 a.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
On 15 mai 2012, at 10:51, Hardy Ferentschik wrote:
>>
>> If the application is made up of several modules, the activator of
>> some application module (having dependencies to all other modules and
>> thus seeing all their exported resources) should be in charge of
>> bootstrapping the factory.
>
> Can you detail what you mean by that?
> Should the application developer write a module that will bootstrap Bean Validation?
That the thing I want to avoid, having the user do useless heavy lifting.
I think this is what it all comes down to in a modular environment. Once upon a time I
thought you would have one ValidatorFactory within a container and all
modules/apps. But due to class loading and encapsulation of modules/app you effectively
need to create a ValidatorFactory for each module/app.
Is this not also what JBoss AS does? If you deploy an app using for example JPA as per
J2EE spec Bean Validation gets enabled and a ValiatorFactory
gets created.
s/J2EE/Java EE/
But that's the thing, this EG worked his butt off to make the Java EE integration 100%
transparent for the application developer. And it was up to us
to achieve that and propose things to other EGs.
I am already not certain of what modularity gains you (as user), if on top of that the
development model is subpar to what Java EE can offer, that would be a big drawback.
In the end it is up to the framework providers to make it as simple
as possible to use Bean Validation for modules/apps running within the framework.
All Bean Validation needs to provide is a way to set the class loader.
Sure in the end, we will have a very simple ClassloaderService interface of sort, but
I'd like to understand fully how that will be used to be sure things will be as good
as possible
in a modular environment.
8:27 p.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
2012/5/15 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 15 mai 2012, at 10:51, Hardy Ferentschik wrote:
>>>
>>> If the application is made up of several modules, the activator of
>>> some application module (having dependencies to all other modules and
>>> thus seeing all their exported resources) should be in charge of
>>> bootstrapping the factory.
>>
>> Can you detail what you mean by that?
>> Should the application developer write a module that will bootstrap Bean
Validation? That the thing I want to avoid, having the user do useless heavy lifting.
>
> I think this is what it all comes down to in a modular environment. Once upon a time
I thought you would have one ValidatorFactory within a container and all
> modules/apps. But due to class loading and encapsulation of modules/app you
effectively need to create a ValidatorFactory for each module/app.
>
> Is this not also what JBoss AS does? If you deploy an app using for example JPA as
per J2EE spec Bean Validation gets enabled and a ValiatorFactory
> gets created.
s/J2EE/Java EE/
But that's the thing, this EG worked his butt off to make the Java EE integration
100% transparent for the application developer. And it was up to us
to achieve that and propose things to other EGs.
I am already not certain of what modularity gains you (as user), if on top of that the
development model is subpar to what Java EE can offer, that would be a big drawback.
> In the end it is up to the framework providers to make it as simple as possible to
use Bean Validation for modules/apps running within the framework.
> All Bean Validation needs to provide is a way to set the class loader.
Sure in the end, we will have a very simple ClassloaderService interface of sort, but
I'd like to understand fully how that will be used to be sure things will be as good
as possible
in a modular environment.
As Hardy says, in the end the user needs to provide BV with a class
loader. Thinking of OSGi, I see two ways atm.:
a) The user indeed bootstraps BV (passing the class loader) and
registers VF as OSGi service. This would be done using a bundle
activator roughly like that:
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
ValidatorFactory factory = Validation
.byDefaultProvider()
.providerResolver( new OsgiProviderResolver() )
.configure()
.userClassLoader( Activator.class.getClassLoader() )
.buildValidatorFactory();
context.registerService( ValidatorFactory.class.getName(), factory, null );
}
public void stop(BundleContext context) throws Exception {}
}
AFAICS this would have to be done in the activator of one bundle
(which can "see" all other bundles of the application).
b) The BV provider's OSGi bundle performs the registration of the VF.
The required class loader would be provided via a ClassLoaderService,
for which the user has to register an implementation in his activator:
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
ClassLoaderService cls = new ClassLoaderServiceImpl (
Activator.class.getClassLoader() );
context.registerService( ClassLoaderService.class.getName(), cls, null );
}
public void stop(BundleContext context) throws Exception {}
}
Judging from the lines of code, to me b) looks simpler. As you say
it's not zero-config like in JEE, but - based on my limited knowledge
of the matter - I'm not aware of another (clean) way. In OSGi,
probably there would be some other approaches possible (using
fragments etc.), but AFAIK these are more considered hacks by the
experts.
In both approaches a ValidatorFactory would be available as OSGi
service to be used in application modules, so the complexity would be
restricted to one activator. I don't know how it would work in other
environments (e.g. JBoss modules), but would expect it to be similar.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:39 a.m.
New subject: bv-dev] [BVAL-251] Improve Bean Validation support for modularized environments
Hi,
a friend of mine pointed me to another approach for bootstrapping a
validator factory under OSGi, the "extender pattern" [1].
In that pattern an OSGi bundle can react upon lifecycle events from
other bundles (starting, stopping etc.) and while doing so, also
examine the started/stopped bundle's manifest headers, check for
certain resources etc.
So one could imagine such an extender within a BV provider bundle, which
* examines started application bundles for existence of
META-INF/validation.xml or a custom manifest header marking a bundle
as validation client and
* bootstraps a validation factory when such a bundle is loaded (using
that bundle's class loader).
This significantly reduces the work to be done by the application developer.
I've played with that idea by extending the RI a little bit [2]. I've
defined a custom manifest header,
"Hibernate-Validator-Resource-Bundle" which specifies the names of the
resource bundles to be used by the message interpolator. The extender
within the HV bundle watches for this header and registers a VF if a
bundle is started whose manifest contains that header.
There are also some tests which show the general idea (two OSGi
modules and a test project) [3].
--Gunnar
[1] http://eclipse.dzone.com/articles/osgi-42-extender-pattern-and
[2] https://github.com/gunnarmorling/hibernate-validator/compare/BVAL-251
[3] https://github.com/gunnarmorling/hibernate-validator/compare/BVAL-251#dif...
2012/5/15 Gunnar Morling <gunnar.morling(a)googlemail.com>:
2012/5/15 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 15 mai 2012, at 10:51, Hardy Ferentschik wrote:
>
>>>>
>>>> If the application is made up of several modules, the activator of
>>>> some application module (having dependencies to all other modules and
>>>> thus seeing all their exported resources) should be in charge of
>>>> bootstrapping the factory.
>>>
>>> Can you detail what you mean by that?
>>> Should the application developer write a module that will bootstrap Bean
Validation? That the thing I want to avoid, having the user do useless heavy lifting.
>>
>> I think this is what it all comes down to in a modular environment. Once upon a
time I thought you would have one ValidatorFactory within a container and all
>> modules/apps. But due to class loading and encapsulation of modules/app you
effectively need to create a ValidatorFactory for each module/app.
>>
>> Is this not also what JBoss AS does? If you deploy an app using for example JPA
as per J2EE spec Bean Validation gets enabled and a ValiatorFactory
>> gets created.
>
> s/J2EE/Java EE/
>
> But that's the thing, this EG worked his butt off to make the Java EE integration
100% transparent for the application developer. And it was up to us
> to achieve that and propose things to other EGs.
>
> I am already not certain of what modularity gains you (as user), if on top of that
the development model is subpar to what Java EE can offer, that would be a big drawback.
>
>> In the end it is up to the framework providers to make it as simple as possible
to use Bean Validation for modules/apps running within the framework.
>> All Bean Validation needs to provide is a way to set the class loader.
>
> Sure in the end, we will have a very simple ClassloaderService interface of sort, but
I'd like to understand fully how that will be used to be sure things will be as good
as possible
> in a modular environment.
As Hardy says, in the end the user needs to provide BV with a class
loader. Thinking of OSGi, I see two ways atm.:
a) The user indeed bootstraps BV (passing the class loader) and
registers VF as OSGi service. This would be done using a bundle
activator roughly like that:
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
ValidatorFactory factory = Validation
.byDefaultProvider()
.providerResolver( new OsgiProviderResolver() )
.configure()
.userClassLoader( Activator.class.getClassLoader() )
.buildValidatorFactory();
context.registerService( ValidatorFactory.class.getName(), factory, null );
}
public void stop(BundleContext context) throws Exception {}
}
AFAICS this would have to be done in the activator of one bundle
(which can "see" all other bundles of the application).
b) The BV provider's OSGi bundle performs the registration of the VF.
The required class loader would be provided via a ClassLoaderService,
for which the user has to register an implementation in his activator:
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception {
ClassLoaderService cls = new ClassLoaderServiceImpl (
Activator.class.getClassLoader() );
context.registerService( ClassLoaderService.class.getName(), cls, null );
}
public void stop(BundleContext context) throws Exception {}
}
Judging from the lines of code, to me b) looks simpler. As you say
it's not zero-config like in JEE, but - based on my limited knowledge
of the matter - I'm not aware of another (clean) way. In OSGi,
probably there would be some other approaches possible (using
fragments etc.), but AFAIK these are more considered hacks by the
experts.
In both approaches a ValidatorFactory would be available as OSGi
service to be used in application modules, so the complexity would be
restricted to one activator. I don't know how it would work in other
environments (e.g. JBoss modules), but would expect it to be similar.
--Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:38 a.m.
New subject: [BVAL-286] Class loading service
Issues like this:
https://hibernate.onjira.com/browse/HHH-7084
are caused by a mismatch in how Hibernate choose to handle these
classloading issues versus the way another framework/API did
(GWT/Jetty in this case). I first thought GWT was to blame, but the
issue is more complex. Then you need to start configuring what you
shouldn't and all...
Thread Context ClassLoader is the de facto standard these days. If we
choose to actually defining and allowing classloading to be
customized, the default must be TCCL.
Regards,
Michael
On Mon, May 14, 2012 at 5:18 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On May 14, 2012, at 9:51 AM, Emmanuel Bernard wrote:
> Can you elaborate on the issues that it has brought?
Yeah, I would love to hear more about this as well :-)
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:45 p.m.
New subject: [BVAL-286] Class loading service
On May 18, 2012, at 4:38 AM, Michael Nascimento wrote:
Issues like this:
https://hibernate.onjira.com/browse/HHH-7084
Thread Context ClassLoader is the de facto standard these days. If we
choose to actually defining and allowing classloading to be
customized, the default must be TCCL.
Funny that you that. We had just had an Hibernate Validator issue not so long ago where
a modular system expert told us just the opposite. Don't use TCCL first ;-)
I think the bottom line is that there is no standard. Checking TCCL first and then the
current class loader was a strategy which Hibernate applied for quite some time.
It proved to be a good approach for quite some time. However, the current trend seems to
be
to make the class loading more configurable and allow to for example pass a class loader.
--Hardy
4360
days inactive
4565
days old
beanvalidation-dev@lists.jboss.org
32 comments
7 participants
participants (7)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Jagadish Prasath Ramu -
Kevin Pollet -
Kevin Pollet -
Michael Nascimento