--- Bob Lee <[EMAIL PROTECTED]> wrote: > On 2/26/07, Konstantin Priblouda > <[EMAIL PROTECTED]> wrote: > > > > > Ummmm, strictly speaking, that's still code. ;) > > > > Strictly speaking yes. But it is externalized and > > does not impose anything on used classes. > > > It imposes something on me, the programmer.
As there is no free lunch, something will be imposed on you anyway. Either on your original classes to be managed by container ( annotations, source & recompilation required ) or on you ( necessity to write code for container wiring - either java code, or some externalized configurarion, be it xml or groovy or whatever else ) Pico approach at least leaves your managed classes alone. Strictly speaking, pico itself does not ofer any externalised configuration, it's additional modules residing in nanocontainer. Pico can be configured by some java code ( like guice ) but does not require annotations. > > What if I like to use another session impl in the > > > same > > > > container? > > > Use an annotation. > > > > And if I need to register the sme class more than > > once? > > Yet another annotation? And another one? > > > Um, yeah. Doesn't Pico need multiple key objects? > And to apply those key > objects, don't I have to write external code where I > repeat property names, > etc.? Well, every distinct instance clearly requires own unambiguous key to be distinguished. Propety names are usually not involved. > > You can override the scope in the configuration. > You > > > can also implement your > > > own scopes and scope annotations. The users' > guide > > > explains this. > > > > And those scope annotations will leak into my > original > > code. ( And I prefer my classes to be innocent, > and > > not > > knowing that it is managed by Guice or pico or > > whatever > > else. Such dependency invalidates whole point of > DI / > > IoC ) > > > I clearly said, you can specify the scope internally > or externally. I like > being able to specify the scope directly on the > class because it makes it > clear to someone who is changing the class, and it's > more succinct. For > example, based on the annotation, I can clearly see > that this class is > session scoped and thus needs to be thread safe. Pico itself has no concept of scope, or better said container is a scope of its own. As it allows conainer hierarchy, scopes are implemented by chaining containers ( and in web envirobment those containers will be assotiated with application / session / request / subscopes ) Of course you have to pay attention where your component is being registered and if there is necessity for thread safety. And you can impose sychronization on object later by means of special wrapping component adapter (if you forgot to design your component right). I can not remember whether there is already such adapter, but if not it would have not much difference with hotswapping one. > In Struts 2 for example, I can apply @SessionScoped > to an action and that > action will be stored in the session. It doesn't get > much simpler than that. In pico ( ok, strictly speaking nanowar, as pico is only DI ) I would register my action in session scoped container to achieve the same result. Or even in appliction scoped container ( though I can not imagine use case for it yet ) > Finally, using a scope annotation in no way ties > your class to the scope > implementation. Well, but I have to place it on class source and compile with it. And now I'm speaking about class from separate project ( i.e VelocityEngine ) - and what do I do if I need the same class in another project in different scope? PLace 2 annotations on it and then recompile and release into maven repository? And how iws guice gound to tell those 2 scopes apart? What if I need 2 instance of same class in 2 different scopes in same app? ( not that uncommon... ) > Bob Konstantin ----[ Konstantin Pribluda http://www.pribluda.de ]---------------- Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
