Hibernate Validator 6.0.7.Final released
by Guillaume Smet
Hi,
We just released Hibernate Validator 6.0.7.Final.
It adds a new @ISBN constraint and benefits from our latest performance
improvements.
It is based on the Bean Validation 2.0.1.Final API, which fixes a small
regression (that you shouldn't encounter in a standard usage of Bean
Validation).
Happy holidays to everyone!
--
Guillaume
8 years
Keeping CI from being confusing.
by Sanne Grinovero
I see many jobs are still explicitly configured to request a build on
slaves tagged as "OS1".
Please get rid of that: we have no longer any slave running on OS1,
some of the new slaves use the "OS1" label to allow a smooth migration
- but it's a lie and it's been a long time since we removed OS1.
I will need to eventually cleanup such things, as it's getting messy
and confusing.
Labels are expected to be used to tag specific slaves to have specific
capabilities, so that some jobs can flag they require such
capabilities.
Typically the only label you need is "Slave" as we don't want most
jobs to run on the master node.
An example of a valid label is "HANA" for the job running integration
tests on the HANA database; for obvious reasons this job needs to be
run on the only slave actually having HANA running.
While at it, if you installed any Jenkins plugin which you no longer
need please remove it.
General reminder: there's no dedicated team to keep CI or
infrastructure running efficiently, we're all responsible so try to
dedicate it some 20 minutes every month making sure your jobs are
still necessary and configurations are up to date.
For more extensive operations ask Davide or myself and we'll see to help.
Thanks,
Sanne
8 years
Interceptors and dependency injection
by Guillaume Smet
Hi all (and Steve especially as it seems you are working on the
subject right now),
You talking about CDI made me think of something we did at
$previousJob a long time ago.
I didn't quite follow what you did in 6 about CDI/Spring injection but
basically the requirement was to be able to create Spring managed
interceptors and to inject them in the PersistenceProvider.
At the time, we ended up with the following:
https://github.com/openwide-java/owsi-core-parent/blob/master/owsi-core/o...
But I think it would probably be nice if we could inject them directly.
Another thing we did which is not really related is creating a
ChainedInterceptor to be able to define several interceptors (the idea
was that we did want the ability to enable some interceptors at will
depending on what a given application required).
Just injecting the interceptors in a random order would probably not
do it as I think you will probably want to define them in an ordered
way.
Not sure it's useful but I thought I might as well talk about it now
that you are working on this feature.
Have a nice day.
--
Guillaume
8 years
Killing hibernate-jpa-api ?
by Sanne Grinovero
Looks like the general agreement is that we will no longer need
- https://github.com/hibernate/hibernate-jpa-api
As we're switching to the standard API distribution, finally available:
javax.persistence:javax.persistence-api:2.2
Still I expect there's going to be some confusion about this, e.g.
Scott was asking today in chat where to find our custom API at
versions 2.2.
I'd like to deploy a relocation artifact so that people merely
upgrading the version to 2.2 of their dependency to
org.hibernate.javax.persistence will get an automated warning and be
nicely redirected to the new artifact.
Any objections?
The one problem I can see is that in case we need to patch it we'd
need to restore the org.hibernate.javax.persistence and it might get
messy, but I think we can agree the chance for this need to arise
being extremely small.
Thanks,
Sanne
8 years, 1 month
HHH-12146 - subclass-specific caching
by Steve Ebersole
HHH-12146 is about being able to enable/disable caching at various levels
in an entity hierarchy. E.g., given a hierarchy such as `Person` and
`Company` both extending `LegalEntity`, this would allow users to say that
only `Company` should be cached but not `Person` nor any other
`LegalEntity` subclass.
The underlying approach here is to still define region and access-strategy
information per-hierarchy - users will simply be able to opt out of (or
into) caching particular subclasses. In my initial attempt I simply
allowed both `@Cache` and `@Cacheable` to appear anywhere in the
hierarchy. However, allowing `@Cache` (as currently defined) implies that
users should be able to define different regions and/or access strategies
for various subclasses within the hierarchy. Stepping back, I thought a
better solution would be to continue to support `@Cache` only at the root
level and define this new feature in terms of `@Cacheable` at the various
levels. This has a few implications that I wanted to discuss.
The main thing is that this means that applications using just `@Cache` to
define caching would still only be able to declare caching for the entire
hierarchy. But I think that is ok because that was the legacy behavior,
and so nothing is really changing there. If we find `@Cache` on the root
we'd assume an implicit `@Cacheable(true)`. I think some examples will
help explain...
Current behavior
@Inheritance(...)
@Cache(...)
abstract class LegalEntity {
...
}
class Person extends LegalEntity {
...
}
class Company extends LegalEntity {
...
}
In the current behavior both `@Cache` and `@Cacheable` are only valid on
the root as seen above. Placing them on any subclass results in an error.
Note too that we could have used `@Cacheable` here instead of `@Cache` in
which case the default `@Cache` values would be applied. It was also legal
to use both together. In fact, a portable application would use
`@Cacheable` with or without `@Cache`.
Proposed behavior
@Inheritance(...)
@Cache(...)
@Cacheable(false)
abstract class LegalEntity {
...
}
class Person extends LegalEntity {
...
}
@Cacheable(true)
class Company extends LegalEntity {
...
}
Here we have the root disabling caching (assuming
`SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting.
`Company` however overrides that to enable caching. We still have
`@Cache` attached to the root to define the specifics of caching (region,
access strategy). But as noted earlier, we could have left off `@Cache`
and accepted the defaults.
I also propose that we continue to accept `@Cache` (without explicit
`@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode`
plays a part in that too.
Anyway, I wanted to make sure everyone agrees with this.
8 years, 1 month
Geospatial types/queries and OGM
by Guillaume Smet
Hi,
So here is how the MongoDB geospatial support looks like currently:
https://github.com/hibernate/hibernate-ogm/tree/master/mongodb/src/main/j...
So basically, moving to JTS would have the following benefits and drawbacks:
+ we can remove these types from OGM
+ we are consistent with the current spatial support of ORM (note that
there is also work on spatial4j which is different from JTS and apparently
they are talking about a JTS 2 API that would be different from the current
API)
+ you have the whole JTS API at hand
- the JTS API for creating shapes is not very user friendly: you have to
define a precision model and a SRID - which are of no use for MongoDB, you
have to pass an array of points to create a polygon and things like that -
it sure works but it's not very user friendly and looks like a 1990s API
- we end up adding a 800 kB jar for something really simple: I don't really
think people will use the JTS advanced features in conjunction with MongoDB
- we will have to add a helper API for allowing the users to convert easily
a shape to a BSON document (currently, it's included in the Geo* classes)
- we won't be able to support GeometryCollection as the only thing
available in the JTS API is the list of coordinates of the shapes, you
can't access the types of the shapes (which are needed for the GeoJSON
version of GeometryCollection) - full disclosure: I haven't added
GeometryCollection support yet in what I did (I created an issue suitable
for new contributors to have an easy task suitable for a potential
contributor)
So all in all, I'm not convinced it's such a good move.
--
Guillaume
8 years, 1 month
