jira down
by Strong Liu
JIRA Startup Failed
You cannot access JIRA at present. Look at the table below to identify the reasons
Description
The jira.home directory '/opt/j2ee/domains/atlassian.com/opensource/projects/webapps/atlassian-jira/hibernate/data' is already locked. Please see the JIRA documentation for more information on locked jira.home directories.
-----------
Strong Liu <stliu(a)hibernate.org>
http://hibernate.org
http://github.com/stliu
13 years, 7 months
Compilation error on master ?
by Hardy Ferentschik
Hi,
does someone else have problems doing a full build of the current master?
I get a compilation error in hibernate-ehcache:
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionFactoryImpl.java:3:
cannot find symbol
symbol : class EhCacheRegionFactory
location: package org.hibernate.cache
import org.hibernate.cache.EhCacheRegionFactory;
^
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionTest.java:3:
cannot find symbol
symbol : class EhCacheProvider
location: package org.hibernate.cache
import org.hibernate.cache.EhCacheProvider;
^
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionTest.java:4:
cannot find symbol
symbol : class ReadWriteCache
location: package org.hibernate.cache
import org.hibernate.cache.ReadWriteCache;
^
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionFactoryImpl.java:17:
cannot find symbol
symbol : class EhCacheRegionFactory
location: class org.hibernate.test.cache.ehcache.EhCacheRegionFactoryImpl
cfg.setProperty(Environment.CACHE_REGION_FACTORY,
EhCacheRegionFactory.class.getName());
^
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionTest.java:16:
cannot find symbol
symbol : class EhCacheProvider
location: class org.hibernate.test.cache.ehcache.EhCacheRegionTest
cfg.setProperty( Environment.CACHE_PROVIDER,
EhCacheProvider.class.getName() );
^
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionTest.java:23:
package ReadWriteCache does not exist
if ( entry instanceof ReadWriteCache.Item ) {
^
/Users/hardy/work/hibernate/git/core-4.0/hibernate-ehcache/src/test/java/org/hibernate/test/cache/ehcache/EhCacheRegionTest.java:24:
package ReadWriteCache does not exist
map = (Map) ( (ReadWriteCache.Item) entry ).getValue();
Seems the ehcache version got updated (at least gradle pulled down some
new deps).
--Hardy
13 years, 7 months
[HV] Changes to API for programmatic constraint definition
by Gunnar Morling
Hi,
as you know, we are about to introduce the concept of method level
constraints in Hibernate Validator 4.2 (see [1] for more details).
In this context we are also planning to support the definition of
method level constraints using the programmatic constraint API [2].
Hardy, Kevin and I have discussed the required changes for a while and
came to a point where we would like to get some more feedback.
As of today this API is used as follows:
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
.property( "licensePlate", FIELD )
.constraint( SizeDef.class )
.min( 2 )
.max( 14 )
.property( "seatCount", FIELD )
.constraint( MinDef.class )
.value ( 2 );
Note, that this is one single invocation chain. In particular,
constraint definitions are part of this chain. With the introduction
of method level constraints this leads to problems as it doesn't make
sense any more to invoke any method of the API at any point of time.
For instance the following invocation should be possible:
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
.method( "drive" )
.parameter(1)
.constraint( NotNullDef.class )
.parameter(2)
.constraint( SizeDef.class )
.min( 2 )
.max( 14 )
.genericConstraint (Pattern.class)
.param( "regex", "...");
But not the following one (as invoking parameter() doesn't make sense
when being on a property):
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
.property( "licensePlate", FIELD )
.constraint( NotNull.class )
.parameter(2) //doesn't make sense
...
So the general problem is, that depending on the current invocation
context only certain methods should be part of the API at that point.
This is no problem when looking at specific methods (such as
property(), method(), parameter() etc.) which return an appropriate
context offering the methods allowed next.
But this fails with a generic method such as constraint() which is
allowed to be invoked at several places but should return a specific
constraint definition at the same time. After several experiments the
following seems to be the best solution IMO:
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
.method( "drive" )
.parameter(1)
.constraint( ConstraintDef.create( NotNull.class ) )
.parameter(2)
.constraint( ConstraintDef.create( SizeDef.class )
.min( 2 )
.max( 14 ) )
.constraint( ConstraintDef.createGeneric( Pattern.class)
.param( "regex", "...") );
Here constraint definitions are created and configured separately and
then are passed to constraint(). That way the invocation context is
not propagated through constraint definition types and can be modeled
to contain exactly the allowed methods at each point of time. Some
variations of this approach are discussed in this Gist [3], e.g.
...
constraint( new SizeDef().min( 2 ).max( 14 ) )
...
On the downside the API looses a bit of its "fluency" and at least for
beginners it might not be obvious how to obtain constraint definition
instances. Personally I think this is ok for the sake of API
consistency (plus, actually I start to like this hierarchical approach
of first configuring constraints and then placing them).
WDYT, is this a step into the right direction? Or do you see any other
approaches we've missed so far (one other thing we've tried was to
parametrize constraint definitions with the current context type, but
this worked out to be pretty cumbersome [4])?
Another question is whether we should enforce an order within the
constraint definitions for one type (e.g. class-level -> properties ->
method 1 parameters -> method 1 return value -> method 2 ...) or allow
an arbitrary order here. Personally I don't see the need for such an
order (we don't require one implementation-wise, and users could
adhere to one by convention if they want to), but Hardy and Kevin feel
different about this :)
For the interested the current proposal can be found at [5].
Thanks for any feedback,
Gunnar
[1] http://in.relation.to/18074.lace
[2] http://docs.jboss.org/hibernate/validator/4.2/reference/en-US/html/chapte...
[3] https://gist.github.com/940438
[4] https://github.com/gunnarmorling/hibernate-validator/commit/6cfe540144828...
[5] https://github.com/gunnarmorling/hibernate-validator/tree/HV-431-new
13 years, 7 months
trouble with 4.0.0.Alpha3 release
by Steve Ebersole
I ran into a problem with the gradle plugin I wrote for doing upload
authentication while working on the release tonight. Apparently there
was a change between Gradle 1.0-milestone-1 (when I developed the plugin
code) and 1.0-milestone-2 in the code for dealing with Maven repositories.
Anyway, I have a request for help sent to the Gradle user list.
Unfortunately it is late, so I probably will not hear a reply for some
time. So I'll just do the release tomorrow when I hear back.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 7 months
Alpha3 preparation
by Steve Ebersole
If you have tasks assigned to you for Alpha3 that will not get done by
tomorrow please reschedule them appropriately. Thanks!
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 8 months
meaning of shared-cache-mode default to Hibernate...
by Scott Marlow
The JPA specification allows us to choose what happens when
shared-cache-mode is not specified (JPA 2.0 3.7.1 specification).
Hibernate currently (as best as I can tell), defaults to
shared-cache-mode of NONE.
Should we change the shared-cache-mode default to ENABLE_SELECTIVE in
Hibernate 4.0? That would mean one less configuration step for
application developers.
Is there any negatives for changing shared-cache-mode to ENABLE_SELECTIVE?
Scott
13 years, 8 months
