> > > - 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. > > 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. On Thu, 2011-01-06 at 14:15 -0200, Thiago H. de Paula Figueiredo wrote: > On Thu, 06 Jan 2011 14:09:02 -0200, Joel Halbert <j...@su3analytics.com> > wrote: > > > So if I understand correctly: > > > > - the only way to disable modules that are specified in the manifest is > > to remove the jar from the classpath > > Wrong. See > http://tapestry.1045711.n5.nabble.com/T5-disable-loading-specified-module-td2431110.html > > > - 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 enable them > > This looks like a huge JAR. Why not break it in smaller, more manageable > ones? > You can also use @SubModule in a module class to include other modules > automatically without using system properties or context parameters. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
