Il giorno 14/ott/05, alle ore 04:07, David Crossley ha scritto:
Then how about mature.
I'm afraid a few anti-spam filter might be triggered by that ;-).
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine Food Blog: http://www.divinocibo.it/
I'd like to:
1. make ApplesProcessor.instantiateController protected
2. introduce SpringAwareApplesProcessor that would not create an apples
controller like the current one:
private AppleController instantiateController(String className)
throws Exception {
Class clazz =
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the official flow implementation, what about
changing its name?
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of what it's all about, and why I would want to use it?
Sylvain Wallez wrote:
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the official flow implementation, what about
On 13.10.2005, at 17:45, Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only
their original creators) are using it.
I never really did get Apples. Can somebody just sort of give a
quick summary of what it's all about, and why
Mark Lundquist wrote:
On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote:
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
I never really did get Apples. Can somebody just sort of give a quick
summary of what it's all about, and why I
Leszek Gawron wrote:
First time the apple is invoked it is created from scratch. Later on if
continuation is being called the apple object is retrieved from
continuation and apple.process( req, res ) is called again on the same
object. You have to maintain view flow yourself. You do not have
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
2. introduce SpringAwareApplesProcessor that would not create an apples
controller like the current one:
private AppleController instantiateController(String className)
throws Exception {
Class
Torsten Curdt wrote:
The API itself is not very likely to change much - if at all.
What about Invoker? If this class is part of API... It declares two exceptions
which are not thrown in the method:
public Invoker(Method method) throws IllegalAccessException,
InstantiationException {
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a better term than
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a
Reinhard Poetz wrote:
Leszek Gawron wrote:
WDYT? If you don't like it I will do 2). only in my codebase.
I like it. I'm one of the Apples users Sylvain mentioned in his mail.
I've also prototyped nearly the same code as you did :-)
Do you use the spring block or does getSpringContext()
Torsten Curdt wrote:
- it looks like javaflow is still quite unstable
Hey, hey, hey! ;) ...that sounds much worse than it is!
It is still marked unstable - that's true. And compared
to Apples it has a bigger complexity implementation-wise
so of course the risk it might break in certain
Stefano Mazzocchi wrote:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second
Sylvain Wallez wrote:
Leszek Gawron wrote:
I'd like to:
1. make ApplesProcessor.instantiateController protected
I never used Apples, but it looks like some people (and not only their
original creators) are using it.
If it's to become one of the official flow implementation, what about
The API itself is not very likely to change much - if at all.
What about Invoker? If this class is part of API... It declares two
exceptions which are not thrown in the method:
public Invoker(Method method) throws IllegalAccessException,
InstantiationException {
No external API.
(NB I hope that I can soon drop Apples in favor of JavaFlow as
using a state machine is a PITA. The missing part is serialization
support for Javaflow. It is itself already serializeable as
Torsten showed me in Amsterdam, but needs some integration work in
Cocoon to make use of it.)
To
Mozilla uses 'frozen'.
I've always used that term to mean that there can't be any more
code changes - such as just before a release.
Well, there definitely going to be code changes to improve the
JavaInterpreter (stupid name - RT!)
But as a user you won't have to change anything in your
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
Vadim
I second that. We really need to find a
Torsten Curdt wrote:
(NB I hope that I can soon drop Apples in favor of JavaFlow as using
a state machine is a PITA. The missing part is serialization support
for Javaflow. It is itself already serializeable as Torsten showed
me in Amsterdam, but needs some integration work in Cocoon to
Reinhard Poetz wrote:
Ralph Goers wrote:
I second that. We really need to find a better term than stable.
One of those discussions hitting us every 3 to 6 months. Anyway, last
time we agreed (for blocks) that we split up stability into three parts:
- api
- implementation
- community
Ralph Goers wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
I second that. We really need to find a better term than stable.
One of those discussions hitting us every 3 to 6 months. Anyway, last
time we agreed (for blocks) that we split up stability into three parts:
- api
-
Reinhard Poetz wrote:
Ralph Goers wrote:
I don't recall the last discussion. Obviously, if there was an
agreement nothing was done about it.
Currently gump.xml only has status=value. How do the 3 parts get
reflected into that? How does the fact that the api is stable but
the
Ralph Goers wrote:
Stefano Mazzocchi wrote:
Ralph Goers wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
We only need a few more people using it to find the corner cases.
Stable API != Stable Implementation. If API is stable, you should
start vote on marking javaflow stable.
I
Ralph Goers wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
I don't recall the last discussion. Obviously, if there was an
agreement nothing was done about it.
Currently gump.xml only has status=value. How do the 3 parts get
reflected into that? How does the fact that the api is stable
27 matches
Mail list logo
