On Fri, 17 Apr 2015 04:54:33 -0300, Lance Java <lance.j...@googlemail.com>
wrote:
In theory, that's possible. Tapestry doesn't reference ASM classes, it's
only dependency is plastic. So in theory you could have a layer in
plastic to choose ASM or javassist as the "provider" (or another byte
code
library).
Yeah, I think that's possible.
I'd doubt that this is high priority for the tapestry team. I seem to
recall Howard mentioning that javassist was buggy and updates were very
slow to be implemented compared to ASM.
Yep. In addition, I don't see the value of supporting both bytecode
manipulation frameworks, at least in the sense of the Tapestry team
spending very precious time on it. Of course, if someone implements that
and provides a good patch, why not? :)
Perhaps if plastic was broken into it's own separate project outside of
the core tapestry source tree, the open source community could tweak it
to be a "provider agnostic" byte code manipulation language in a similar
vein to
slf4j.
I'm not sure why these contributions cannot happen with Plastic sources
still belonging in the Apache Tapestry project.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
