Hibernate.org
by Steve Ebersole
After months of sitting in limbo it looks like there may finally be
movement on getting hibernate.org content moved over to the
magnolia/clearspace setup.
We need to figure out what all still needs to be done in terms of
content. For core (+ annotations/em) I have a good idea of the work
still to do. But in terms of search, validator, shards and tools
(nhibernate?) I have no idea.
This will not happen until next week at the earliest as I have a meet up
scheduled with the JBoss design team here in Austin to go over LnF,
navigation, etc later this week.
Like one specific thing I know we have to iron out is navigation and
side bar content for the various subprojects. Will the various
subprojects "be under" hibernate? The infrastructure is really built so
that all projects are at the same level. I think it comes down to how
much content (pages) we see for each sub project and how y'all want the
nav and menus to work. If a unified set of nav and menus along with a
minimal set of content pages is acceptable then its probably doable to
just create sub content pages under the main set of hibernate pages. If
y'all want something more elaborate or separate nav/menus than we are
going to have to split these up I think (I'll verify to make sure this
is still the case).
--
steve(a)hibernate.org
http://hibernate.org
14 years, 10 months
CR-2
by Steve Ebersole
I will be doing CR-2 later tonight as I needed to track down an
unforeseen issue that arose from the recent merging of documentation
translation work. If I run out of time Gail volunteered to do it
tomorrow. Otherwise it will need to slip until Friday as I am in an all
day meeting tomorrow.
--
steve(a)hibernate.org
http://hibernate.org
14 years, 10 months
Does any RuntimeException cause a transaction rollback?
by Hardy Ferentschik
Hi,
I was just looking at HHH-4676 - "Any interceptor exception (RTE) should
mark the tx for rollback"
and was wondering whether we can generally say that in JPA any
RuntimeException will mark the current
transaction for a rollback.
Currently we have this in AbstractEntityManagerImpl:
public RuntimeException convert(RuntimeException e) {
RuntimeException result = e;
if ( e instanceof HibernateException ) {
result = convert( (HibernateException) e );
}
else if (e instanceof ConstraintViolationException) {
markAsRollback();
}
//if any RT exception should mark the tx for rollback, convert the last
else if into a else
return result;
}
Should this be changed to:
public RuntimeException convert(RuntimeException e) {
RuntimeException result = e;
if ( e instanceof HibernateException ) {
result = convert( ( HibernateException ) e, null );
}
else {
markAsRollback();
}
return result;
}
Meaning all RuntimeExceptions will mark the current transaction for
rollback? Any comments?
--Hardy
14 years, 10 months
adding a binding to a boolean method in Search's @Field to enable/disable
by Sanne Grinovero
Hello all,
there's a user on Search's forum which is asking for a new feature:
https://forum.hibernate.org/viewtopic.php?f=9&t=1002800
We already had cases of people wanting to enable/disable indexing at
instance level; in this case he wants to avoid indexing certain fields
in some conditions; reading a boolean property in the same indexed
instance would be good enough.
I'm unsure about the binding expression, but the idea of having each
Field enabled/disabled independently would indeed have helped me in
other situations, preventing me from writing a full ClassBridge for
just some special fields.
Regards,
Sanne
14 years, 10 months
Re: [hibernate-dev] Message-Templates from multiple JARs
by Hardy Ferentschik
Hi,
Having multiple resource bundles and some custom way of specifying these
bundles is
related to HV-238 and HV-251.
Having a ResourceBundleLocatorStrategy should solve your problem Gunnar,
right?
The default strategy could behave like it does now and we can provide an
additional strategy
which allows for multiple resource bundles. You would specify the strategy
in the hibernate
config file. The names for the different resource files could also be
specified in the
config (or maybe there is a better way!?)
--Hardy
On Mon, 15 Feb 2010 16:51:13 -0300, Gunnar Morling
<gunnar.morling(a)googlemail.com> wrote:
> I agree, there probably won't be that many 3rd-party constraint vendors
> :-)
>
> Nevertheless I think the problem is not too exotic. In my day job for
> example we're building a large-scale enterprise application, which is
> made
> up of multiple JARs ("components") developed by multiple, independent
> development teams.
>
> Now it would be great, if two teams could develop independently their
> custom
> constraints, specific to their component. As of now they would have to
> provide a unified ValidationMessages.properties, violating the
> encapsulation
> of the components.
>
> A rather simple solution might be a meta-annotation @MessageBundle, which
> optionally could be used at constraint annotation type declarations to
> specify the name of the message bundle to be used. That way name
> collisions
> between constraints from different JARs still could occur, but finding
> unique names should not be too hard. If that meta-annotation is not
> given, a
> fallback to ValidationMessages.properties might be used.
>
> WDYT?
>
> Cheers, Gunnar
>
>
> 2010/2/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
>> Yes, you need to copy it over or more likely adapt the messages to your
>> application (in which case you don't care).
>> The problem with listing the resource bundle is that you need an order
>> to
>> specify which has precedence over which.
>>
>> Another solution could be some sort of plugin system where 3rd party
>> constraint makers can reference automatically a resource bundle. But
>> realistically, how many 3rd party constraint makers will there be?
>>
>> The question is: is the additional complexity for the solution worth the
>> current problem?
>>
>> On 14 févr. 2010, at 22:00, Gunnar Morling wrote:
>>
>> > Hello you two,
>> >
>> > recently I thought about the following situation:
>> >
>> > * I have a JAR containing a custom constraint on the class path
>> (could be
>> a constraint provided by some 3rd-party constraint vendor)
>> > * I have another custom constraint within the actual project itself
>> (and
>> therefore a ValidationMessages.properties as well)
>> >
>> > Now the ValidationMessages.properties provided by the 3rd-party
>> vendor is
>> hidden by my own ValidationMessages.properties, which - if I'm not
>> mistaken
>> - requires me to copy the contents of the first to the latter.
>> >
>> > Is there any better solution to this problem?
>> >
>> > Maybe BV/HV should provide some means for constraint vendors to
>> specify
>> the resource bundle containing messages? If you think, that's useful I'd
>> create a JIRA issue for that one.
>> >
>> > Thanks for any ideas,
>> >
>> > Gunnar
>>
>>
14 years, 10 months
Re: [hibernate-dev] 3.5.0-CR-2 set up in JIRA
by Steve Ebersole
Thanks for bringing
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4613 to my
attention. That was just carelessness on my part. I have resolved it
already.
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870 is
indicative of a larger, though pretty isolated, issue. It only affects
users wanting to use what JPA terms a "static metamodel". The
referenced error is happening when trying to "wire up" the static
metamodel classes. The underlying issue is various mismatches between
how JPA defines the metamodel and how Hibernate defines it. The
long-term fix for this is substantial. I nudged the issue author for
some more details. I agree it would be nice to have all these static
metamodel issues resolved prior 3.5.0, but given that users don't really
know about this feature thus far (the actual generator has no
documentation/fanfare and the spec does not really dwell on the
specifics) I don't see that as necessarily feasible at this time.
On 02/17/2010 01:40 AM, Guenther Demetz wrote:
> Hi Steve,
>
> I know 2 unassigned bug issues which only 3.5 is affect and not former
> GA releases.
> HHH-4613
> <http://opensource.atlassian.com/projects/hibernate/browse/HHH-4613>
> HHH-4870
> <http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870>
> I think this issues should be fixed for backward compatibility reasons.
>
> Overmore there are further unassigned 47 bug issues on jira with version
> 3.5 set as affectedVersion (see JQL query below).
> I haven't the time to analyze them one by one, but I fear there are some
> other bug's which are affect to 3.5 only
> and thus may compromise 3.5's backward compatibility.
>
>
> JQL Query: resolution = Unresolved AND affectedVersion >= "3.5.0.Beta-1"
> AND affectedVersion not in ("3.0.1.GA","3.3.2.GA","3.3.1.GA","3.3.0.GA")
> AND fixVersion = EMPTY and assignee = null AND type = "bug" ORDER BY key
> DESC
>
> best regards
> Guenther Demetz
>
>
>
> Steve Ebersole schrieb:
>> Just wanted to point out to everyone that 3.5.0-CR-2 has been set up in
>> JIRA (
>> http://opensource.atlassian.com/projects/hibernate/browse/HHH/fixforversi...
>> ) and tentatively scheduled for Feb 24 2010. I say tentatively because
>> I am not sure I will wait that long; lets see how things go.
>>
>> In the meantime, I moved all unresolved issues not in progress to 3.5.x.
>> Please take the time asap to mark any issues you want in 3.5.0-CR-2.
>> I completely expect this to be the last CR before 3.5.0
>>
>> Thanks
>>
>>
>
--
steve(a)hibernate.org
http://hibernate.org
14 years, 10 months
