Changes include:
- update Guice tests that asserts error messages
- export new errors tests
- update Guice compiler flag so parameter names are available at runtime, which is required for the errors tests
PiperOrigin-RevId: 337602195
Changes include:
- update Guice tests that asserts error messages
- export new errors tests
- update Guice compiler flag so parameter names are available at runtime, which is required for the errors tests
PiperOrigin-RevId: 337401912
A linked binding should only be treated as an eager singleton if the target binding is eager singleton *and* the source binding is unscoped. If the source binding is scoped, it may be a scope with context constraints (such as @RequestScoped) that shouldn't be evaluated during injector creation.
Bug repro:
bind(Key1).toInstance(<something>)
bind(Key2).to(Key1).in(RequestScoped.class);
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=249417146
Generated with refaster, with some manual touch-ups afterwards.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=238042288
In 41f307e21b this AbstractModule.configure() became non-abstract in the base class, so it is now allowed for subclasses to not override the method at all when they don’t need to access the binding dsl.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148043119
This method is going away and this is the only internal use of it in guice (outside of tests). It is used to construct error messages by listing the dep chains from other
threads involved in singleton based lock cycles.
There is no direct replacement, so instead we are using a completely different
error message formatting using thread stacks.
For each thread in the cycle we will print something like:
Thread['foo',5,main] is holding locks the following singletons in the cycle:
com.google.Foo
com.google.Bar annotated with com.google.inject.name.Named(hello)
at com.google.inject.internal.SingletonScope.provision
at ....
at com.google.application.package.Foo.createInjector
and then for the thread who detected the cycle we will report the current
provisioning stack (as normal).
While this loses some detail from the other threads, it does add the full stack trace which should be useful for identifying the top level call that triggered the failure.
To do this i had to slightly modify the contract on CycleDetectingLock to make sure that the final lock in the cycle was reported
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134445852
configure a presubmit to ensure that it stays formatted.
Highlights include:
* simplified import order
* method annotations are now consistently defined on the preceding line
* javadoc reformatted to 100 chars column width
One test that contained line numbers in error messages had to be modified and
the formatter didn't like some of the more complicated preprocessor directives
(MOE and AOP).
To avoid formatting the copyright notices as javadoc i did a preprocessing step to rewrite the initial '/**' to '/*' using perl
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132718493
99% of this is adding missing @Override annotations, in the long tail we also have
* insert missing calls to Assert.fail() in tests that are testing exception behavior
* rewrite a few cases of Foo.class.instanceof(c) to c instanceof Foo
* rewrite Class.newInstance - > Class.getConstructor().newInstance() which doesn't break checked exception checking.
* adding @javax.inject.Inject annotations to methods that override methods annotated with @javax.inject.Inject
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131839622
Reasoning:
I am rolling out an Annotation Processor check that fails at compile-time if you annotated a class with multiple scoping-annotations as this is not supported by Guice.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128826347
Now when you can create two independent singletons using
the same injector in different threads.
This make it easy to create scopes creating singletons using
thread pools with all the concurrency being done by Guice.
As a nice side effect Singleton scope is no longer treated
specially in Guice codebase.
The obvious problem to solve is potential deadlocks:
A requires B, B requires C, C requires A where all are
singletons and all are created simultaneously.
It's impossible to detect this deadlock using information
within one thread, so we have to have a shared storage.
An idea is to have a map of creators' locks and a map
of which threads are waiting for other singletons to be created.
Using this information circular dependencies are trivially
discovered within O(N) where N is a number of concurrent threads.
Important to not that no other deadlock scenarios within
Guice code is introduced as Guice does not expose any
other scopes that can span several threads.
Now it would be possible for
client code to deadlock on itself with two lazy singletons
calling each other's providers during creation.
This is deemed as a non-issue as it is up to the client
to write a thread-safe code.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91610630
Singleton is defined as a scope which creates no more than one
object per injector. It's highly confusing when you catch a deadlock
between two unrelated injectors due to the same class injection.
Problem is demonstrated using a test that recreates scenario when
one thread injecting class can block other thread to use its own
injector.
Proposed solution is to use Injector-wide locks in a singleton.
ThreadLocal as a way to store current state.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=78469951
By setting guice_include_stack_traces flag OFF, Guice does not collect stack traces for identifying the declaring source of a binding. Instead it uses the first non-skipped module class name from the modules stack. As a result, in some cases, error messages can be slightly different with this flag. For example, the file name and line number are not always available.
A sample error message with this flag :
Guice creation errors:
1) Received null converting foo (bound at com.google.inject.TypeConversionTest.configure(Unknown Source) (via modules: com.google.inject.TypeConversionTest -> com.google.inject.TypeConversionTest)) to java.util.Date
using CustomConverter which matches only(java.util.Date) (bound at com.google.inject.TypeConversionTest.configure(Unknown Source) (via modules: com.google.inject.TypeConversionTest -> com.google.inject.TypeConversionTest -> com.google.inject.TypeConversionTest)).
while locating java.util.Date annotated with @com.google.inject.TypeConversionTest()
for field at com.google.inject.TypeConversionTest.date(TypeConversionTest.java:478)
at com.google.inject.TypeConversionTest.configure(Unknown Source) (via modules: com.google.inject.TypeConversionTest -> com.google.inject.TypeConversionTest)
This also changes the DEFAULT flag name to ONLY_FOR_DECLARTION_SOURCE.
Adds InternalFlags.getIncludeStackTraceOption() to wrap system property access.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=53610378
only if there's >1 module (otherwise it's just noise). The format is
Some normal messaging about the fact that something terrible happened
at <the normal source> (via modules: A -> B -> C)
So, for example, exposing something that isn't bound would show up as:
1) Could not expose() Foo, it must be explicitly bound.
at FooExposerModule.configure(FooExposerModule.java:211) (via modules: ParentModule -> FooExposerModule)
.. and a duplicate binding would show up as:
A binding to DuplicatedThing was already configured at ModuleA.configure(ModuleA.java:36) (via modules: ParentModule -> FooModule -> ModuleA)
at ModuleA.configure(ModuleA.java:36) (via modules: ParentModule -> BarModule -> ModuleA)
All the tests passed as-is (because this is just new information), so I made a bunch of tests stricter to explicitly look for this new information.
I also cleaned up some other errors regarding scopes & some other stuff.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=53039251
* Sort imports
* Convert tabs to spaces
* Fix the ant no_aop build
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2532
git-svn-id: https://google-guice.googlecode.com/svn/trunk@1572 d779f126-a31b-0410-b53b-1d3aecad763e
