+1, not that important for the first release "build" oriented but if we extend the concept to runtimes it should be done but it is not that easy since you need to take care of current context to know if you are in a container or not and if you use right perms. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
2013/9/18 Matt Benson <[email protected]>: > Hmm... well, the typical usage profile for WeaveProcessor/CleanProcessor > would be that it is invoked by Maven or Ant, so I wouldn't usually (ever?) > expect an active SecurityManager in these contexts. That leaves custom > stuff, the nature of which I can't really begin to imagine having just > woken up. ;) IMO it doesn't really seem like an issue, but if you feel it > could be important you could do a little hacking. :D > > Matt > > > On Tue, Sep 17, 2013 at 10:45 PM, Dave Brosius <[email protected]> wrote: > >> On 09/17/2013 04:40 PM, Matt Benson wrote: >> >>> I propose that the [weaver] component [1] is ready for release. I am the >>> primary contributor to the code, but Mark Struberg also worked on the core >>> architecture. As soon as [weaver] is released I intend to incorporate the >>> privilizer module into Apache BVal, and at least at one point it was >>> planned that it would be similarly used in Apache OpenWebBeans, so >>> hopefully these will reduce its risk of being orphaned. Does anyone have >>> any concerns before I put the promotion of [weaver] to a proper component >>> to a vote? >>> >>> Thanks, >>> Matt >>> >>> [1] >>> https://commons.apache.org/**sandbox/commons-weaver/index.**html<https://commons.apache.org/sandbox/commons-weaver/index.html> >>> >>> >> should the class loader creation in WeaveProcessor/CleanProcessor be done >> in a AccessController.doPrivileged block? >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
