[OGM] When is AssociationKey serialized?
by Gunnar Morling
Hi,
I'm wondering why org.hibernate.ogm.grid.AssociationKey implements
Serializable. When is it actually serialized?
I'm suspecting the answer is "never", as the type of the "metadata" member
is not serializable, so I'd expect a NotSerializableException to be raised.
If so, does anything speak against making AssociationKey not implement
Serializable?
Thanks,
--Gunnar
12 years
Getting notified when session factory is completely set up
by Gunnar Morling
Hi,
Is there a way for services (living in the SF-scoped registry) to get
notified when the session factory has been set up and perform some action
using that completely initialized factory?
Upon invocation of initiateService() of SessionFactoryServiceInitiator
implementations, the passed factory is still under construction (the call
originates from SessionFactoryImpl<init>), so I can't access all members.
The same holds true for the StartStoppable contract in OGM which also sees
a session factory under construction.
Now I could store the passed reference in a field and execute the required
logic (some sort of validation) later on. I only have no meaningful hook to
trigger such action exactly once. So I'd have to manage a flag to make sure
the action is only performed once.
Is there a better way to achieve this?
Would it make sense to provide an additional contract to notify services
about session factory lifecycle events:
public interface SessionFactoryLifecycleAware extends Service {
void onSessionFactoryLifecycleEvent(SessionFactoryImplementor sfi,
Event event);
public enum Event { POST_START, PRE_STOP }
}
?
Thanks,
--Gunnar
12 years
Fwd: [OGM] Public packages of datastore modules
by Davide D'Alto
> a) it adds many empty packages which seem user-exposed but actually
aren't (org.hibernate.ogm.logging, org.hibernate.ogm.logging.
mongodb) and b) it makes it cumbersome to structure impl-internal stuff
into sub-packages (have a look at the CouchDB module [1] to see what I
mean).
I think I've missed it, what is it your suggestion for internal packages?
On Mon, Feb 10, 2014 at 4:09 PM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
> On 10 February 2014 14:52, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > 2014/2/10 Sanne Grinovero <sanne(a)hibernate.org>
> >>
> >> On 10 February 2014 12:32, Davide D'Alto <daltodavide(a)gmail.com> wrote:
> >> > I can work on this today and start to plan the release for Wednesday.
> >> >
> >> > I don't think this change should block the next release though.
> >> >
> >> > It would also be nice to include this:
> >> > https://github.com/hibernate/hibernate-ogm/pull/282
> >> > so that people can actually use the enitty manager to create queries
> >> >
> >> >
> >> >
> >> > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling
> >> > <gunnar(a)hibernate.org>wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> One thing I'd like to address before doing the next OGM release is
> the
> >> >> structure of public packages in the datastore-specific modules.
> >> >>
> >> >> Currently we have the following structure:
> >> >>
> >> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
> >> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
> >> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
> >> >> ...
> >> >>
> >> >> I think it makes sense to pull the datastore-specific package up one
> >> >> level,
> >> >> moving all the types of a backend under one shared super-package. So
> it
> >> >> would like this instead:
> >> >>
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
> >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
> >> >> ...
> >> >>
> >> >> The reason I'm bringing this up is that we're introducing new
> >> >> user-exposed
> >> >> types with that release: the store identifier types (MongoDB, CouchDB
> >> >> etc.)
> >> >> and their properties class (MongoDBProperties, CouchDBProperties
> etc.).
> >> >> So
> >> >> if we agree to do this change it would be good to do it now before
> >> >> having
> >> >> to move these public types later on.
> >>
> >> Since you mention users as a reason for this change, I've to admit
> >> that I don't see how it helps users.
> >> Personally I think it's quite helpfull to have the package to help me
> >> quickly identify which dialects I have available;
> >
> >
> > That's my thinking as well, but how do the intermediary "datastore",
> > "dialect" etc. packages (at a higher level than the actual datastore
> > package) help to achieve this?
> >
> > To me, packages should be organized by the most important criteria first,
> > and that's IMO the type of datastore here. Thus I think it should be
> > org.hibernate.ogm.mongodb.* for everything MongoDB instead of
> > org.hibernate.ogm.*.mongodb. Why have these rather technical packages in
> > between?
>
> I understand that you like that better, but we need to figure if
> that's an objective statement: dialects in Hibernate ORM don't work
> like that, and people are used to the current approach:
>
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch03.html#confi...
>
> My impression is that ORM users are familiar with the concept of
> "dialect", hence they know they are searching for a dialect which does
> make it quite straight forward to go for something in
>
> org.hibernate.dialect
>
> For example it's
> > org.hibernate.dialect.H2Dialect
> and not
> > org.hibernate.h2.Dialect
> and also it's not
> > h2.dialect.hibernate
>
> I realize the ORM is slightly different as it has just one class,
> still that's what people are used to in terms of dialects.
>
> "most important criteria first, as you say.." ;-)
>
> Maybe 100% of our users would disagree with the ORM naming choice if
> asked about it, but I've seen no complains so either that's not true
> or nobody cares enough, which is why I'm still not persuaded on this
> being worth of our time to change.
>
> Sanne
>
>
>
> >
> > Also I'm trying to expose as less packages and types to the user as
> > possible. So e.g. I'd like to put the dialect identifier type from the
> > option API straight into a backend's root package, e.g.
> > org.hibernate.ogm.mongodb.MongoDB. With the current approach that's not
> > possible, in between there is the org.hibernate.ogm.datastore package
> (which
> > itself is empty for all the datastore modules).
> >
> >>
> >> we should also
> >> expect potentially to have sub-types in the future like
> >>
> >> org.hibernate.ogm.datastore.infinispan.local
> >> org.hibernate.ogm.datastore.infinispan.clusterable
> >> org.hibernate.ogm.datastore.cassandra.embedded
> >>
> >> Since I don't see a value advantage in changing the packages, I'll
> >> side with the "resistance against change" party, unless you share some
> >> compelling argument of course :-)
> >>
> >> the "logging" case is different: that's a private package so we might
> >> want to highlight that in the package structure.
> >
> >
> > Agreed, that's caused by the current rule of putting the "impl" packages
> at
> > the bottom of the tree. So actually the complete logging package
> currently
> > is org.hibernate.ogm.logging.mongodb.impl.
> >
> > I dislike this pattern for several reasons, a) it adds many empty
> packages
> > which seem user-exposed but actually aren't (org.hibernate.ogm.logging,
> > org.hibernate.ogm.logging.mongodb) and b) it makes it cumbersome to
> > structure impl-internal stuff into sub-packages (have a look at the
> CouchDB
> > module [1] to see what I mean).
> >
> > So far I couldn't convince Emmanuel to let go of this pattern, though ;)
> In
> > HV we did the split at the top-most level (i.e. everything not
> user-exposed
> > is under org.hibernate.validator.internal), and IMO that works much
> better
> > than the current approach in OGM.
> >
> >> >> Another question is how to differentiate between public and internal
> >> >> packages, but I think we can discuss this later on, as a change would
> >> >> only
> >> >> affect internal packages. Emmanuel and I couldn't agree on a best
> >> >> approach
> >> >> when discussing it shortly, so this might need some more time :)
> >> >>
> >> >> Any thoughts?
> >>
> >> I'd move things to .impl for the private ones, leaving all others as
> >> they are. That should also simplify for example a filtering rule for
> >> the javadoc generation.
> >
> >
> > Move in which way exactly, do you suggest to have one "impl" package or
> > many?
> >
> > --Gunnar
> >
> > [1]
> >
> https://github.com/hibernate/hibernate-ogm/tree/master/couchdb/src/main/j...
> >
> >
> >>
> >>
> >> -- Sanne
> >>
> >> >>
> >> >> --Gunnar
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev(a)lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
12 years, 1 month
[OGM] Public packages of datastore modules
by Gunnar Morling
Hi,
One thing I'd like to address before doing the next OGM release is the
structure of public packages in the datastore-specific modules.
Currently we have the following structure:
* org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...>
* org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...>
* org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...>
...
I think it makes sense to pull the datastore-specific package up one level,
moving all the types of a backend under one shared super-package. So it
would like this instead:
* org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore
* org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect
* org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging
...
The reason I'm bringing this up is that we're introducing new user-exposed
types with that release: the store identifier types (MongoDB, CouchDB etc.)
and their properties class (MongoDBProperties, CouchDBProperties etc.). So
if we agree to do this change it would be good to do it now before having
to move these public types later on.
Another question is how to differentiate between public and internal
packages, but I think we can discuss this later on, as a change would only
affect internal packages. Emmanuel and I couldn't agree on a best approach
when discussing it shortly, so this might need some more time :)
Any thoughts?
--Gunnar
12 years, 1 month
RESTEasy, CDI, embedded Jetty, bean validation is ignored
by Abhijit Sarkar
Hi,
I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to
embedded Jetty. What I can't seem to get working is bean validation. The
documentation says that adding 'resteasy-validator-provider-11' along with
hibernate validator dependencies (hibernate-validator,
hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean
validation is simply ignored. I curiously also get the following message in
the logs:
plugins.validation.ValidatorContextResolver - Unable to find CDI supporting
ValidatorFactory. Using default ValidatorFactory
I tried registering Hibernate InjectingConstraintValidatorFactory in
META-INF/validation.xml but it depends on a BeanManager being injected and
blows up at runtime.
I've tried everything under the sun without any success. What can I do to
get this working? The code can be found here
https://github.com/abhijitsarkar/groovy/tree/master/movie-manager/movie-m...
A log gist is here: https://gist.github.com/anonymous/8947319
RESTEasy 3.0.6.Final
Weld servlet 2.1.2.Final
Hibernate validator 5.0.3.Final
Jetty embedded 9.1.1.v20140108
Regards,
Abhijit
12 years, 1 month
New unified XML handling
by Steve Ebersole
Gail, et al.
I am starting to integrate the new unified XML handling into the process of
building a Metadata object. Logically this sits at the level of "source
processing" (source package). The concept of a MetadataSourceProcessor is
kind of obsolete because there is just one process to apply (annotations
+xml-overrides & metadata-complete-xml).
Because the output of this unified process is a Jandex index, one option is
to replace "source" with direct Jandex. Another option is to keep "source"
and have it be a wrapper around Jandex. This second option is likely
quicker turnaround since we can mostly reuse the annotation source
processor code. Also, wrapping the Jandex calls this ways lets us apply
some simplification of the questions we ask of the data. Not to mention it
would probably be a good idea to encapsulate as much as possible this
reliance on external libs. There are some concerns to this approach though
to my mind. My main concern is performance, as this requires us to
instantiate all the "source" wrappers around Jandex.
What do y'all think?
12 years, 1 month
API/SPI in 5.0
by Steve Ebersole
As we transition to 5.0 we have to make a lot of decisions wrt API/SPI
methods that are no longer relevant. I think it is better to look at
these individually.
== Configuration
I went ahead and made a preliminary decision here as I discussed in
HHH-7164. The thinking is that we had some leeway here because
Configuration had been deprecated (and pretty widely known to be
deprecated based on StackOverflow and other sources). Basically I made
Configuration a simple delegate to the new Metadata building code. I
removed all the methods that exposed access to the org.hibernate.mapping
objects that Configuration used to manage.
---
== Integrator
This one is a little tougher. In retrospect I think I would have just
gone for a number of discrete contributor contracts. For example,
usually Integrator is used to add event listeners, so an
EventListenerContributor would have worked. Then I would have used
Integrator as a grouping of contributors.
== PersisterFactory (and persister constructors)
Forms taking Configuration and org.hibernate.mapping objects should,
imo, get removed. But I can live with deprecation if someone wants to
"pound the table" for that. But realize that the
Configuration+org.hibernate.mapping forms would not be called ever.
12 years, 1 month
Building the unified (orm.xml with Hibernate extensions) mapping schema
by Steve Ebersole
With HHH-8893[1] I am working on building the unified XSD for mapping
information. I have mentioned this a few times. HHH-8894[2] is related to
this.
Part of HHH-8894 is this idea to handle legacy hbm.xml documents as if they
were defined using this new XSD. Initially I had planned on using XSLT to
manage this. And in fact I started writing it as I was adding the
Hibernate extensions to the new unified XSD.
The "problem" is that XSLT is "not my thing". And so while some folks
could probably whip together the XSLT to accomplish this is a short time, I
find it taking me quite a long time. Not to mention that when it comes to
debugging problems with these transformations, I will be even more lost.
So I got to thinking about alternatives. Ultimately we are dealing with
JAXB. So we have a nice object model for these schemas (currently for the
standard JPA orm.xml schema and for the hbm.xml schema, I'll build the
"unified" one as I develop). The thought that occurred to me was to
leverage these 2 models to perform the transformation:
1) Read the hbm.xml and bind to its JAXB model
2) Walk this bound model and start building the unified mapping JAXB model
This still facilitates both of the usages I wanted from XSLT. In terms of
a build-time tool, we'd do the above steps and right the unified mapping
out to file. In terms of on-the-fly translation, well, we have the unified
mapping JAXB model, we'd just use it.
WDYT? If anyone feels very strongly about using XSLT for this, I am happy
to accept help :)
[1] https://hibernate.atlassian.net/browse/HHH-8893
[2] https://hibernate.atlassian.net/browse/HHH-8894
12 years, 1 month
