Re: [3.0] Having the Provider provide a class with an Inject

[Stephan Classen]

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 
.
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/8ce3e03e-bd85-4bba-8604-6027d9a93249%40googlegroups.com 
.

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.

Re: OptionalBinder and Names.bindProperties

[Joshua Moore-Oliva]

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  > 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

Re: Potential exception thrown by txn.begin() in JpaLocalTxnInterceptor is not caught

[edouard . kaiser]

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  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 .
> To post to this group, send email to google...@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/b74e3ebd-c366-46e6-82ed-f974306cf4fa%40googlegroups.com
>  
> 
> .
> 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.