api/spi/internal package split
by Steve Ebersole
OK, now that we have been doing this for a few months and have some actual
experience, I wanted to circle back and talk about this notion of splitting up
packages to denote api/spi/internal intent.
Not so much "should we do it". I think we absolutely should to help do osgi
stuff a little later and now (new major rev) is the time to be changing up
packages.
Not, more I mean the specifics of how we will do this. Currently we took the
approach (mostly) that these distinctions are leaves (as in plural leaf) in
the package name. So for example, we have:
1) org.hibernate.service (api)
2) org.hibernate.service.spi
3) org.hibernate.service.internal
On the plus side this keeps related stuff grouped together. Everything under
org.hibernate.service we know relates to the notion of services. Everything
under org.hibernate.engine we know deals with the internal engine. etc
On the downside (imo) this creates lots of packages. To see what I mean, just
take a look at https://github.com/hibernate/hibernate-
core/tree/master/hibernate-core/src/main/java/org/hibernate/service
The only other option I saw was to make api/spi/internal the top level
packaging construct:
1) org.hibernate.service (still api)
2) org.hibernate.spi.service
3) org.hibernate.internal.service
What's been everyone's experience(s) here?
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 10 months
Integrator locator
by Steve Ebersole
HHH-5562 is done, which introduces a locator/discovery means for integrating
with Hibernate. Specifically it introduces the (alternate name suggestions
welcome, i am indifferent to this one) org.hibernate.impl.Integrator
interface.
It does discovery based on a classpath lookup for a well-defined filename (can
discover multiple) which names an implementor of this interface. The process
occurs in the midst of Sessionfactory building to account for the main use
cases I know of including Envers, Search, Validation and BV. Currently I
additionally define those 4 as "built in" integrators, meaning there is no
need for them to define auto-discovery files unless we want them to be
integrated in that manner (I know for example that Search is interested in
this via HSEARCH-595). Anyway, we should probably decide pretty early which
integrations we want done which way.
Actually I take one part back. Envers is actually handed by discovery due to
the fact that it is in a separate project (jar). The others were done this
way because they already had the reflection code in place to do this. So for
it, we need to decide if we want to go the opposite way.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
15 years
HSEARCH-679 status
by Tom Waterhouse
I see that HSEARCH-679 is scheduled to be released in Hibernate Search
3.4.0. I haven't seen any progress on the issue though. If it will help
moving the issue along I can definitely test proposed solutions, we can
reproduce the issue consistently. Unfortunately we've reproduced the issue
during product demonstrations to potential customers, hence the urgency on
our end to see the issue resolved.
Cheers,
Tom
15 years
building core from master
by Sanne Grinovero
Hello,
I really wanted to merge my super-trivial patch using the new JUnit4
capabilities, but I'm having some issues in building core.
1)IntelliJ
(after solving the OOM issues with the annotation processor)
It doesn't find the ANTLR generated files, hence I can't run my test
as it has a compile failure.
2)Eclipse
the configuration files generated by gradle are totally wrong, but I
could fix them by hand.
Now Eclipse refuses to compile the project as there's a circular dependency:
the testsuite from hibernate-core depends on the hibernate-testing
module, which in turn depends on hibernate-core.
This doesn't look right, I guess we should merge this module back into
hibernate-core?
Reopening in IntelliJ to figure out why it seemed to almost work there:
In fact, it's showing a warning about circular dependencies, but
somehow it can work around it.
3) Command line
./gradlew clean build
Gets me 100 compile errors, related to the usage of @Override in the
generated code, I guess Gradle could also somehow could workaround the
dependency circularity but didn't set the compiler to Java6
compatibility:
TestLogger_$logger.java:515: method does not override or implement a
method from a supertype
@Override
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
100 errors
FAILURE: Build failed with an exception.
Suggestions? Is it working fine for everyone else?
Cheers,
Sanne
15 years
Shaded build for the HV annotation processor
by Gunnar Morling
Hi guys,
I just played around with the Hibernate Validator AP in my IDE, and it's
really awesome to see all these constraint checks in action.
There is just one thing which I think we can improve: right now the user has
to to add three different JARs to the annotation processor path:
* the AP itself
* validation-api.jar (some types such as @Valid are imported in the AP)
* and also hibernate-validator.jar (due to HV-436 and in the future HV-270
where types from HV core are used in the AP).
I think that's pretty cumbersome for the users, so I thought about shading
HV core and the validation API into the AP JAR. That way only one single JAR
must be put onto the AP class path. I'm generally no big fan of uber-jars,
but I think in this special case this makes sense pretty much.
WDYT?
Gunnar
15 years
Using hibernate/spring for batch jobs - open session in view pattern?
by orly＠notrly.com
so i think i understand the open session in view pattern when generally
used with controllers and creating a filter which creates the hibernate
session and starts the transaction and then there are multiple service
calls for that http request.
im trying to do the same thing for batch jobs but running into some issues.
so i have a set of batch jobs, and for each one, it calls a service to get
a list of objects. it does this in the batch class. then for each object,
it will make a service call to process the object. i have this call in the
batch class wrapped in a try catch, so if an exception occurs, i log it,
but iw ant the next object to be processed and persisted.
i was creating a hibernate session in this batch class and binding it to
the current thread - this was so that the session used to get the list of
objects is the same session used to process each object since in the
services it might call object.getList which is lazy loaded (can only be
loaded from that same session). but im not creating a transaction in that
batch class either because these batch jobs can run long, and if the db
timeout is at 5 min i'll get an error saying the db connection closed for
this outer transaction (since each service call will have an inner
transaction)
but there was a problem w/ this when say the first object in the list
threw an exception in the service, then when i process the 2nd object and
try to access something from the obj that's lazy loaded, it will say
there's no session. this seems to be because im not actually supposed to
reuse a session after an exception occurs since hibernate does something
to it..?
any ideas on how to resolve this?
whats the best way to go about doing something like this? it seems like
something that's really common for batch jobs - getting a list of objects,
and process each one independently of the other (persisting it and if
exception occurs, doesnt affect persisting of the others).
thanks
15 years
multi-tenancy and ConnectionProvider
by Steve Ebersole
reference http://opensource.atlassian.com/projects/hibernate/browse/HHH-5697
For multi-tenancy implemented by sepaerate schema we need the ability to tell
the ConnectionProvider about the tenant for the given getConnection() request.
I really see 3 approaches to this:
1) Have 2 hierarchies here. The current ConnectionProvider contract remains
the same. Add a new MultiTenantConnectionProvider with methods accounting for
tenant
2) Just alter the ConnectionProvider contract to pass information in. If we
go this route I prefer the "parameter object" pattern where we pass in
ConnectionOptions interface (see issue).
3) Use contextual lookup. ConnentionProviders interested in (or capable of
understanding) mulit-tenancy would perform some kind of "contextual"
(ThreadLocal, etc) lookup for the needed information.
Thoughts? Discussions?
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
15 years
Mocking for unit tests
by Tom Waterhouse
I've completed a unit test for HSEARCH-679. Testing the issue was made
easier using mock objects, as I needed to mock SearchFactoryImplementor and
Worker to determine if indexing work was created during transaction commit.
The mocking library I've used recently is Mockito, and is the library used
for the test. I don't know that mocks have been used to this point for
Hibernate Search testing. Mockito/mocking is acceptable?
You can see the test I created as an attachment to HSEARCH-679.
Tom
15 years
org.hibernate.secure
by Steve Ebersole
Is anyone using or aware of uses of the JACC stuff in org.hibernate.secure?
I'd like to remove it.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
15 years
gradle build problems
by David Mansfield
Fresh checkout of master (4.0) from github, and ./gradlew yields:
::::::::::::::::::::::::::::::::::::::::::::::
:: UNRESOLVED DEPENDENCIES ::
::::::::::::::::::::::::::::::::::::::::::::::
:: org.slf4j#slf4j-api;1.6.0: not found
:: xml-apis#xml-apis;1.0.b2: not found
::::::::::::::::::::::::::::::::::::::::::::::
I do not have any .m2 directory locally, and repository.jboss.org and
snapshots.jboss.org do not have the versions of the projects listed
above. However, repo2.maven.org has these artifacts, but the
configuration is not looking there.
Can someone point me how to get my .m2 initialized with the missing
resources, or how to get gradle to search maven.org?
(note: build.gradle specifies version 1.5.8, yet 1.6.0 is being
requested, also something I cannot understand).
15 years
