PDFs generated for Hibernate 4.1 documentation
by Philip Schlesinger
Hi all,
Per the recommendation of Sanne Grinovero, I'm posting here. Please
see the ticket I created
https://hibernate.onjira.com/browse/WEBSITE-16
-- title "Generate, validate, and publish PDF versions of Hibernate
4.1 documentation".
I've attached three PDFs to that ticket, one for each of the Hibernate
4.1 documents. I made them landscape 8.5x14 so the tables would fit.
If somebody can do this better as 8.5x11 and/or in portrait, be my
guest...
Sanne commented: "This is nice to have but will be outdated soon, the
best solution would be if you could patch the build system to provide
a task to generate them. I would suggest you to drop an email to the
hibernate developer mailing list [1] to make sure the whole team
notices this; I don't think everyone receives notifications about the
"website" project."
Steve Ebersole commented: "The "Getting Started Guide" at least cannot
be done in PDF; it links to a zip file (see 2. Tutorial code). Sanne,
Phillip and I talked about this on IRC. Really we need someone to help
with jDocBook and especially the integration with FOP (how DocBook is
converted into PDF). Phillip unfortunately does not know FOP."
- Phil
--
Philip H. Schlesinger
Software Development Manager, PICS, Inc.
P: (949) 936-4508
P: (714) 409-3105
The Contractors' Choice
17701 Cowan #140 | Irvine, CA | 92614
Join PICS on LinkedIn
13 years, 10 months
WEBSITE-16
by Sanne Grinovero
Hi all,
I just received a notification about the creation of $subject on JIRA.
I also find PDF documentation very useful and find myself often
downloading them to forward them to my Kindle.
(So an ebook format would be even better than a PDF)
Why does ORM not build PDF documentation?
Regards,
Sanne
13 years, 10 months
Re: [hibernate-dev] XML to Relational mapping
by Steve Ebersole
Again my mail client deciding to use the wrong reply address. Ugh,
sorry.
On Mon 15 Oct 2012 07:48:23 PM CDT, Steve Ebersole wrote:
> It was just never really finished. It had lots of "holes". And no
> one ever stepped up to take it on.
>
> On Sun 14 Oct 2012 02:11:11 AM CDT, Claude Mamo wrote:
>> Hi,
>>
>> We have a project where we have have to map an XML document to a
>> relational model. I've discovered that with Hibernate 3 you could do
>> this via the EntityMode.DOM4J. Unfortunately, the feature was removed in
>> Hibernate 4 (https://hibernate.onjira.com/browse/HHH-6879). I know the
>> feature was experimental, however, are there other reasons for removing
>> this feature? For example, was it implemented inefficiently?
>>
>> Thanks,
>>
>> Claude
>>
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
Re: [hibernate-dev] [HSearch] ServiceManager and services
by Hardy Ferentschik
On 12 Jan 2012, at 3:00 PM, Steve Ebersole wrote:
> "Java services api" == ServiceLoader I assume?
correct
> Going on that assumption:
>
> No. ServiceLoader is just a discovery mechanism. There still needs to be something that, as you say, negotiates amongst the various discovered implementations of a particular service. 2 well known ServiceLoader uses are JDBC drivers and image processors, each illustrating a different approach that are really inherent to their respective problem domains. In the case of JDBC drivers, the discovery is just used to register all the available drivers; users must still specify which driver they want via JDBC url protocol. In the case of image processing (as I understand it anyway, not really my forte) the choice of processor is more intrinsic to the image you ask to have processed based on MIME type.
>
> Here is sound like you more have the JDBC style, where discovery is just making the complete set of possibilities known. The user would still need to make a distinction. Or maybe you have some special rules like (a) using the standard service if it is the only one discovered; (b) using the "other" service if 2 are discovered; (c) requiring the user tell you if 3 or more are found. Many ways to skin that cat.
Right. I would expect the user to make this distinction via the configuration.
I think really the problem is that what we have is actually not a ServiceManager (at least not what I understand under this term). It is a fancy way to instantiating a class and giving it a life cycle (aka #start(), #stop()).
We really have more of a BeanLifeCycleManager.
--Hardy
13 years, 10 months
Connection release mode and Session.connection() deprecation
by Steve Ebersole
Was thinking some more today about the deprecation of Session.connection()
The reason we deprecated it was that we need a way to scope access to
the Connection because Session may have to release it due to "release
mode". The back story here is that we added "connection release mode"
as a way to fix an earlier problem using Hibernate in certain
container-managed-transaction scenarios involving nested bean calls
where they both used the same Session but the nested bean forced the
session to obtain a Connection first. Hibernate tries to delay
obtaining the JDBC Connection until needed. However, in the stated
scenario that leads to a situation where the container managing the
transaction sees a Connection "leaking" from the nested bean call since
it was the one that forced the Connection to be obtained from the
DataSource. The solution to this back then was to have Hibernate
release the Connection whenever it was done using it for the moment in
JTA cases. In retrospect, I think a much cleaner solution to the above
situation is to force the Session to obtain the Connection up front
rather than this obtain/release as-needed cycle.
So as one more attempt to save Session.connection() from going away, I
wanted to propose that we drop the notion of "release mode" in favor of
simply saying whether or not to aggressively acquire the Connection when
the Session starts. Then all of the concerns that made deprecating and
planning on removing Session.connection() are no longer there.
WDYT?
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
Re: [hibernate-dev] hibernate-dev Digest, Vol 76, Issue 18
by Marc Schipperheyn
I have setup a jobs alternative on www.freelas.net. Right now we focus
mainly on the Dutch and Brazilian markets but you can always publish jobs
without a location.
You can find a direct link to the English version here:
http://www.freelas.net/nederland/NL_e<http://www.freelas.net/nederland/NL_nl>
n/
and a link to the Hibernate jobs section here:
http://www.freelas.net/nederland/NL_en/account/tag/hibernate/355/<http://www.freelas.net/nederland/NL_nl/account/tag/hibernate/355/>
and
Hibernate Search section here:
http://www.freelas.net/nederland/NL_en/account/tag/hibernate_search/483/<http://www.freelas.net/nederland/NL_nl/account/tag/hibernate_search/483/>
The good thing about this site: it's built with Hibernate and Hibernate
Search :-)
Anyway, not intended as a spam promotion of the site but as a response to
the jobs section message. I'd be happy to process suggestions.
Marc
On Wed, Oct 10, 2012 at 9:55 AM, <hibernate-dev-request(a)lists.jboss.org>wrote:
> Send hibernate-dev mailing list submissions to
> hibernate-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
> hibernate-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> hibernate-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Links to CI jobs on hibernate.org (Hardy Ferentschik)
> 2. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
> 3. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
> 4. Re: Hibernate Search Spatial: Units? (Emmanuel Bernard)
> 5. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
> 6. Re: Bytecode enhancement (Steve Ebersole)
> 7. Re: Bytecode enhancement (Steve Ebersole)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Oct 2012 11:03:26 +0200
> From: Hardy Ferentschik <hardy(a)hibernate.org>
> Subject: Re: [hibernate-dev] Links to CI jobs on hibernate.org
> To: Hibernate <hibernate-dev(a)lists.jboss.org>
> Message-ID: <2640B82F-21F6-41F4-8F40-6C5F4018BCA2(a)hibernate.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 9 Jan 2012, at 7:44 PM, Steve Ebersole wrote:
>
> > Gunnar,
> >
> > Do you mean in the menu option? That's seems to be from whoever last
> > updated the CI information. Hardy?
>
> Might have been me. Once I was young and ambitious and thought we could
> sort this mess out.
> By now I gave up on these jobs.
>
> Any news regarding alternatives?
>
> --hardy
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Oct 2012 10:31:19 +0100
> From: Sanne Grinovero <sanne(a)hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Nicolas Helleringer <nicolas.helleringer(a)gmail.com>
> Cc: Hibernate <hibernate-dev(a)lists.jboss.org>
> Message-ID:
> <CAFm4XO0Fh_bq2G=
> b2zvhP0WX3oROu-xW1HvhBBWytZxdEYCCjw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> The default name for @Spatial is the empty string (at least as defined
> on the annotation before we override it to the entity mode).
>
> Considering we have @Spatials (plural) to support multiple coordinates
> on a single entity, would it make sense to support
>
> onCoordinates(String... names)
> ?
>
> This has the nice effect of supporting the method without any
> parameter, so one can use
>
> Query luceneQuery = builder.spatial()
> .onCoordinates()
> .within( 50, Unit.KM )
> ...
>
> to point to the default one (undefined, aka empty string)
>
> Can also target multiple constraints at once:
>
> Query luceneQuery = builder.spatial()
> .onCoordinates( "home", "office" )
> .within( 50, Unit.KM )
> ...
>
> Looks not so good when mixing default and specific:
>
> Query luceneQuery = builder.spatial()
> .onCoordinates( "", "office" )
> .within( 50, Unit.KM )
> ...
>
> But my guess is that when having multiple coordinates on an entity it
> should be recommended to name them all explicitly; we could even
> require this.
> --
>
> +1 to not consider
> "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> case I think we should update the tests using it to use the DSL.
>
> Sanne
>
> On 10 October 2012 08:44, Nicolas Helleringer
> <nicolas.helleringer(a)gmail.com> wrote:
> > 5 seems just fine to me
> >
> > Niko
> >
> > 2012/10/10 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >>
> >> I see a few options:
> >>
> >> 1. Make onCoordinates optional
> >>
> >> For me that does not look right and would make the dsl confusing but I'd
> >> like to see additional feedback
> >>
> >> 2. Use a constant
> >>
> >> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
> >>
> >> 3. Use the class name ( that's what you did )
> >>
> >> 4. Use "" as the value
> >>
> >> .onCoordinates("")
> >>
> >> 5. Add a specific method
> >>
> >> .onDefaultCoordinates()
> >>
> >> So far 5 seems the most natural to me.
> >>
> >> Emmanuel
> >>
> >>
> >> On 10 oct. 2012, at 09:20, Nicolas Helleringer
> >> <nicolas.helleringer(a)gmail.com> wrote:
> >>
> >> This makes sense.
> >> The DSL is clearly THE way to build spatial queries. It simple and
> >> elegant.
> >>
> >> By the way, Emmanuel, I would like some help to remove the
> >> .onCoordinates( PoI.class.getName() )
> >>
> >> in
> >>
> >> Query luceneQuery = builder.spatial()
> >> .onCoordinates( PoI.class.getName() )
> >> .within( 50, Unit.KM )
> >> .ofLatitude( centerLatitude )
> >> .andLongitude( centerLongitude )
> >> .createQuery();
> >>
> >> when building a spatial query on a class with a @Spatial that does not
> >> have a name attribute set and thus using the default value of
> >> class.getName()
> >>
> >> Niko
> >>
> >>
> >> 2012/10/10 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >>>
> >>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
> >>> should be an internal class. Do we want to offer direct access to these
> >>> instead of the dsl?
> >>> The answer could be yes, but I'd like to see a use case.
> >>>
> >>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> >>>
> >>> > Hi Nicolas,
> >>> >
> >>> > In the QueryBuilder DSL a spatial Query has a nice option to define
> >>> > which units are being used:
> >>> >
> >>> > org.apache.lucene.search.Query luceneQuery =
> >>> > builder.spatial().onCoordinates( UserRange.class.getName() )
> >>> > .within( 50, Unit.KM ).ofLatitude( centerLatitude
> >>> > ).andLongitude(
> >>> > centerLongitude ).createQuery();
> >>> >
> >>> >
> >>> >
> >>> >
> org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
> >>> > double, double, String)
> >>> > has a javadoc comment specifying the parameters are expected to be
> KM.
> >>> >
> >>> > I guess we should pick a strategy and be consistent with it; I think
> >>> > we should add the Unit parameter to the SpatialQueryBuilder;
> >>> >
> >>> > Any thoughts about it? Can I assume you'll be able to look into that?
> >>> >
> >>> > Cheers,
> >>> > Sanne
> >>> >
> >>> > Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 10 Oct 2012 10:52:44 +0100
> From: Sanne Grinovero <sanne(a)hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Nicolas Helleringer <nicolas.helleringer(a)gmail.com>
> Cc: Hibernate <hibernate-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAFm4XO26cB4MFc_FBOfkrJrvTKeF6Fet6s3LggDMwxyk0B2Q5w(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 10 October 2012 10:31, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> > The default name for @Spatial is the empty string (at least as defined
> > on the annotation before we override it to the entity mode).
> >
> > Considering we have @Spatials (plural) to support multiple coordinates
> > on a single entity, would it make sense to support
> >
> > onCoordinates(String... names)
> > ?
> >
> > This has the nice effect of supporting the method without any
> > parameter, so one can use
> >
> > Query luceneQuery = builder.spatial()
> > .onCoordinates()
> > .within( 50, Unit.KM )
> > ...
> >
> > to point to the default one (undefined, aka empty string)
> >
> > Can also target multiple constraints at once:
> >
> > Query luceneQuery = builder.spatial()
> > .onCoordinates( "home", "office" )
> > .within( 50, Unit.KM )
> > ...
> >
> > Looks not so good when mixing default and specific:
> >
> > Query luceneQuery = builder.spatial()
> > .onCoordinates( "", "office" )
> > .within( 50, Unit.KM )
> > ...
> >
> > But my guess is that when having multiple coordinates on an entity it
> > should be recommended to name them all explicitly; we could even
> > require this.
> > --
> >
> > +1 to not consider
> > "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> > case I think we should update the tests using it to use the DSL.
>
> About this, we should also not mention it in the docs: we're using it
> in most examples, excluding only the paragraph introducing the Spacial
> specific DSL.
> We also refer to it frequently in 9.6, the low level details
> explanation chapter.
>
> >
> > Sanne
> >
> > On 10 October 2012 08:44, Nicolas Helleringer
> > <nicolas.helleringer(a)gmail.com> wrote:
> >> 5 seems just fine to me
> >>
> >> Niko
> >>
> >> 2012/10/10 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >>>
> >>> I see a few options:
> >>>
> >>> 1. Make onCoordinates optional
> >>>
> >>> For me that does not look right and would make the dsl confusing but
> I'd
> >>> like to see additional feedback
> >>>
> >>> 2. Use a constant
> >>>
> >>> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
> >>>
> >>> 3. Use the class name ( that's what you did )
> >>>
> >>> 4. Use "" as the value
> >>>
> >>> .onCoordinates("")
> >>>
> >>> 5. Add a specific method
> >>>
> >>> .onDefaultCoordinates()
> >>>
> >>> So far 5 seems the most natural to me.
> >>>
> >>> Emmanuel
> >>>
> >>>
> >>> On 10 oct. 2012, at 09:20, Nicolas Helleringer
> >>> <nicolas.helleringer(a)gmail.com> wrote:
> >>>
> >>> This makes sense.
> >>> The DSL is clearly THE way to build spatial queries. It simple and
> >>> elegant.
> >>>
> >>> By the way, Emmanuel, I would like some help to remove the
> >>> .onCoordinates( PoI.class.getName() )
> >>>
> >>> in
> >>>
> >>> Query luceneQuery = builder.spatial()
> >>> .onCoordinates( PoI.class.getName() )
> >>> .within( 50, Unit.KM )
> >>> .ofLatitude( centerLatitude )
> >>> .andLongitude( centerLongitude )
> >>> .createQuery();
> >>>
> >>> when building a spatial query on a class with a @Spatial that does not
> >>> have a name attribute set and thus using the default value of
> >>> class.getName()
> >>>
> >>> Niko
> >>>
> >>>
> >>> 2012/10/10 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >>>>
> >>>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
> >>>> should be an internal class. Do we want to offer direct access to
> these
> >>>> instead of the dsl?
> >>>> The answer could be yes, but I'd like to see a use case.
> >>>>
> >>>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
> >>>>
> >>>> > Hi Nicolas,
> >>>> >
> >>>> > In the QueryBuilder DSL a spatial Query has a nice option to define
> >>>> > which units are being used:
> >>>> >
> >>>> > org.apache.lucene.search.Query luceneQuery =
> >>>> > builder.spatial().onCoordinates( UserRange.class.getName() )
> >>>> > .within( 50, Unit.KM ).ofLatitude( centerLatitude
> >>>> > ).andLongitude(
> >>>> > centerLongitude ).createQuery();
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
> >>>> > double, double, String)
> >>>> > has a javadoc comment specifying the parameters are expected to be
> KM.
> >>>> >
> >>>> > I guess we should pick a strategy and be consistent with it; I think
> >>>> > we should add the Unit parameter to the SpatialQueryBuilder;
> >>>> >
> >>>> > Any thoughts about it? Can I assume you'll be able to look into
> that?
> >>>> >
> >>>> > Cheers,
> >>>> > Sanne
> >>>> >
> >>>> > Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
> >>>> > _______________________________________________
> >>>> > hibernate-dev mailing list
> >>>> > hibernate-dev(a)lists.jboss.org
> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>>
> >>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 10 Oct 2012 13:17:32 +0200
> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Sanne Grinovero <sanne(a)hibernate.org>
> Cc: Hibernate <hibernate-dev(a)lists.jboss.org>
> Message-ID: <20121010111732.GA1075(a)dhcp-193-234.cdg.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> > > onCoordinates(String... names)
>
> Does `onCoordinates()` means all coordinates or simply the default one. If
> all, then
> existing queries will break if you add an new coordinate property to an
> entity.
>
> Also, I'm not sure there is a use case for targeting in the same query,
> the various coordinates defined on a given entity. But I have no real
> idea.
>
> Otherwise, I'm fairly neutral to the proposal.
>
> > > +1 to not consider
> > > "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> > > case I think we should update the tests using it to use the DSL.
> >
> > About this, we should also not mention it in the docs: we're using it
> > in most examples, excluding only the paragraph introducing the Spacial
> > specific DSL.
> > We also refer to it frequently in 9.6, the low level details
> > explanation chapter.
>
> Damn, I thought we discussed that already to remove it from the doc. But
> maybe it was for the unit tests.
> If we go for the private route, we need to move those classes to an
> `impl` package. What's weird is that I thought I did it in the past :/
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 10 Oct 2012 12:27:51 +0100
> From: Sanne Grinovero <sanne(a)hibernate.org>
> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Cc: Hibernate <hibernate-dev(a)lists.jboss.org>
> Message-ID:
> <CAFm4XO1K6SLAcwcvy=
> hsbGdjLbsgHPCe1xABn60ORFdkW08ZNg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 10 October 2012 12:17, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> >> > onCoordinates(String... names)
> >
> > Does `onCoordinates()` means all coordinates or simply the default one.
> If all, then
> > existing queries will break if you add an new coordinate property to an
> > entity.
>
> I would assume that empty would target the default one, as it's unnamed as
> well.
>
> >
> > Also, I'm not sure there is a use case for targeting in the same query,
> > the various coordinates defined on a given entity. But I have no real
> > idea.
>
> I would be able to find a car park place to rent which is both close
> to home and office.
>
> >
> > Otherwise, I'm fairly neutral to the proposal.
>
> I'm fairly neutral too, mostly wanted to explore this way to avoid the
> extra method.
>
> >
> >> > +1 to not consider
> >> > "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
> >> > case I think we should update the tests using it to use the DSL.
> >>
> >> About this, we should also not mention it in the docs: we're using it
> >> in most examples, excluding only the paragraph introducing the Spacial
> >> specific DSL.
> >> We also refer to it frequently in 9.6, the low level details
> >> explanation chapter.
> >
> > Damn, I thought we discussed that already to remove it from the doc. But
> > maybe it was for the unit tests.
> > If we go for the private route, we need to move those classes to an
> > `impl` package. What's weird is that I thought I did it in the past :/
>
> don't remember this but agree
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 10 Oct 2012 07:36:55 -0500
> From: Steve Ebersole <steve(a)hibernate.org>
> Subject: Re: [hibernate-dev] Bytecode enhancement
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Cc: Hibernate hibernate-dev <hibernate-dev(a)lists.jboss.org>
> Message-ID: <50756BE7.7040607(a)hibernate.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Its not quite that simple, again due to how we recurse. This would
> need to be a "stack" stored on a ThreadLocal. Depends what you want to
> store in here I guess, but like I said we already have "context
> specific caches" and it would be good to consolidate all that
> information into one place. What I mean by the current "context
> specific caches" is the "extra" information passed to many of the
> listeners. Take merging for example:
>
> interface MergeEventListener {
> public void onMerge(MergeEvent event);
> public void onMerge(MergeEvent event, Map copiedAlready);
> }
>
> 'copiedAlready' is a context specific cache. It tracks entity
> reference replacements. Many listeners have similar concept.
>
> Your proposal would certainly clean up those APIs.
>
> On Wed 10 Oct 2012 03:01:30 AM CDT, Emmanuel Bernard wrote:
> > On Wed 2012-10-10 9:26, Emmanuel Bernard wrote:
> >> Would using a service that store cache data structures by session work?
> I am thinking out loud here trying to push the cache idea before discarding
> it. That would require a weak-key concurrent map. The one I know is the one
> Jason wrote as a proposal for SE. I. Cannot remember where we use it but it
> must be in Search or in Validator.
> >
> > Actually that is simpler than that. Because the session cannot be used
> > in more than one thread, only one call stack is active per session. We
> > can keep the cache per session and lear it before every top level public
> method
> > of session (ie persist, flush, merge etc).
>
> --
> steve(a)hibernate.org
> http://hibernate.org
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 10 Oct 2012 07:55:15 -0500
> From: Steve Ebersole <steve(a)hibernate.org>
> Subject: Re: [hibernate-dev] Bytecode enhancement
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Cc: Hibernate hibernate-dev <hibernate-dev(a)lists.jboss.org>
> Message-ID: <50757033.8070202(a)hibernate.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/10/2012 02:26 AM, Emmanuel Bernard wrote:
> > Yes my proposal would imply we pass along the cache data structure
> through all of our internal methods.
> > My concerns about byte code enhancement are a bit diffuse but relate to:
> >
> > - does it add an extra build step to users?
>
> No, we'd go all out and complete both runtime and buildtime enhancement
> options.
>
>
> > - how much configuration is needed in SE?
>
> As far as I understand it, its just a matter of defining the agent as a
> VM start option. This is all new to me too, so not sure of all the
> specifics.
>
>
> > - has JBoss AS finally implemented the temporary class loaders required
> for runtime byte code enhancement (JPA contract)?
>
> Well there is already code in place, that you put in place, that does
> the existing limited runtime enhancement we already support when
> building a container managed EMF. Not sure why you did that nor what
> containers do/don't support that.
>
>
> > - how does that all play when entities are serialized?
> > - can I unserialize entities on different a different VM?
>
> Regarding ser/deser... If you are asking about physically, then yes it
> should work as long as any fields we enhance into the entity are defined
> as transient. If you mean logically, then I think yes as well. Anytime
> an entity is serialized it would essentially become un-managed, which is
> exactly what happens today too. And just like today as well,
> reattachment would mean an implied dirtiness.
>
> Of course, we would be enhancing the entity to implement a particular
> contract. Users would have the option to manually implement that
> interface themselves and not even require bytecode enhancement at all.
> This *could* have some nice benefits like smarter reattachment (rather
> that implied dirtiness). Etc.
>
>
> > But more importantly I had the feeling that the cache approach would
> have less intrusive than the byte code enhancement approach but your email
> made me change my mind. Propagating the cache would be more intrusive
> assuming we don't want thread local, and we probably don't want these.
>
> ThreadLocals are nice... when they work. But I have seen lots of cases
> were they maybe don't get cleared and all kinds of hard-to-debug
> problems start to appear when threads are pooled. It certainly takes a
> lot of defensiveness.
>
>
> > Would using a service that store cache data structures by session work?
> I am thinking out loud here trying to push the cache idea before discarding
> it. That would require a weak-key concurrent map. The one I know is the one
> Jason wrote as a proposal for SE. I. Cannot remember where we use it but it
> must be in Search or in Validator.
>
> Well I have been thinking about "identifying" sessions by assigning them
> a unique id (uuid?) when the session is started. That could help with
> the requirement for a specific type of map. That said, not really sure
> what this buys us. It still leaves open the same potential for leaks as
> using a ThreadLocal (though not as potentially disruptive).
>
>
> Have y'all seen any performance numbers that show the limits within
> which this "context cache" alternative is actually beneficial? Seems to
> me there will be a tipping point here beyond which it would actually
> make performance worse.
>
> --
> steve(a)hibernate.org
> http://hibernate.org
>
>
> ------------------------------
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> End of hibernate-dev Digest, Vol 76, Issue 18
> *********************************************
>
13 years, 10 months
XML to Relational mapping
by Claude Mamo
Hi,
We have a project where we have have to map an XML document to a
relational model. I've discovered that with Hibernate 3 you could do
this via the EntityMode.DOM4J. Unfortunately, the feature was removed in
Hibernate 4 (https://hibernate.onjira.com/browse/HHH-6879). I know the
feature was experimental, however, are there other reasons for removing
this feature? For example, was it implemented inefficiently?
Thanks,
Claude
--
ricston <http://www.ricston.com/>
Your flexible Open Source services partner
*Claude Mamo* - *Software Engineer*
Ricston Ltd - Northfields Suite 4,
Independence Avenue, Mosta MST9026, MALTA
claude.mamo(a)ricston.com - www.ricston.com
tel: +356 21334457 - fax +356 21334156
13 years, 10 months
[HSearch] ServiceManager and services
by Hardy Ferentschik
Hi,
as part of my investigations for HSEARCH-1025 and HSEARCH-1026 I had a look at how services are implemented in Search.
I thought I could make the statistics collector also a service. Looking at the code I am a little confused though.
Let's look at the different pieces.
First ServiceManager:
public interface ServiceManager {
public abstract <T> T requestService(Class<? extends ServiceProvider<T>> serviceProviderClass, BuildContext context);
public abstract void releaseService(Class<? extends ServiceProvider<?>> serviceProviderClass);
public abstract void stopServices();
}
And now one service example:
public class JGroupsChannelProvider implements ServiceProvider<MessageSender> {
…
}
And one usage:
this.messageSender = serviceManager.requestService( JGroupsChannelProvider.class, context );
Now, I am wondering how this is a configurable service implementation. Whenever I request a "service" I specify a concrete implementation.
How is that different to hard coded things or using some properties to specify the impl class. Really the service in the above case is the interface
MessageSender and that's what I should request as a service.
Which leads me to the second point, the service discovery. For that we use META-INF/services/org.hibernate.search.spi.ServiceProvider where we list
the ServiceProvider implementation we use. How, could I as user e.g. replace the serialization service to use something else than Avro?
I guess in this case the user adds to its jar also META-INF/services/org.hibernate.search.spi.ServiceProvider specifying his implementation class, but
then there must be some code which negotiates which implementation to chose, right? That's how I would expect it to work using the Java services api.
Or maybe ServiceManager is not what I think a ServiceManager should be!?
What am I missing?
--Hardy
13 years, 10 months
Hibernate Search Spatial: Units?
by Sanne Grinovero
Hi Nicolas,
In the QueryBuilder DSL a spatial Query has a nice option to define
which units are being used:
org.apache.lucene.search.Query luceneQuery =
builder.spatial().onCoordinates( UserRange.class.getName() )
.within( 50, Unit.KM ).ofLatitude( centerLatitude ).andLongitude(
centerLongitude ).createQuery();
org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
double, double, String)
has a javadoc comment specifying the parameters are expected to be KM.
I guess we should pick a strategy and be consistent with it; I think
we should add the Unit parameter to the SpatialQueryBuilder;
Any thoughts about it? Can I assume you'll be able to look into that?
Cheers,
Sanne
Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
13 years, 10 months
