[Validator] method level validation
by Hardy Ferentschik
Hi,
forwarding this email to hibernate-dev to get some more feedback.
Here are some of my thoughts. The method level validation is suggested in
Appendix C of the Bean Validation specification. The method signatures
there all return a set of ConstraintViolations.
The question is how binding these signatures are.
Root bean and property path are indeed questionable for method level
validation. By extending ConstraintViolation you still have to deal with
these values. Maybe instead of
extending we should have a new interface MethodConstraintViolation.
Emmanuel, do you have some more feedback on what was discussed regarding
appendix C?
--Hardy
------- Forwarded message -------
From: "Gunnar Morling" <gunnar.morling(a)googlemail.com>
To: "Hardy Ferentschik" <hibernate(a)ferentschik.de>
while working on method-level validation I wondered how to represent the
failing validation of method parameters. I think
javax.validation.ConstraintViolation in its current form is only partly
suitable for the needs of parameter/return value validation:
* The concept of property path seems not to fit right. How would the
property path look for a failing parameter constraint? One could come up
with something like "MyBean.MyMethod(String,Int).Parameters[1]" but I
can't say I'd like that
* The concept of a root bean does only fit partly. I think one would need
a safe reference to the "root method" and the parameter index. A direct
reference to the class hosting the validated method seems only partly
useful (and could anytimes be retrieved from a Method reference).
I therefore prototyped this into this direction:
* Created a MethodConstraintViolation that extends ConstraintViolation by
adding fields the causing method and the parameter index (one surely would
add a flag or something in case of return value validation)
* In case a constraint directly at one of a method's parameters fail,
ConstraintViolation#rootBean and propertyPath are null (but method and
parameterIndex are set)
* In case a "cascading" constraint fails (meaning in this context, a
parameter is annotated with @Valid and the referenced bean has constraints
itself which in turn fail), method and parameterIndex are set, rootBean
and propertyPath refer to parameter bean itself, *not* the class hosting
the validated method
WDYT, is this the right way to go? Maybe we should brainstorm a bit on IRC?
14 years, 12 months
On possible extensions for the validator
by Federico Mancini
Hi all,
I am new to the list and I am opening this thread on Emmanuel Bernard's
suggestion, in order to
discuss some possible extensions to the validator (jsr 303) I have been
working on with a couple of collegues.
Mainly it concerns the possibility to extend composition with boolean
operators (ex.: A field is either in the range 1-10 OR 20-30 AND
notNull) and allow validation of sets of interdependent properties
(ex.: EITHER the name field is notNull OR the surname field is notNull/
AT LEAST 1 field must be filled/etc....).
A description of the experimental framework we implemented can be found
here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and
some further discussion on the choices we made here
http://www.ii.uib.no/~federico/papers/Annotations.pdf.
I hope this might be of some interest for the Hybernate Validator project,
but, even if not, it would be nice to get some feedback.
Thanks,
Federico Mancini
15 years
Transaction API
by Steve Ebersole
Currently there is a big discrepancy between the documentation for some
of the methods on org.hibernate.Transaction and the actual code.
Specifically the methods isActive(), wasRolledBack() and wasCommitted()
explicitly state that they only account for the "local state" of the
transaction object, not the underlying transaction.
However, the code explicitly checks the current status of JTA
transactions to responded to these methods.
We need to fix one or the other. Personally I do not follow the use of
these methods too much, so asking for feedback on which way is more
useful.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
15 years, 1 month
Please provide guide line
by Brajesh Patel
Hello all,
Please provide beginner guide for learn hibernate.
Thanks in advance.
--
Thanks
Brajesh Patel
15 years, 1 month
Infinispan DirectoryProvider for Hibernate Search
by Sanne Grinovero
Hi all,
this was planned long time ago and is now being requested often,
especially on the Infinispan forum and irc.
As Search might have to manage several indexes, these can all be
stored in the same cache, or in different caches;
In both cases the cache or CacheManager should be reused, and so the
different DirectoryProvider implementations should
be able to get a reference to the CacheManager.
In case this is stored in JNDI, this should be trivial, but when it's
not we might need to manage the CacheManager lifecycle and
have a global configuration file for it.
The Infinispan Directory was designed to work with Search, so it's all
about dependencies and configuration; these are the steps needed:
1) create a module
- needed to introduce the Infinispan dependency and Java6.
- it could be loaded using the FQN for the moment, and later on we
could think about a SPI to plugin "short names"
2) define how a single Infinispan CacheManager's lifecycle should be
handled when JNDI is not used
[as noticed here: http://community.jboss.org/thread/155875]
- The initialize(..) method of the DirectoryProvider should pass a
reference to a started CacheManager,
I see we have now a BuildContext passed in, could we use this to
pass a reference to a loosely coupled CacheManager?
- the SearchFactory should start a cacheManager before the DirectoryProviders
- it should stop the cachemanager
- we should enable a configuration property to name the Infinispan
configuration file
3) In case JNDI is used, provide needed configuration for it (name?)
This provides a usable distributed index, but then other components
should be integrated:
* Share the cachemanager used for the index with the one eventually
setup as second level cache
* Share Infinispan's JGroups channel with the JGroups backend of
Hibernate Search to setup master/slave configurations
* Share Hibernate's database as a cachestore for the index
I'm in need of ideas about how to integrate the lifecycle of the
CacheManager, if someone could help on that I could assemble some of
the other pieces.
Cheers,
Sanne
15 years, 1 month
Fwd: Topic reply notification - "Could not register synchronization for container transaction"
by Sanne Grinovero
Hi Emmanuel,
do you have any clue about this issue in the forum thread mentiond below?
I thougth they might be missing the transactionmanager registration, but a)
I'd expect a different exception b)there's no mention of Glassfish in the
Hibernate core documentation.
Is it possible that in glassfish it's not allowed to start a transaction at
all in a user created thread?
Cheers,
Sanne
---------- Messaggio inoltrato ----------
Da: "Hibernate Forums" <do-not-reply(a)jboss.org>
Data: 28/set/2010 15:24
Oggetto: Topic reply notification - "Could not register synchronization for
container transaction"
A: "s.grinovero" <sanne.grinovero(a)gmail.com>
Hello s.grinovero,
You are receiving this notification because you are watching the topic,
"Could not register synchronization for container transaction" at
"Hibernate Community". This topic has received a reply since your last
visit. You can use the following link to view the replies made, no more
notifications will be sent until you visit the topic.
If you want to view the newest post made since your last visit, click the
following link:
https://forum.hibernate.org/viewtopic.php?f=9&t=1004515&p=2436306&e=2436306
If you want to view the topic, click the following link:
https://forum.hibernate.org/viewtopic.php?f=9&t=1004515
If you want to view the forum, click the following link:
https://forum.hibernate.org/viewforum.php?f=9
If you no longer wish to watch this topic you can either click the
"Unsubscribe topic" link found at the bottom of the topic above, or by
clicking the following link:
https://forum.hibernate.org/viewtopic.php?uid=48308&f=9&t=1004515&unwatch...
--
Hibernate Community Forum
http://forum.hibernate.org/
15 years, 1 month
[HSearch] Upgrade to Lucene 3.0
by Hardy Ferentschik
Hi,
I was working on the issues around upgrading HSearch to Lucene 3.0
(HSEARCH-424).
Before even thinking about utilizing any of the new Lucene features like
numeric fields and so on, we
have to deal with HSEARCH-593 - the upgrade of the Solr analyzer framework.
We are using the Solr analyzer framework (a set of Lucene filters and
matching factory classes) within
the HSearch specific @AnalyzerDef annotation. The problem is that the
latest release of Solr (1.4) is
compatible only to Lucene 2.9 and there is no official release yet which
works with Lucene 3.0.
In fact Solr is now part of the Lucene source tree and I assume Lucene and
Solr releases will now happen
together. The current 3.1 branch of Lucene contains the updated Solr code,
but there is no release date
for Lucene 3.1 in the near future.
As a workaround I created a new maven module -
hibernate-search-solr-analyzers - in HSearch. I added the
latest source from the 1.4 Solr release and then backported the changes
form the Lucene 3.1 branch to make
the analyzer framework work with Lucene 3.0.2. This works, but there were
several issues.
The Lucene code has moved on as well on the 3.1 branch and new classes got
introduced, for example CharTermAttribute.
Other issues are CharArraySet and CharArrayMap which now take a Version
parameter as well. Some classes
also have moved from Solr core to Lucene core. This means that backporting
becomes quite a bit more complicated.
This is really not a good position to be in from a maintenance point of
view for hibernate-search-solr-analyzers.
The good news is that our additional hibernate-search-solr-analyzers
module would become obsolete with
a release of Lucene/Solr 3.1. At this point we would have the possibility
to release a new version of HSearch
depending just on the new Lucene/Solr release.
What I am wondering right now is:
- Does it make sense to introduce hibernate-search-solr-analyzers and
should we have a release with this additional module?
- If we release hibernate-search-solr-analyzers, should we really make it
obsolete once Lucene 3.1 is out or keep this module
as sort of buffer?
- So far I haven't renamed any package names. This has the advantage our
existing users don't have to change their code.
Does it make sense to rename the packages?
- This is not the first time we are having problems with the Solr code.
Does it makes sense to fork the Solr code
and maintain or own version of the analyzer framework?
Right now I tend to say that we go for the hibernate-search-solr-analyzers
approach, but remove the module again once
Lucene 3.1 is released. But what's your take on this?
--Hardy
15 years, 1 month
Annotation name for column-level read/write expression
by Emmanuel Bernard
Hey guys,
I've implemented http://opensource.atlassian.com/projects/hibernate/browse/HHH-4510 and committed it. It basically looks like that
@Entity
class CreditCard {
@Column(name="credit_card_num")
@ReadWriteExpression(
forColumn="credit_card_num",
read="decrypt(credit_card_num)",
write="encrypt(?)")
public String getCreditCardNumber() { return creditCardNumber; }
public void setCreditCardNumber(String number) { this.creditCardNumber = number; }
private String creditCardNumber;
}
However, I am not super happy about @ReadWriteExpression as a name. @ColumnReadWriteExpression is the most correct name but quite mouthful.
Anybody gets a better idea?
Emmanuel
15 years, 1 month
