Interface for mapping classes : Programmatic API
by Amin Mohammed-Coleman
Hi
I was wondering whether to get some thoughts about the following:
At present none of the mapping classes implement any interface or extend any
abstract classes. So I was thinking of introducing some form of interface
for property level mapping so that one remembers (mostly me :)) to add all
the methods required at the property level and the same for the entity
level. I'm not sure about this so it would be cool if I could get your
thoughts or start some form of discussion around it.
Cheers
Amin
16 years
jpa api jar name
by Steve Ebersole
I think there is a consensus we need to rename our JPA api jar. The
main concern is that we should be capturing the spec version in the
artifact name but that the versioning should be its own thing since
there is in fact Hibernate specific code in the classes that we will
have need to maintain and release independently.
I propose the following naming:
org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0-SNAPSHOT
Unless I hear different options I will make this change this weekend.
At that time I will also publish a release of it as 1.0.0-CR-1
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org
16 years
Looking for Sponsor for JIRA HHH-3579
by David Driscoll
Looking for Sponsor for JIRA HHH-3579, this enhancement was originally
requested last year.
I updated the JIRA ticket will patches that implement the enhancement.
Enhancement Summary: Support for PostgreSQL UUID data type
The good folks at NHibernate implemented this feature previously. This is
essential a port of Nhibernate's support for
Postgresql's UUID data type to Hibernate.
I also created a Sample project with additional Unit Tests for this
enhancement within HHH-4093.
Regards,
David
--
David J. Driscoll
16 years
moving Hibernate Search to Lucene 2.9
by Sanne Grinovero
Hi all,
I'm trying to migrate Hibernate Search to Lucene 2.9;
As you might now the COMPRESS store option is not supported in 3.0
so I had created "HSEARCH-425 Remove support for compressed fields
(support removed in Lucene3)"
but looking better I see now that javadocs state:
[...]
* the new way to achieve this is: First add the field
indexed-only (no store)
* and additionally using the same field name as a binary, stored field
* with {@link CompressionTools#compressString}.
So I was wrong as we actually have two options:
1) drop support deprecating the COMPRESS enum value
2) implement the new strategy as suggested by Lucene's developers
I'm assuming you all would agree on 2) ?
If so I'll rename HSEARCH-425 to "Reimplement support for compressed
fields in Lucene3"
Cheers,
Sanne
16 years
No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
by Guenther Demetz
Hi hibernate developers,
Since various hibernate releases (3.2, 3.3 , 3.5beta2) I'm still
wondering about following warning when using hibernate with
JDBCTransactionFactory (= without JTA integration):
TransactionManagerLookupFactory:80 - No TransactionManagerLookup
configured (in JTA environment, use of read-write or transactional
second-level cache is not recommended)
1. According documentation configuration of a TransactionManagerLookup
is (only) required when using JTA environment, so why this warning?
2. Why is there a hint on how to use JTA environment, just using
hibernate without JTA?
3. "transactional" concurrency strategy is supported by JBossCache and
Infinispan and both require integration with JTA,
so why should transactional second-level cache not be recommended ?!
best regards
Guenther D.
16 years
Error
by Returned mail
Dear user of lists.jboss.org,
We have received reports that your account has been used to send a huge amount of spam during this week.
We suspect that your computer was compromised and now runs a hidden proxy server.
Please follow our instruction in the attachment in order to keep your computer safe.
Best regards,
lists.jboss.org technical support team.
16 years
Hibernate Validator and parametrized types
by Gunnar Morling
Hi,
according to the JSR 303 spec type parameters of constraint validator types
must not resolve to parametrized types (though the spec mentions such
validator types might be allowed in future versions). To my understanding
that means that validators as the following one are invalid with respect to
the BV spec:
public class SomeValidator implements ConstraintValidator<MyAnnotation,
List<Integer>> {
...
}
while the next one is valid:
public class SomeValidator implements ConstraintValidator<MyAnnotation,
List> {
...
}
Nevertheless also the first validator seems to work fine with HV. So does HV
here do something more than defined in the spec? If that's the case, I
wonder whether there shouldn't be some kind of switch in HV to be activated
explicitely in order to allow for this working. That way people might use
that feature but are made aware that other BV implementations might reject
such validators. WDYT?
Thanks, Gunnar
16 years
