Re: ApplesProcessor - a little crazy idea
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/
Re: ApplesProcessor - a little crazy idea
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? Apple has really no relation to page flow, whatever meaning of the word we consider. 2. introduce SpringAwareApplesProcessor that would not create an apples controller like the current one: Why don't we embrace Spring's webflow as one of the implementations of Cocoon's flow ? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: ApplesProcessor - a little crazy idea
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? If it's to become one of the official flow implementation, what about changing its name? Apple has really no relation to page flow, whatever meaning of the word we consider. yeah... for real. :-) —ml—
Re: ApplesProcessor - a little crazy idea
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 changing its name? Apple has really no relation to page flow, whatever meaning of the word we consider. Since I had a look at apples I am very fond of it. The main use for me is stateless M2M device - server interaction. I could use JavaFlow but: - that would be overkill - it looks like javaflow is still quite unstable about the naming: I wouln't change them much. Insert flow here and there (AppleFlowController, ApplesFlowProcessor) and that should be enough. 2. introduce SpringAwareApplesProcessor that would not create an apples controller like the current one: Why don't we embrace Spring's webflow as one of the implementations of Cocoon's flow ? Sure why not. But for my case it's a cannon aimed at a fly. I just want my StatelessAppleControllers be injected automatically with spring business services. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: ApplesProcessor - a little crazy idea
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 what it's all about, and why I would want to use it? It does restore the context but you run through the controller on each request. So it's not really a continuation based approach. I used to call it sub-sessions. On each request a new sub-session is being created - handled as if it were a continuation. So it's a half-way between an action and javaflow. Marc, did I put this right? cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: ApplesProcessor - a little crazy idea
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 would want to use it? If it's to become one of the official flow implementation, what about changing its name? Apple has really no relation to page flow, whatever meaning of the word we consider. yeah... for real. :-) Oh man! I was going to come up with a competing standard called Orange just so we could have Apples to Oranges comparisons! ;P
Re: ApplesProcessor - a little crazy idea
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 would want to use it?
The quickest summary from apples lamer:
Apples is:
- a flow interpreter
- a front controller that allows you to code in java (no scripting!).
I think a it can be compared to struts controller a little but.
- it has continuations but they do not suspend apple execution. See
an example from our codebase:
public class HanoiApple extends AbstractLogEnabled implements AppleController {
// full state of the puzzle is in the following variables
public Stack[] stacks;
public Object floatingDisk = null;
public int moves = 0;
public int puzzleSize = 0;
public void process(AppleRequest req, AppleResponse res) throws
ProcessingException {
// processing
if (stacks == null) {
String requestSize = req.getCocoonRequest().getParameter(size);
if (requestSize != null) {
try {
int size = Integer.parseInt(requestSize);
intializeStacks(size);
} catch (NumberFormatException ignore) {
}
}
} else {
// decide selected column
String requestStack = req.getCocoonRequest().getParameter(stack);
if (requestStack != null) {
// do something here
}
}
//view generation
if (stacks == null) {
res.sendPage(hanoi/intro.jx, null);
} else {
Map bizdata = new HashMap();
bizdata.put(stacks , this.stacks);
bizdata.put(moves , + this.moves);
bizdata.put(floatingDisk, this.floatingDisk);
bizdata.put(nextMove, this.floatingDisk==null ? Lift it! : Drop
it!);
bizdata.put(puzzleSize , + this.puzzleSize);
res.sendPage(hanoi/hanoi.jx, bizdata);
}
}
}
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 to
store data in session but have it isolated in single apple.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: ApplesProcessor - a little crazy idea
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 to store data in session but have it isolated in single apple. It is very similar to relay contact circuits language [1][2]. In this language, program is executed in loops, each loop starts from the beginning of the program and executes it to the end, and program is executed endlessly till power is shut off :) May be we should rename Apples to Ladders :) Vadim [1] http://en.wikipedia.org/wiki/Ladder_programming_language [2] http://www.mikroelektronika.co.yu/english/product/books/PLCbook/chapter5/chapter5.htm#5.3
Re: ApplesProcessor - a little crazy idea
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 clazz = Thread.currentThread()
.getContextClassLoader().loadClass(className);
Object o = clazz.newInstance();
return (AppleController) o;
}
but like this:
private AppleController instantiateController( String beanName )
throws Exception {
Object o = getSpringContext().getBean( beanName );
if ( !( o instanceof AppleController ) )
throw new SomeException( cannot fetch an apple controller
+ by name: + beanName );
}
Most of my apples look like this:
public class RouteDefinitionsApple extends AbstractSpringApple {
public void process( AppleRequest request, AppleResponse response ){
ApplicationContext springContext = fetchContextFromSomewhere();
FooService foo = (FooService) springContext.
getBean( fooService );
String bar = foo.bar();
response.sendPage( view/foo.jx, bar );
}
My change would allow to have automatic spring dependencies injected
because the apple itself would be spring managed.
We could make instantiateController either with bean name or bean class.
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() refer to a usual spring
context? I'd prefer using the Spring block as the integration is _much_ more
advanced, thanks to Carsten.
So please check in and then we can work on it.
(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.)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--
--
Re: ApplesProcessor - a little crazy idea
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 {
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
Re: ApplesProcessor - a little crazy idea
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 stable. Ralph
Re: ApplesProcessor - a little crazy idea
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 better term than stable. Mozilla uses 'frozen'. -- Stefano.
Re: ApplesProcessor - a little crazy idea
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() refer to a
usual spring context? I'd prefer using the Spring block as the
integration is _much_ more advanced, thanks to Carsten.
I am using a spring context loaded with
org.springframework.web.context.ContextLoaderListener. I'm fetching it
then with my own SpringApplicationContextFetcher:
public class SpringApplicationContextFetcher implements Contextualizable,
ThreadSafe {
public final static String ROLE=
SpringApplicationContextFetcher.class.getName();
private Context context;
public void contextualize( Context context ) throws ContextException {
this.context = context;
}
public ApplicationContext fetchContext() {
HttpContext environmentContext;
try {
environmentContext = (HttpContext) context.get(
Constants.CONTEXT_ENVIRONMENT_CONTEXT );
} catch ( ContextException e ) {
throw new IllegalStateException( Error while accessing
cocoon context, e );
}
Object attr = environmentContext.getAttribute(
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE );
if ( attr == null ) {
throw new IllegalStateException( Root application context
not found in servlet context );
}
if ( attr instanceof RuntimeException ) {
throw (RuntimeException) attr;
}
if ( attr instanceof Error ) {
throw (Error) attr;
}
if ( ! ( attr instanceof ApplicationContext ) ) {
throw new IllegalStateException( Root context attribute is
not of type ApplicationContext: + attr );
}
return (ApplicationContext) attr;
}
public static ApplicationContext fetchContext( ServiceManager manager )
throws ServiceException {
SpringApplicationContextFetcher fetcher = null;
try {
return ( (SpringApplicationContextFetcher)
manager.lookup( ROLE ) ).fetchContext();
} finally {
if ( fetcher != null )
manager.release( fetcher );
}
}
}
This is almost a copy paste from standard Spring WebApplicationContextUtils.
Could you summarize the advantages of spring block over pure spring
application context. I know I can use cocoon.getComponent(springBean)
but that has no added value for me. I prefer to keep spring isolated
from cocoon. This way I am sure I have my business logic 100% easily
testable. What I lack the most is a decent xml parser support in spring.
So please check in and then we can work on it.
Thing is: where should I put it?
apples block - bad idea
spring block - it will introduce dependency on apples
(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 tell you the truth I would start using javaflow in production long
time ago (all my production sites run quite fresh cocoon trunk) but I am
a little bit scared with postings on users list (NPEs, loosing session).
But if Torsten says it's stable - I am probably going to check it out
in few days.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: ApplesProcessor - a little crazy idea
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 conditions is bigger. But as for the trunk implementation - I think we made great progress. I see. This clears things a little bit. I am no more scared to try it in production then. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: ApplesProcessor - a little crazy idea
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 that. We really need to find a better term than stable. 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. What we are after here is something that says that the component is mature in the sense that its APIs are stable and that the community is willing to maintain it while adhering to our release guidelines (i.e. maintaining binary compatibility and/or deprecating things over time). Ralph
Re: ApplesProcessor - a little crazy idea
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 changing its name? Apple has really no relation to page flow, whatever meaning of the word we consider. 2. introduce SpringAwareApplesProcessor that would not create an apples controller like the current one: Why don't we embrace Spring's webflow as one of the implementations of Cocoon's flow ? In terms of our marketing maybe we should also do the opposite: show users (or implement some helpers if tutorial is not enough) how cocoon can be used to render views under control of Spring MVC. It is a pity that spring users have to use Velocity or xml + single xslt to render views when there is cocoon that cannot be used. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: ApplesProcessor - a little crazy idea
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. A left over from my fixing session
before the GT ;) Should be probably return to be a
private class ...or might even move into javaflow
itself.
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.
Hm... chicken egg problem ...somehow I would like
to get some feedback first. The FOM/API itself hasn't
really changed much since the branch version.
I am tempted to rename the abstract base class ...but
that's it. Everything else is under the hood.
But people tend to think of stable as rock-solid
and well tested. But without more feedback I cannot
make that promise.
I happy to say the public API is frozen ...but for
rock-solid I would first like to get a javaflow
1.0 release out of the door over at jakarta.
...and maybe even fix the continuation management
in trunk. Expect a RT next week when I am back
from Amsterdam.
cheers
--
Torsten
PGP.sig
Description: This is a digitally signed message part
Re: ApplesProcessor - a little crazy idea
(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 tell you the truth I would start using javaflow in production long time ago (all my production sites run quite fresh cocoon trunk) but I am a little bit scared with postings on users list (NPEs, loosing session). Hm ...was that for the trunk version? I did not see anything added to bugzilla. Probably another good reason to subscribe to the user list again. *sigh* ...more mails, more mails! But if Torsten says it's stable - I am probably going to check it out in few days. Stable API or rock solid? ;) cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: ApplesProcessor - a little crazy idea
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 code. So far that's the only promise I can make until jakarta javaflow has become 1.0. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: ApplesProcessor - a little crazy idea
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 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
This is also reflected by the block.xml schema. Anything new this time?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: ApplesProcessor - a little crazy idea
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 make use of it.) To tell you the truth I would start using javaflow in production long time ago (all my production sites run quite fresh cocoon trunk) but I am a little bit scared with postings on users list (NPEs, loosing session). Hm ...was that for the trunk version? I did not see anything added to bugzilla. Probably another good reason to subscribe to the user list again. *sigh* Got no idea. From time to time I just see messages' subjects like: - NPE in javaflow - weird behaviour in finally block - session lost with javaflow they might be just FUD. Still they kept me away. ...more mails, more mails! But if Torsten says it's stable - I am probably going to check it out in few days. Stable API or rock solid? ;) No matter - if you say it's not that bad I'm into it! :) -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: ApplesProcessor - a little crazy idea
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 This is also reflected by the block.xml schema. Anything new this time? 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 implementation needs to be verified get presented so that we can easily see that? Ralph
Re: ApplesProcessor - a little crazy idea
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
- implementation
- community
This is also reflected by the block.xml schema. Anything new this time?
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
implementation needs to be verified get presented so that we can easily
see that?
http://svn.apache.org/repos/asf/cocoon/trunk/src/schema/cob-schema-1.0.xsd
-- see the complex type state
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
block status (was Re: ApplesProcessor - a little crazy idea)
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 implementation needs to be verified get presented so that we can easily see that? http://svn.apache.org/repos/asf/cocoon/trunk/src/schema/cob-schema-1.0.xsd -- see the complex type state Right. And then I searched for all usages of the schema and came up with 2 block.xml files, neither of which specify this. In other words, nothing has been done about it. Ralph
Re: ApplesProcessor - a little crazy idea
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 second that. We really need to find a better term than stable. 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. What we are after here is something that says that the component is mature in the sense that its APIs are stable and that the community is willing to maintain it while adhering to our release guidelines (i.e. maintaining binary compatibility and/or deprecating things over time). Then how about mature. -David
Re: block status (was Re: ApplesProcessor - a little crazy idea)
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 but
the implementation needs to be verified get presented so that we can
easily see that?
http://svn.apache.org/repos/asf/cocoon/trunk/src/schema/cob-schema-1.0.xsd
-- see the complex type state
Right. And then I searched for all usages of the schema and came up
with 2 block.xml files, neither of which specify this.
In other words, nothing has been done about it.
Yes, we have to do it, but the procedure *how* we do it has already been
defined.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
