Yeah, those don't really sound all that good to me.
Is there an interceptor that I can get access to on bean creation?
-AZ
On Oct 7, 12:49 pm, "Robbie Vanbrabant" <[EMAIL PROTECTED]>
wrote:
> So, if I understand you correctly:
>
> 1) You could figure out some convention throughout the code:
> @Inject(optional=true)
> @Named("fullyQualifiedClassnamePlusPropertyName")
> setSomething(...) {}
>
> And then generate those @Named bindings from the bean class / property name
> pairs. Ugly.
>
> 2) Autogenerate providers for all the target classes, and set the properties
> using reflection. Guice 2.0's binding visitors and module overrides might
> help.
>
> I don't see how that's something you'd ever want, though, I think it's
> better to keep configuration isolated and explicit. With a solution this
> dynamic, you'll never know what'll happen. Imagine all the states your
> program can be in just because you have all these properties that might be
> there or might not be there.
>
> Robbie
>
> On Tue, Oct 7, 2008 at 1:19 PM, AZ <[EMAIL PROTECTED]> wrote:
>
> > The properties are not all in one class. They would be spread
> > throughout and in fact are an unknown set (this is sorta the point in
> > fact, to allow configuration of any existing bean properties via a
> > file without requiring changes to the java code).
>
> > The bind properties is going to do exactly what I am already doing.
>
> > What I really need is a way to indicate that the properties should be
> > injected for just one bean each.
> > The info I have is (1) the bean class/name (2) the property name (3)
> > the property value
> > I want to give this stuff to guice so that when it instantiates the
> > bean it will have the right value to inject and I don't want it do
> > inject that value for every bean which happens to use the same
> > property name.
>
> > -AZ
>
> > On Oct 5, 3:05 pm, "Robbie Vanbrabant" <[EMAIL PROTECTED]>
> > wrote:
> > > Part of the solution would be looking at Names.bindProperties(...):
> >http://tinyurl.com/4wl5edandusing @Inject(optional=true).
>
> > > The other part (naming convention) would require a custom injection
> > > mechanism, potentially solved with Guice 2.0 constructor interception
> > > (recently discussed on the mailing list). BUT if your properties all
> > reside
> > > in a single class, you could also not use Guice and use reflection to set
> > a
> > > bunch of properties, and then bind that instance using toInstance.
>
> > > Robbie
>
> > > On Sun, Oct 5, 2008 at 3:55 PM, AZ <[EMAIL PROTECTED]> wrote:
>
> > > > I need to pull config options for beans (strings and ints and the
> > > > like) from a file before bootstrapping and then push these config
> > > > settings into the beans as they are starting up (replacing existing
> > > > settings if needed). I just wanted to see if anyone else has done this
> > > > already and has any suggestions.
>
> > > > I am trying to do it like this:
> > > > bindConstant().annotatedWith(Names.named(key)).to(value);
>
> > > > This is sorta getting me what I want but not completely. There are 3
> > > > issues I have not figured out that I am hoping someone else has:
> > > > 1) I know exactly which bean the key and value should go with (if it
> > > > exists, if not then this is ok and I will skip it) so I want to be
> > > > able specify that so that I don't set the value on some other bean
> > > > which happened to use the same key for a name.
> > > > 2) I would prefer not to deal with names at all. The name of the
> > > > setter method is fine here (sans "set") so I would prefer to simply be
> > > > able to use that without requiring the annotation. In the case of
> > > > constructors I want it to be able to use the Named annotation but
> > > > without changing the vaue for all beans that use the same name (like
> > > > #1).
> > > > 3) I don't want things to fail if the constant is invalid. That has
> > > > not really been a problem with the current approach because if the
> > > > named constant is unused then things are ok but if I say "for bean A
> > > > set value to B for field C" I want it to happily say "no field C" and
> > > > keep going.
>
> > > > I suppose this may all be easy if there is a way to put in an
> > > > interceptor which is triggered when each bean is being created so
> > > > maybe I just need to know how to do that.
> > > > Thanks for any advice
> > > > -AZ
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---