Re: Potential exception thrown by txn.begin() in JpaLocalTxnInterceptor is not caught
Awesome, we just migrated our application to onami-persist. I had a look at the source code, it looks much better. Thanks guys. Le jeudi 22 janvier 2015 08:03:35 UTC+11, scl a écrit : Regarding persist-extension see: https://groups.google.com/d/topic/google-guice/Dp9nWdmDbUs/discussion There are several know bugs. An alternative implementation exists (currently maintained by me): http://onami.apache.org/persist/ Cheers On 01/21/2015 04:49 AM, edouard...@gmail.com javascript: wrote: Hi all, I'll use Hibernate as an example for the underlying JPA implementation. In JpaLocalTxnInterceptor.java, line 66, guice-persist starts a transaction with txn.begin(). When Guice asks Hibernate to start a transaction, this is what Hibernates does: - Fetch a connection - Tries to disable auto-commit on the connection if autocommit was set to true. The problem is, sometimes this operation fails (loss of connectivity, whatever...) and an Hibernate exception is thrown (the most curious one can have a look at Hibernate source-code, JdbcTransaction.java, line 72). But guice-persist doesn't catch this potential RuntimeException when it begins a transaction. And because it doesn't catch it, it doesn't call rollback on the transaction. You might think, why would I call rollback on a transaction which didn't even start ? (keep in mind txn.begin() just failed). Because the connection fetched by Hibernate is only released in case of commit or rollback. By not calling rollback, the current thread gets stuck in a stale state, and the next time this thread is used for JPA transaction, Hibernate will throw an exception: Already have an associated managed connection. Because, correct me if I'm wrong, but if txn.begin() raises an exception, unitOfWork.end() is never called, the EntityManager is never closed and removed from ThreadLocal in JpaPersistService. I had a quick look at the JPA interceptor source code, for Spring Data, they do catch any potential exception, even when they begin a transaction, and call rollback in case of problem. Any thoughts on this ? Thanks for your help guys -- You received this message because you are subscribed to the Google Groups google-guice group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com javascript:. To post to this group, send email to google...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/b74e3ebd-c366-46e6-82ed-f974306cf4fa%40googlegroups.com https://groups.google.com/d/msgid/google-guice/b74e3ebd-c366-46e6-82ed-f974306cf4fa%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups google-guice group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/5e0258e2-39ef-472f-bb97-b346e78d839b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: OptionalBinder and Names.bindProperties
Thanks, that helped me ramp up on the guice ecosystem and configuration.
However - the fact that setDefault has different binding coercion semantics
to setBinding smells like a bug to me. Is there any reason that its current
behaviour is the correct one? If not I might file a bug report.
On Saturday, January 31, 2015 at 4:42:38 AM UTC-7, Laszlo Ferenczi wrote:
Hi Josh,
Using the binding mechanism in guice might be a bit of an overkill for
simple property bindings, however you have a number of alternatives:
- Properties itself allows for defaults handling, create a property file
with the defaults and create one for the application and merge them in the
properties object. Binding the resulting properties will have the defaults.
- Bind the properties object itself and manually fetch the values from it
- Specify defaults in the code, only override when you get a meaningful
value injected
A more complex way would be to roll your own configuration management.
In our projects we use an in-house developed ConfigManager object which is
similar to the Properties object but it provides typesafe getters for
various primitive types. A generic TypeListener allows the injections of
config values into the object. (conceptually very similar of what netflix's
governator does)
Obviously you can use the governator library also, it'll do the trick (and
many others). I believe apache onami has a solution for configuration too.
Hope this helps.
--
L
On Sat, Jan 31, 2015 at 5:25 AM, Joshua Moore-Oliva chat...@gmail.com
javascript: wrote:
First off - I am only a few days into guice, so I apologize if my
questions are dumb - I have tried to compensate with what I hope are clear
examples.
I am attempting to make liberal use of OptionalBinder in my code to allow
some default values to be specified and then potentially overriden by
configuration. I have run into a cascading series of issues. First, lets
start with what works in a simple case that currently works (but does not
have the default value functionality I hope to achieve with OptionalBinder):
public class Simple {
private final int simpleInt;
private final String simpleStr;
@Inject
public Simple(@Named(simpleInt) int simpleInt, @Named(simpleStr)
String simpleStr) {
this.simpleInt = simpleInt;
this.simpleStr = simpleStr;
}
public int getSimpleInt() {
return simpleInt;
}
public String getSimpleStr() {
return simpleStr;
}
}
If I wish to wire up the value of simpleVal from configuration, I can use
Names.bindProperties (which was recommended in the FAQ)
public class SimpleTest {
@Test
public void testGetSimpleVal() throws Exception {
Injector inj = Guice.createInjector(getTestModule());
Simple s = inj.getInstance(Simple.class);
assertEquals(1, s.getSimpleInt());
assertEquals(default, s.getSimpleStr());
}
private Module getTestModule() {
return new AbstractModule() {
@Override protected void configure() {
bind(Simple.class);
Properties p = new Properties();
p.setProperty(simpleInt, 1);
p.setProperty(simpleStr, default);
Names.bindProperties(binder(), p);
}
};
}
}
So far, so good - Names.bindProperties is great, it even converts my
strings to ints (1 - 1 for simpleInt)
Now I attempt to set up default values for simpleInt and simpleStr using
OptionalBinder. I do this by returning another Module with default
bindings. (I assume I should do this on a package not class level, but it
keeps the example simple).
public class Simple {
private final int simpleInt;
private final String simpleStr;
@Inject
public Simple(@Named(simpleInt) int simpleInt, @Named(simpleStr)
String simpleStr) {
this.simpleInt = simpleInt;
this.simpleStr = simpleStr;
}
public int getSimpleInt() {
return simpleInt;
}
public String getSimpleStr() {
return simpleStr;
}
public static AbstractModule getDefaultsModule() {
return new AbstractModule() {
@Override protected void configure() {
OptionalBinder.newOptionalBinder(binder(),
Key.get(Integer.class, Names.named(simpleInt )))
.setDefault().toInstance(12345);
//OptionalBinder.newOptionalBinder(binder(),
Key.get(String.class, Names.named(simpleInt )))
//.setDefault().toInstance(12345);
OptionalBinder.newOptionalBinder(binder(),
Key.get(String.class, Names.named(simpleStr)))
.setDefault().toInstance(Simple class default);
}
};
}
}
public class SimpleTest {
@Test
public void testGetSimpleVal() throws Exception {
Re: [3.0] Having the Provider provide a class with an Inject
There are several ways to do it. You can simply introduce logic in you modules which allows to configure the bindings at startup time. This is the simplest way but if the logic gets complexer it will also be hard to understand. You can group bindings which belong together into modules and then include/exclude entire modules instead of single bindings. Another possibility is to use the override feature of guice. This allows you to define default bindings and then selectively replace them with another binding. The syntax is as follows: Modules.override(defaultBindingModule).with(specialBindingModule); In your first post you mentioned mocks. If you want to use guice within unit tests then there are frameworks which ease the burden of the boiler plate code. For example jukito will create a new injector for every test class. It also allows to easily define the bindings you want and it can create bindings to mockito mocks for all missing bindings on the fly. Hope this gets you started. If you need more hints you can always come back to this place. On 01/30/2015 11:17 PM, Igmar Palsenberg wrote: Even tough you have a working solution now. It is not pretty and from my perspective hard to understand what is actually happening. So I am still wondering if you need to change the returned type during runtime or if the returned type gets fixed during startup of the application. Because if it is fixed during startup there are cleaner ways of achieving what you want. It get's fixed during application startup. I prefer a solution that gives me a constructed object from the injector, but the current solution is also acceptable, yet not perfect : Some custom annotations of this framework stop to functioning. The stacktrace makes no sense (a known issue with Guice 3 and Java 8). If you have a suggestion : Please let me know. Regards, Igmar -- You received this message because you are subscribed to the Google Groups google-guice group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscr...@googlegroups.com mailto:google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com mailto:google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/8ce3e03e-bd85-4bba-8604-6027d9a93249%40googlegroups.com https://groups.google.com/d/msgid/google-guice/8ce3e03e-bd85-4bba-8604-6027d9a93249%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups google-guice group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/54CE8A95.9080609%40gmx.ch. For more options, visit https://groups.google.com/d/optout.
