On Thu, 06 Jan 2011 14:37:43 -0200, Joel Halbert <j...@su3analytics.com>
wrote:
> > - if you have lots of modules, which a client may want to
selectively
> > enable, do not declare them in the manifest, but instead let the
client
> > use the tapestry.modules sys property to selectively enabl
But that's sort of my point - configuring IOC via a system property
doesn't seem right, especially if all I wanted to do was disable 1 of
many services.
It's not configuring the whole IoC via a system property. It's just an
additional way of configuring it. Don't forget the @SubModule annotation.
Again, there's no way of disabling individual services, just T-IoC
modules. I don't know any IoC container that does that.
> This looks like a huge JAR. Why not break it in smaller, more
manageable
> ones?
Again, it doesn't seem right to have to consider what are effectively
runtime deployment configuration options when building an application
into a jar.
Don't forget the @SubModule annotation.
I think you should consider JARs as self-contained black boxes. If you add
one to the classpath, you want all services in it. If there's a set of
services that you may not use, create a separate JAR for them. Why put
services you won't use in a JAR you'll use? But that's just my opinion, of
course. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
