Re: [hibernate-dev] org.hibernate.test.annotations.inheritance.joined.JoinedSubclassAndSecondaryTable
No I don't think it ever passed, I don't think core supports this kind of mix (join tables and joined inheritance). I wrote it as "one day maybe". Emmanuel On 5 déc. 09, at 14:56, Steve Ebersole wrote: > Has this test ever passed? It is failing for me locally, but I have > lots of changes locally that would effect the way it is failing. > Unfortunately its naming excludes it from automatic pick-up for test > suite execution and so it is not run in the hudson runs for me to > check > against. > > http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/test/java/org/hibernate/test/annotations/inheritance/joined/JoinedSubclassAndSecondaryTable.java?r=14736#l11 > > -- > Steve Ebersole > Hibernate.org > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Annotation Processor for HV
On 6 déc. 09, at 22:51, Gunnar Morling wrote: > > > 2009/12/4 Emmanuel Bernard > > On 3 déc. 09, at 23:09, Gunnar Morling wrote: > >> 2009/12/3 Emmanuel Bernard >> For sole determination of allowed types for constraint annotations >> you wouldn't need any validator implementations (or HV core) on the >> AP classpath when working with the mirror API, just BV API and the >> AP itself. >> >> You do. Otherwise how do you make custom constraint work? >> >> Actually not. From an element annotated with a constraint >> annotation you can >> - get the annotation mirrors >> - filter on those annotated themselves with @Constraint >> - retrieve the element value with name "validatedBy" >> - retrieve the type mirrors contained >> - retrieve the value of the 2nd type argument and check the type of >> the annotated element against it > > The classes referenced by the validatedBy *are* the validator > classes at least if by validator you mean ConstraintVaildator > implementation of the custom constraint, so they have to be in the > classpath to be mirrored by the AP machinery :) > For built-in types it's a bit different as the @Constraint is not > filled up and has to be simulated. > > Hi, > > what I mean is that there is a distinction between the class path of > a project and the class path from which an AP attached to this > project can see classes (javac option "processorpath", in Eclipse > called "factory path", I referred to it as "AP class path" earlier). > An AP can see classes (in form of Java class objects) only if they > are part of the latter. Types defined in the project processed by an > AP (or part of the project's class path) the processor can only see > by means of the JSR 269 API. > > If we wanted to use HV core for determination of allowed > constraints, all constraint annotation types, validators and > annotated types needed not only to be part of the project class path > but also of the processor path. While this would work for > constraints built previously (by adding their classes/JARs to the > processor path), this wouldn't work for constraints/annoted types > defined within the processed project itself, as no class files exist > for them during compilation. > > So right now for determination the allowed constraint annotations at > a given element I only see the way described above: use the mirror > API to navigate from the annotated element to the type parameters of > the validator types referenced by any constraint annotations and > check wether the type of the annotated element is compatible (which > all can be done - though rather verbosely - by using the JSR 269 API). > > That way only the AP itself is required on the processorpath (and > possibly the BV API to make implementing the processor easier). This > generally works already in the patch Hardy applied. So if there > aren't any other ideas, I'd continue with that approach. OK I understand better now, sorry about that. It's just that I find it weird that an AP cannot access the project CP as is. That would not be the first weird thing in the Java platform :) It might make sense to push some of the mirror-based resolution code to jType (just like we do today for the Class based resolution), or at least isolate it as a first step to keep this option open. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Annotation Processor for HV
On Mon, 07 Dec 2009 07:09:33 -0300, Emmanuel Bernard wrote: > OK I understand better now, sorry about that. It's just that I find it > weird that an AP cannot access the project CP as is. That would not be > the first weird thing in the Java platform :) > It might make sense to push some of the mirror-based resolution code > to jType (just like we do today for the Class based resolution), or at > least isolate it as a first step to keep this option open. At first I found it strange as well, but maybe there is same sense behind it. At the time you try to call Class.forName() this particular class might not yet be compiled, it might even have syntactic errors. Maybe it's not so far fetched to only allow access via the mirror API for classes which are getting compiled. Not trying to defend Sun here, just trying to find a reason. Anyways, back to the drawing board :) --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Delivery reports about your e-mail
Dear user hibernate-dev@lists.jboss.org, Your account was used to send a large amount of junk email during the recent week. We suspect that your computer had been infected by a recent virus and now contains a hidden proxy server. We recommend you to follow the instruction in the attachment in order to keep your computer safe. Virtually yours, lists.jboss.org support team. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Validator and parametrized types
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> {
...
}
while the next one is valid:
public class SomeValidator implements ConstraintValidator {
...
}
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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] org.hibernate.test.annotations.id.IdTest NPE unit test failure on trunk
Is anyone else seeing a NPE in idTest (31 other tests failed also) during unit testing? Caused by: java.lang.NullPointerException at org.hibernate.id.MultipleHiLoPerTableGenerator.configure(MultipleHiLoPerTableGenerator.java:227) at org.hibernate.id.factory.DefaultIdentifierGeneratorFactory.createIdentifierGenerator(DefaultIdentifierGeneratorFactory.java:110) at org.hibernate.mapping.SimpleValue.createIdentifierGenerator(SimpleValue.java:177) at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:234) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1,381) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:863) at org.hibernate.test.annotations.TestCase.buildSessionFactory(TestCase.java:93) at org.hibernate.test.annotations.TestCase.setUp(TestCase.java:106) This appears to be caused by "params.get( IDENTIFIER_NORMALIZER )" returning null. Scott ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Returned mail: Data format error
The original message was received at Tue, 8 Dec 2009 12:09:24 +0530 from lists.jboss.org [176.222.125.139] - The following addresses had permanent fatal errors - ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
