JIRA notifications
by Steve Ebersole
I will be changing Hibernate Core JIRA project to use the participant-based
notification scheme. Should I change over any other projects while I am in
there?
What is participant-based notification? Basically, any participant (reporter,
assignee and all commenters) is automatically notified on changes.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
some change broke master build
by Strong Liu
/Users/stliu/projects/hibernate/hibernate-core/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/lazy/ToOneDelegateSessionImplementor.java:36: org.hibernate.envers.entities.mapper.relation.lazy.ToOneDelegateSessionImplementor is not abstract and does not override abstract method <T>execute(org.hibernate.engine.jdbc.LobCreationContext.Callback<T>) in org.hibernate.engine.jdbc.LobCreationContext
public class ToOneDelegateSessionImplementor extends AbstractDelegateSessionImplementor {
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
13 years, 1 month
logging level question (targeted for 4.0)
by Scott Marlow
Hi,
Do we still want to log configuration at INFO still? I was just looking
at http://pastebin.com/4GRZkDfY and wondering if this information should
still be at INFO or should we move it to DEBUG?
If we still want to log configuration at INFO, what if we were to change
the AS7 logging configuration to show only ERROR logging for the
configuration related classes? Would that be a bad workaround?
Thanks,
Scott
13 years, 1 month
nested ServiceRegistry ?
by Steve Ebersole
ServiceRegistry itself has worked out great imo, but I am starting to run into
difficulties in migrating certain things to be services. Specifically I had
issues with both event listeners and Statistics. In each case the issue was
slightly different, but both were solveable by having a notion of the
ServiceRegistry being scoped by the SessionFactory. That is not the ideal
general solution though since many services do not care about or need the
SessionFactory. The only real solution I have thought of is to have the
concept of a set of nested registries. In the simpliest case, I think 2.. a
basic service registry and a session factory scoped one where the session
factory scoped one knows about the basic one (typical parent delegation).
But I am looking for any other suggestions.
Another option is that maybe listeners and stats are just not services in the
ServiceRegistry sense.
So what were the specific problems? I guess that is useful to formulate
suggestions ;)
In the case of statistics, its merely a case that it needs a reference to the
SessionFactory to be able to answer questions like "getEntityNames,
"getCollectionRoleNames", etc.
In the case of listeners it is not a simple explanation. It really comes down
to scoping of the listeners and timing in regards to how stuff happens at the
moment because of the "freeness" of Configuration. The end result was
different for each listener set. jpa, envers, bean validation, search each
had unique set of problems; even the default listeners had issues.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
org.hibernate.classic
by Steve Ebersole
I cleaned up the org.hibernate.classic package last night, including removing
o.h.classic.Session, o.h.classic.Validatable and
o.h.classic.ValidationException.
I ran into trouble with o.h.classic.Lifecycle because tests in the
org.hibernate.test.legacy package make pretty extensive (and sometimes
extremely odd) use of it. Which leads to an ugly choice with regards to these
tests.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
updated testing stuff
by Steve Ebersole
I wanted to give everyone a heads up about the changes to the stuff in
org.hibernate.testing (there is still a question about whether Eclipse is able
to handle the hibernate-testing as a separate module setup).
Internally, the main piece is a custom JUnit4 runner implementation,
org.hibernate.testing.junit4.CustomRunner. Some things it does:
1) The first major difference is that it creates a single instance of the test
class for all the methods. This is completely different than stock JUnit and
different from what we used to have.
2) Applies around-advice for custom @BeforeClassOnce and @AfterClassOnce
annotations
3) Applies around-advice handling for @FailureExpected, @Skip,
@SkipForDialect, @RequiresDialect and @RequiresDialectFeature annotations.
Another major difference from the previous incarnation of this code is that
instead of not even simply dropping "ignored" tests from the testsuite, we now
treat them as if they had been marked with JUnit's @Ignore. This works nicely
with JUnit reports and IDEs.
Some notes about the specific custom annotations:
1) @BforeClassOnce - much like JUnit's own @BeforeClass except that the
annotated method need not be static.
2) @AfterClassOnce - much like JUnit's own @AfterClass except that the
annotated method need not be static.
3) @FailureExpected - Marks a method (or at class-level to mark all method in
class) as being a failure expected. If
'hibernate.test.validatefailureexpected' is defined as a System property as
'true' then this behaves just like older "failure expected" handling;
otherwise the test is treated as an ignore.
4) @OnFailure - annotates a method to be performed on test failure.
5) @OnExpectedFailure - annotates a method to be performed on an expected test
failure.
6) @RequiresDialect (method or class) - The test will be run only if the
executing dialect matches the specified dialect.
7) @RequiresDialect (method or class) - The test will be run only if the
executing dialect matches the specified feature.
8) @Skip (method or class) - defines a general purpose, conditional skip. The
test is skipped if the specified condition is met.
9) @SkipForDialect (method or class) - The test will be run only if the
executing dialect does not match the specified dialect.
10) @TestForIssue (method or class) - just an informational annotation for
now. Allows to specify the JIRA key for the issue the test demonstrates.
It is also worth noting that only methods explicitly marked with
@org.junit.Test are considered test methods.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
