You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2001/02/15 15:49:24 UTC
log performance penalties
I'm looking at the changes made to Cocoon while I was away:
are you guys aware of the fact that something like
getLogger().debug("Making URL from " + location);
is translated by java compilers into
StringBuffer sb = new StringBuffer("Making URL from ");
sb.append(location);
getLogger().debug(sb.toString());
which generates
1) a new stringbuffer object
2) a new String
even if debug log channel is disabled?
Probably so, but just to make sure.
The only way to do it well is by wrapping the whole call around a log
channel test such as
if (getLogger().debugIsActive()) getLogger().debug("Making URL from " +
location);
FYI, doing this in JServ 1.0 resulted in a 20% performance improvement.
I understand that performance fine tuning is very low priority right now
(and rightly so!) but please, keep this in mind from start or profiling
will be a major pain in the ass later on.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: log performance penalties
Posted by Giacomo Pati <gi...@apache.org>.
Stefano Mazzocchi wrote:
> I'm looking at the changes made to Cocoon while I was away:
>
> are you guys aware of the fact that something like
>
> getLogger().debug("Making URL from " + location);
>
> is translated by java compilers into
>
> StringBuffer sb = new StringBuffer("Making URL from ");
> sb.append(location);
> getLogger().debug(sb.toString());
>
> which generates
>
> 1) a new stringbuffer object
> 2) a new String
>
> even if debug log channel is disabled?
>
> Probably so, but just to make sure.
I'm fully aware of that but it has helped alot finding bugs because C2 is a
very distributed exeption throwing and eating beast :). Most of the logging
stuff come from Berin and I've found that it was easy to debug now.
> The only way to do it well is by wrapping the whole call around a log
> channel test such as
>
> if (getLogger().debugIsActive()) getLogger().debug("Making URL from " +
> location);
I've thought of how to weaken that and your idea seems to be one solution.
The radical solution I had was to pipe the code through a filter that
eliminates all the debug loggin stuff (but in fact this would be a loss)
>
> FYI, doing this in JServ 1.0 resulted in a 20% performance improvement.
>
> I understand that performance fine tuning is very low priority right now
> (and rightly so!) but please, keep this in mind from start or profiling
> will be a major pain in the ass later on.
Re: AW: log performance penalties
Posted by Peter Donald <do...@apache.org>.
At 11:21 24/2/01 +0100, Stefano Mazzocchi wrote:
>> > I would suggest we start converting/implementing the logging in the way
>Stefano suggested.
>> > Either by
>> > 1. if (logger.debugIsActive()) logger.debug(...)
>>
>> +1
>>
>> > 2. if (LOG && logger.debugIsActive()) logger.debug(...)
>>
>> -1, because it over-complicates things, and I don't _really_ think it's
>> necessary. I assume logger.debugIsActive() is a fairly light weight
>> call, so we wouldn't be gaining too much.
>
>I tend to disagree: having a finely granular debugging infrastucture in
>place is *always* significant, no matter what evolution stage of the code
>you reach since you'll always have to modify stuff and break them.
>
>More than performance, I'm talking about size!
>
>Think about it: all the strings must be stored, this increases the class
>size.
Most compilers don't remove dead code as far as I am aware. The extra size
of a few strings is insignificant in the long run. Especially considering
that C2 is in active development. The ever so slight and largely
insignificant gain is offset by the increased comlexity of the system IMHO.
What is the saying .. premature optimisation is the root of all evil? ;)
>It's the best logging practice anyway since its as close to ASP you can get
>with Java today.
>
>I vote for something like
>
> if (Cocoon.LOG && logger.channelIsActive(Logger.DEBUG)) {
> logger.debug("this " + is " pretty " + expensive);
> }
If Cocoon.LOG is a static final then theoretically it is dead code and can
be removed by compiler (but isn't in practical cases). If it is not a
static final then you could instead do something like the following (which
is already implemented in logkit).
At start of execution
LogKit.setGlobalPriority( Priority.DEBUG );
then in your code
if (logger.isDebugEnabled()) {
logger.debug("this " + is " pretty " + expensive);
}
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: log performance penalties
Posted by Stefano Mazzocchi <st...@apache.org>.
----- Original Message -----
From: "Paul Russell" <pa...@luminas.co.uk>
To: <co...@xml.apache.org>
Sent: Friday, February 23, 2001 6:01 PM
Subject: Re: AW: log performance penalties
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > I would suggest we start converting/implementing the logging in the way
Stefano suggested.
> > Either by
> > 1. if (logger.debugIsActive()) logger.debug(...)
>
> +1
>
> > 2. if (LOG && logger.debugIsActive()) logger.debug(...)
>
> -1, because it over-complicates things, and I don't _really_ think it's
> necessary. I assume logger.debugIsActive() is a fairly light weight
> call, so we wouldn't be gaining too much.
I tend to disagree: having a finely granular debugging infrastucture in
place is *always* significant, no matter what evolution stage of the code
you reach since you'll always have to modify stuff and break them.
More than performance, I'm talking about size!
Think about it: all the strings must be stored, this increases the class
size.
It's the best logging practice anyway since its as close to ASP you can get
with Java today.
I vote for something like
if (Cocoon.LOG && logger.channelIsActive(Logger.DEBUG)) {
logger.debug("this " + is " pretty " + expensive);
}
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: log performance penalties
Posted by Paul Russell <pa...@luminas.co.uk>.
* Carsten Ziegeler (cziegeler@sundn.de) wrote :
> I would suggest we start converting/implementing the logging in the way Stefano suggested.
> Either by
> 1. if (logger.debugIsActive()) logger.debug(...)
+1
> 2. if (LOG && logger.debugIsActive()) logger.debug(...)
-1, because it over-complicates things, and I don't _really_ think it's
necessary. I assume logger.debugIsActive() is a fairly light weight
call, so we wouldn't be gaining too much.
> with if (Cocoon.LOG && logger.debugIsActive()) the same effective? Then I could imagine to use 2.
-0. Again, I'm not really sure we need it.
I think we also need remember that it's not a sin to _remove_ debug
events once code starts to stabalise -- it's a natural part of
refactoring.
Speaking of refactoring, anyone know what the end result of the unit
testing discussions?
Paul.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Berin Loritsch wrote:
> > Giacomo Pati wrote:
> > > Stefano Mazzocchi wrote:
> > > > ----- Original Message -----
> > > > From: "Allan Erskine" <a....@cs.ucl.ac.uk>
> > > > To: <co...@xml.apache.org>
> > > > Sent: Friday, February 23, 2001 5:05 AM
> > > > Subject: [C2] XSP and apects (was: log performance penalties)
> > > >
> > > > > ----- Original Message -----
> > >
> > > <snip/>
> > >
> > > > > thing for different forms, longing for XSP actions, feeling locked in
> > > > > by proprietary sitemap. Just the usual $0.02 worth in other words).
> > > >
> > > > I don't follow cocoon-users and I believe that placing a rant on
> > > > cocoon-users is totally meaningless.
> > > >
> > > > Cocoon was not designed with webapps in mind, admittely, not even
> > > > Cocoon2 so far and the 'action proposal' is not enough thought out to
> > > > represent a clear design (even Giacomo agrees with me on this).
> > >
> > > Unfortunetly, yes, I do agree :/
> > > I haven't come to a better solution and all other proposals (thanks for
> > > them all) will polute the sitemap with too much semantics IMHO. Semantics
> > > which is too much programatic to make it into the sitemap (for now).
> > > That's why I haven't agreed (most silently) with the proposers of
> > > additional stuff on the action proposal. We still have a lot to think
> > > about it. As proposer (and implementor) of the Action proposal into C2 I
> > > use it for web apps and I've seen that you can come up with easy
> > > solutions but you'll need additional layers which supports your Action
> > > coding (ie. access layers like Castor).
> >
> > I am still working out the bugs, but the new Actions I committed today
> > (which when they are debugged will replace the XXXEmployeeAction actions)
> > will load a configuration file (an XML file) to set the parameters needed
> > for the actions. This lets you set parameters and other things that are
> > completely orthagonal to the sitemap.
>
> Yes, I probably think is might be the solution. But still, I don't know if we
> need Actions? Can't a Matcher or a Selector take its place? Can't a Matcher
> instead of matching URIs match on events? Or be configured with a separate
> file as you proposed? Or even have it's own namespace to be configured (I
> know this would clutter up the sitemap but it is still separated by
> namespace).
That's what I was talking about. Using an external file to configure these
things, or match on events. An Event matcher would really be cool. Basically,
we could set in motion a Future (a value that is specified now, but evaluated
in the future--usually in a separate thread), and you could check on the result
after the EvaluationComplete event is sent. (However that is not directly related
to the thread at hand).
Either separate by namespace, or use an external file. Too many things in the
sitemap make it a development tool, and not an administration tool. That is
not the stated purpose of the Sitemap.
>
> Giacomo
>
> > This approach would work for configuring aggregation and other aspects
> > without cluttering the sitemap with too many semantics.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Giacomo Pati <gi...@apache.org>.
Berin Loritsch wrote:
> Giacomo Pati wrote:
> > Stefano Mazzocchi wrote:
> > > ----- Original Message -----
> > > From: "Allan Erskine" <a....@cs.ucl.ac.uk>
> > > To: <co...@xml.apache.org>
> > > Sent: Friday, February 23, 2001 5:05 AM
> > > Subject: [C2] XSP and apects (was: log performance penalties)
> > >
> > > > ----- Original Message -----
> >
> > <snip/>
> >
> > > > thing for different forms, longing for XSP actions, feeling locked in
> > > > by proprietary sitemap. Just the usual $0.02 worth in other words).
> > >
> > > I don't follow cocoon-users and I believe that placing a rant on
> > > cocoon-users is totally meaningless.
> > >
> > > Cocoon was not designed with webapps in mind, admittely, not even
> > > Cocoon2 so far and the 'action proposal' is not enough thought out to
> > > represent a clear design (even Giacomo agrees with me on this).
> >
> > Unfortunetly, yes, I do agree :/
> > I haven't come to a better solution and all other proposals (thanks for
> > them all) will polute the sitemap with too much semantics IMHO. Semantics
> > which is too much programatic to make it into the sitemap (for now).
> > That's why I haven't agreed (most silently) with the proposers of
> > additional stuff on the action proposal. We still have a lot to think
> > about it. As proposer (and implementor) of the Action proposal into C2 I
> > use it for web apps and I've seen that you can come up with easy
> > solutions but you'll need additional layers which supports your Action
> > coding (ie. access layers like Castor).
>
> I am still working out the bugs, but the new Actions I committed today
> (which when they are debugged will replace the XXXEmployeeAction actions)
> will load a configuration file (an XML file) to set the parameters needed
> for the actions. This lets you set parameters and other things that are
> completely orthagonal to the sitemap.
Yes, I probably think is might be the solution. But still, I don't know if we
need Actions? Can't a Matcher or a Selector take its place? Can't a Matcher
instead of matching URIs match on events? Or be configured with a separate
file as you proposed? Or even have it's own namespace to be configured (I
know this would clutter up the sitemap but it is still separated by
namespace).
Giacomo
> This approach would work for configuring aggregation and other aspects
> without cluttering the sitemap with too many semantics.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Stefano Mazzocchi wrote:
> > ----- Original Message -----
> > From: "Allan Erskine" <a....@cs.ucl.ac.uk>
> > To: <co...@xml.apache.org>
> > Sent: Friday, February 23, 2001 5:05 AM
> > Subject: [C2] XSP and apects (was: log performance penalties)
> >
> > > ----- Original Message -----
> <snip/>
>
> > > thing for different forms, longing for XSP actions, feeling locked in by
> > > proprietary sitemap. Just the usual $0.02 worth in other words).
> >
> > I don't follow cocoon-users and I believe that placing a rant on
> > cocoon-users is totally meaningless.
> >
> > Cocoon was not designed with webapps in mind, admittely, not even Cocoon2
> > so far and the 'action proposal' is not enough thought out to represent a
> > clear design (even Giacomo agrees with me on this).
>
> Unfortunetly, yes, I do agree :/
> I haven't come to a better solution and all other proposals (thanks for them
> all) will polute the sitemap with too much semantics IMHO. Semantics which is
> too much programatic to make it into the sitemap (for now). That's why I
> haven't agreed (most silently) with the proposers of additional stuff on the
> action proposal. We still have a lot to think about it. As proposer (and
> implementor) of the Action proposal into C2 I use it for web apps and I've
> seen that you can come up with easy solutions but you'll need additional
> layers which supports your Action coding (ie. access layers like Castor).
I am still working out the bugs, but the new Actions I committed today (which
when they are debugged will replace the XXXEmployeeAction actions) will load
a configuration file (an XML file) to set the parameters needed for the actions.
This lets you set parameters and other things that are completely orthagonal
to the sitemap.
This approach would work for configuring aggregation and other aspects without
cluttering the sitemap with too many semantics.
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Giacomo Pati <gi...@apache.org>.
Stefano Mazzocchi wrote:
> ----- Original Message -----
> From: "Allan Erskine" <a....@cs.ucl.ac.uk>
> To: <co...@xml.apache.org>
> Sent: Friday, February 23, 2001 5:05 AM
> Subject: [C2] XSP and apects (was: log performance penalties)
>
> > ----- Original Message -----
<snip/>
> > thing for different forms, longing for XSP actions, feeling locked in by
> > proprietary sitemap. Just the usual $0.02 worth in other words).
>
> I don't follow cocoon-users and I believe that placing a rant on
> cocoon-users is totally meaningless.
>
> Cocoon was not designed with webapps in mind, admittely, not even Cocoon2
> so far and the 'action proposal' is not enough thought out to represent a
> clear design (even Giacomo agrees with me on this).
Unfortunetly, yes, I do agree :/
I haven't come to a better solution and all other proposals (thanks for them
all) will polute the sitemap with too much semantics IMHO. Semantics which is
too much programatic to make it into the sitemap (for now). That's why I
haven't agreed (most silently) with the proposers of additional stuff on the
action proposal. We still have a lot to think about it. As proposer (and
implementor) of the Action proposal into C2 I use it for web apps and I've
seen that you can come up with easy solutions but you'll need additional
layers which supports your Action coding (ie. access layers like Castor).
Giacomo
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Allan Erskine <a....@cs.ucl.ac.uk>.
that reply was a great relief - thanks! I was beginning to wonder if I was
missing the point...
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Cc: "Ricardo Rocha" <ri...@apache.org>
Sent: Tuesday, February 27, 2001 12:01 PM
Subject: Re: [C2] XSP and apects (was: log performance penalties)
<snip/>
> Allan Erskine wrote:
> > Assuming a "concern" in this context is taken as delimiting a
> > broad area of interest, such as presentation or application logic, I
> > believe that my use of the word aspect is actually closer to what it
usually
> > means in AOP, namely a feature that crosscuts many system components.
>
> Well, "concerns" and "aspects" are different things, the second more
> granular than the first.
>
> Visual example: if you give me a "concern" as a 3D object, I percieve
> its "aspects" as its projections (shade) to a plane. Of course, there
> are an infinite number of projections of a 3D object onto a 2D plane
> (you just have to move the plane around the rotate its normal!).
>
> So, there are "areas of interest" (concern islands) that share the same
> concerns, this automatically forces the sharing of the aspects these
> concerns convey.
>
> But different concern islands might share the same aspects... in fact,
> it's pretty easy to come up with a list of aspects that are shared by
> all concerns. For example, the concept of "useful" is an aspect, not a
> concern because it applies to concerns and discriminates them, but
> doesn't uniquely identify one.
>
> This is the terminology I use so hopefully this would remove some
> terminology problems that might emerge.
OK...sounds very reasonable, and probably more generally applicable than my
terminology which is closer to the notion of design aspect (lifted from the
aspect J primer).
Design aspect: A feature that crosscuts other design components.
My definition of an implementing an aspect would be any implementation that
captures (and preferably encapsulates) a design aspect (removing the
crosscutting from the implementation).
An implemented aspect could be considered as "encapsulated" if it were
impossible to reproduce whatever was encapsulated outwith the
implementation's constructs. Obviously this could be nigh-on impossible in
a general purpose programming language...but in XSP, with appropriate
control over logicsheets, and restricting the use of the underlying
programming language, it could be very possible....and well worth going for!
Actually what I'm harping on about would probably be the analogue of
separating concerns.
> > The difference between implementing aspects in a general purpose
programming
> > language (like Java) and implementing aspects in a restricted purpose,
but
> > extensible language (like XSP) lies in the manner in which aspects are
> > modularised/captured.
>
> Agreed.
>
> > In aspectJ, the aspect construct is provided as a modularisation unit
for
> > crosscutting concerns.
> Well, no, this is not how I see it (but it's a personal opinion, not an
> objective truth): the above seems to indicate there is no difference
> between a concern and an aspect, being one the technical implementation
> of the other.
>
whoops, sorry, I meant crosscutting _feature_. It's hard to avoid using
such a general word as "concern"! Didn't mean to set you off :)...
> I'd like to keep the two things separated: my concern might be the
> visual presentation of information, the aspects of the problem are
> "usability", "friendlyness", "politeness", "visual coherence", "error
> support", etc...
I'm with this...aspect!=concern
> If your concern is writing application logic, aspects are "visibility"
> (logging), "stability" (concurrency, memory management), "security",
> "modularity", "coherence", "simplicity", "reusability", "longlasting",
> etc...
>
> Many of this "aspects" are implicitly bound into the programming
> language, or the programming paradigm: this is what 'high level' means,
> more aspects are taken into consideration by the programming language or
> contract design.
>
> In fact, design patterns are aspects frames: they give you the "shape"
> of the object and if you use that shape, you automatically have some
> shades, thus some aspects.
>
yep - some design patterns naturally have a design aspect since they
crosscut components, or involve collaborating components. What a lot of
good design patterns have been struggling with has been the lack of good
ways to implement an aspect. Apart from....
> Java is so good at this because it has the "interface" concept: without
> interfaces, Java would be just another OOP language. So, it is entirely
> possible to associate one aspect to one interface and use multiple
> interface extension as a cure to the ugly OO multiple inheritance.
>
> Guess what? This is exactly what we designed in Avalon: the only
> existing AOP framework that doesn't require Java syntax modifications.
> Look at Cocoon2 in Cocoon.java
>
> public class Cocoon
> extends
> AbstractLoggable
> implements
> Component,
> Initializable,
> Modifiable,
> Processor,
> Contextualizable {
*clink* (penny dropping sound from someone just newly arrived from C++)
<snip/>
> Yes, entirely. But this is where I see the problems: just like Java was
> not designed for multi-dimensional separation of concerns in
> programming, XML wasn't either!
>
> XML is the first widely known model that allows multi-dimensionality
> (with namespacing) and since XSP makes heavy use of this, it seems
> logical to percieve an increased functionality and aspect orientation in
> a fully multi-dimensional syntax.
>
> But this rings a bell in my head: are you sure that it's really XSP that
> you like? or rather a collection of "aspects" that XSP itself has?
Nope. Definitely XSP that I like. Although you're right in what you say, I
don't think I'm shooting quite as high as you. I'd like to see better AO
languages, but for now, for my XML server processing, I like XSP because I
can use logicsheet tags to encapsulate what would otherwise be crosscutting
features. I'd like to be able to have this power in areas of my XML
processing other than just pages.
> Would it be better to take the good part of these aspects and carefully
> craft a syntax extension for the Java language, much like the AspectJ
> folks are doing, rather than use XSP a skeleton to provide
> multi-dimensionality to mono-dimensional programming languages?
>
> Hey, look: I don't have an answer for this! I've been fighting with the
> limitations of the OOP paradigm since I proposed the creation of Avalon
> three years ago and I've been very happy to find many people like you
> impressed and intrigued by these new concepts such as SoC, AOP, design
> patterns and all other modern software engineering paradigms.
>
> But deep in my heart, using XSP as a way to turn an OOP language into an
> AOP one, it's a hack: sure, it can be done, but it might include hidden
> mistakes that are not visible at first. One is the XML markup syntax
> which is totally code unfriendly. Another is the intrinsic complexity of
> the XML model: maybe there is a simpler syntax to add these concepts.
In the future, for sure...but for now, I'd be happy to see XSP become a best
of breed XML processing language, no matter how unsuitable XML may be for
languages! It would seem unrealistic to think of dropping the XML from XSP
at this stage!
<snip/>
> > I was thinking here of XSP's potential as a
> > general purpose factory for server components other than
XSPGenerators...it
> > would be a
> > natural for this as it has already started to prove itself as an
integration
> > technology; it would make my life simpler for one to have that
flexibility
> > in component construction available from sitemap calls other than
> > map:generate.
>
> Ah, now I get you: yes, Ricardo and I have been talking about this
> extensively, on how to use the concepts of XSP to generate other parts
> of Cocoon rather than generators.
>
> Of course, transformers come to mind
They certainly do! Definitely a logical step after generators...especially
with sub-pipeline aggregation on the way, could be just the job to address a
bunch of web-app aspects. Is this what you had in mind?...
<xsp:transform>
(access to sax input stream and sax output stream. Consider restricting
access to underlying language, so everyone has to write useful logicsheets)
(bunch of useful logicsheets based round XMLFilter)
(and SAXPath! whoops, got carried away there...)
</xsp:transform>
droool....
> > Decreasing learning costs and improving maintenance is my middle name!
>
> Great to hear that :)
>
> > And also _would_ be a potential benefit of expanding XSP's remit.
> > Decreased learning cost - you just have
> > to learn XSP. Decreased maintanence - XSP markup has demonstrated it's
> > utility in separating concerns, and capturing aspects.
>
> You'll be happy to hear that this is exactly what we discussed: how to
> make XSP 1.1 more general (one thing is to allow to avoid the use of the
> xsp: namespace entirely) and separate the code generation from the
> aspect aggregation semantics.
yessss.....but would removing the namespacing not bump the version up to XSP
2? (wouldn't be backwards compatible would it?)
I agree removing the namespacing would make xsp much more accessible, but
the changes I was thinking of were more minor, and wouldn't break any
compatibility. I was just thinking of adding a couple more xsp types other
than xsp page, that would be distinguished by what was permitted within
each, namely
<xsp:action>
no sax output, and preferably not much control over servlet or cocoon
components other than action parameters (any ideas how you'd separate this
out?!). Access to underlying programming language.
</xsp:action>
<xsp:process>
full control over request/response mechanism and other cocoon
components, but no access to underlying programming language (except through
logicsheets). The sitemap (and sub-sitemaps) would be one of these.
</xsp:process>
<xsp:transform/>...
page would be left the same to maintain compatibility, although ideally
would be
<xsp:page>
control over a sax output stream, no access to underlying programming
language (except through logicsheets). Gentlemans agreement among
logicsheet authors not to do anything that should really belong in
<xsp:action/> (preferably enforcable, but this would be difficult)
</xsp:page>
These are really just my first thoughts, so there's probably alot to
criticise here...
> But we decided to wait until the Cocoon2 core design stabilizes before
> sparkling yet another design quest. Hope you agree with me that too many
> design irons in the fire could dissipate all the creativity energy and
> kill the fire.
Oh, of course, I agree. Still, a little R&D never hurt anyone....;>
> > Following this line of reasoning, the first thing you'd add to XSP would
be
> > the option to insist on only pure markup in an XSP page, no recourse to
the
> > underlying programming language. This is definitely a direction I'd
like to
> > see for XSP, since it would encourage good style and portability, as
well as
> > the development of more powerful, flexible, and self-contained
logicsheets.
>
> Great! This is *exactly* why we want the xsp: namespace out of the way!
> You should be able to write things like
>
> <page>
> <para>Today is <date:today/></para>
> </page>
>
> and forget it!
I'm all for this...! (when the time seems right)
> This allows you to go to document writers and say "look, if you want the
> date, use this tag and it will magically appear". This more or less the
> same concept of word processor "fields" and writers love them!
>
> Forcing them to encapsulate the page into
>
> <xsp:page>
> <page>
> <para>Today is <date:today/></para>
> </page>
> </xsp:page>
>
> is not different from something like
>
> <?xsp?>
> <page>
> <para>Today is <date:today/></para>
> </page>
>
> which is totally bad!!! (as 10 years of HyTime limbo clearly showed!)
>
<snip/>
> Anyway, the ultimate goal for XSP is to be so thin it becomes
> transparent :)
For pages, certainly, sounds great!
> > could ensure markup mixing only occured up to the point anticipated by
the
> > logicsheet authors (if this were appropriate). For example a sitemap
> > logicsheet could declare that the flowmap logicsheet was the only other
> > permissable markup in such hypothetical XSP components. This again
would
> > help enforce separation.
>
> Agreed. This is where the SiLLy language comes in, but Ricardo should be
> the one to talk more about this.
>
I liked the sound of SiLLy when I first arrived in C2land...it's bucked the
trend of C2 components already, by appearing in the docs months before being
implemented!
> > I used the term rationalised because at the moment the sitemap and XSP
pages
> > need to be pre-compiled, cached, re-compiled, aggreated, etc in two
similar
> > but different ways. If another technology, eg a flowmap were to be
added
> > that operated in a third "the same but different" way, would this not be
an
> > indicator that a unification should be sought? Such a unification would
> > presumably rationalise parts of the codebase.
>
> Have you talked with Ricardo lately? :) Gosh, these are more or less the
> same words he's been using. I'm positive that if you give him a hand,
> he'll be pleased to show you his intentions for this 'rationalization'.
Well I'd be very pleased to see them, and of course I'd like to help. I've
been struggling up the C2 curve since Xmas, but I'm getting into it, and
have the debugger set up....
> > XSP's current an future structure is (and should be) an open invitation
to
> > extension, integration, and continued development. I need convinced
> > the same can be said as easily of the sitemap.
>
> Agreed, even if solidity of contracts (that is markup, interfaces and
> the like) is a great value and back incompatibility must be sacrificed
> for the sake of 'elegance' only when it's valuable to do so. (like we
> did with Cocoon2)
The good thing about C2 though is that it's so flexible, and so much of this
is already implemented, it would all slot right in I'm sure....
> That's great.
>
> Ricardo, if you find the time, this call is for you :)
woo...progress...!
- Allan
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Stefano Mazzocchi <st...@apache.org>.
Allan Erskine wrote:
>
> Thanks for the reply. I a bit feel misrepresented on some parts - my
> fault though...(original message was one of these 5am moments
> of "clarity")...I've tried to redress this below; hopefully my suggestions
> won't appear quite as 'out there' this time...apologies to those that regard
> some of this OT....
Absolutely no need to apologize, Allan.
Really, I mean it: it's because of comments such as yours that evolution
takes place. It's a real pleasure for me (but I think I can talk for
everyone around here!) to partecipate in such friendly discussions.
Believe me, it's not as common out of this community.
> > > ----- Original Message -----
> > > From: "Stefano Mazzocchi" <st...@apache.org>
> > >
> > > > Of course, the real solution would be to use AspectJ to code Cocoon,
> but
> > > > I'd rather wait until AspectJ stabilizes before moving to aspect
> > > > oriented programming. [for those of you who don't know what I'm
> talking
> > > > about, look at www.aspectj.org for more info on ASP for Java]
> > > >
> > >
> > > XSP seems nothing short of an aspect abstraction mechanism.
> >
> > Well, thanks for saying this. Interesting enough, this is exactly what
> > Ricardo and I were discussing a months ago privately, the only problem is
> > the XML syntax which is very unfriendly with code.
> >
> > So, while I agree with your vision, I'd suggest to be careful: XSP was
> > designed with SoC in mind as well as ASP. So it's very likely that you
^^^
<typo>read AOP!!</typo>
> > percieve both as the same, but it's logically wrong since XSP (at least
> 1.0,
> > the current) is targetted to server page generation, not to code
> generation
> > in general.
>
> This had occurred to me. Since XSP and
> logicsheets were designed with SoC in mind, might I have confused aspects
> with concerns and pointed out the startlingly obvious?
No, this is not what I percieved.
> Well, hopefully not! Here's where I was coming from...
>
> Assuming a "concern" in this context is taken as delimiting a
> broad area of interest, such as presentation or application logic, I
> believe that my use of the word aspect is actually closer to what it usually
> means in AOP, namely a feature that crosscuts many system components.
Well, "concerns" and "aspects" are different things, the second more
granular than the first.
Visual example: if you give me a "concern" as a 3D object, I percieve
its "aspects" as its projections (shade) to a plane. Of course, there
are an infinite number of projections of a 3D object onto a 2D plane
(you just have to move the plane around the rotate its normal!).
So, there are "areas of interest" (concern islands) that share the same
concerns, this automatically forces the sharing of the aspects these
concerns convey.
But different concern islands might share the same aspects... in fact,
it's pretty easy to come up with a list of aspects that are shared by
all concerns. For example, the concept of "useful" is an aspect, not a
concern because it applies to concerns and discriminates them, but
doesn't uniquely identify one.
This is the terminology I use so hopefully this would remove some
terminology problems that might emerge.
> The difference between implementing aspects in a general purpose programming
> language (like Java) and implementing aspects in a restricted purpose, but
> extensible language (like XSP) lies in the manner in which aspects are
> modularised/captured.
Agreed.
> In aspectJ, the aspect construct is provided as a modularisation unit for
> crosscutting concerns.
Well, no, this is not how I see it (but it's a personal opinion, not an
objective truth): the above seems to indicate there is no difference
between a concern and an aspect, being one the technical implementation
of the other.
I'd like to keep the two things separated: my concern might be the
visual presentation of information, the aspects of the problem are
"usability", "friendlyness", "politeness", "visual coherence", "error
support", etc...
If your concern is writing application logic, aspects are "visibility"
(logging), "stability" (concurrency, memory management), "security",
"modularity", "coherence", "simplicity", "reusability", "longlasting",
etc...
Many of this "aspects" are implicitly bound into the programming
language, or the programming paradigm: this is what 'high level' means,
more aspects are taken into consideration by the programming language or
contract design.
In fact, design patterns are aspects frames: they give you the "shape"
of the object and if you use that shape, you automatically have some
shades, thus some aspects.
Java is so good at this because it has the "interface" concept: without
interfaces, Java would be just another OOP language. So, it is entirely
possible to associate one aspect to one interface and use multiple
interface extension as a cure to the ugly OO multiple inheritance.
Guess what? This is exactly what we designed in Avalon: the only
existing AOP framework that doesn't require Java syntax modifications.
Look at Cocoon2 in Cocoon.java
public class Cocoon
extends
AbstractLoggable
implements
Component,
Initializable,
Modifiable,
Processor,
Contextualizable {
It is evident that pure OOP practices are becoming obsolete in those
fields where concepts become too abstract to be 'synthetized' into
behavioral objects.
But Java was *NOT* designed with AOP in mind (only the interface concept
has influence from this late accademic research). So we are left with
the question: can it be turned into a full AOP language?
> In XSP, what appears to happen is that markup is chosen to
> represents and encapsulate what would otherwise be a crosscutting feature,
> that is to say,
> markup-constructs are being deliberately chosen to capture aspects.
> (regardless of whether the
> crosscutting feature/aspect represents a complete concern area).
This is correct. I resonate with this view.
> And so my proposition is just the simple observation that as well as being
> pivotal in separating the concerns in cocoon's "pyramid of contracts" model,
> XSP markup is flexible enough to capture aspects that would crosscut the
> system if hardcoded. This is why I'm a *fan* of XSP, and would seek to
> expand and refine it's role.
>
> I hope this sounds reasonable...
Yes, entirely. But this is where I see the problems: just like Java was
not designed for multi-dimensional separation of concerns in
programming, XML wasn't either!
XML is the first widely known model that allows multi-dimensionality
(with namespacing) and since XSP makes heavy use of this, it seems
logical to percieve an increased functionality and aspect orientation in
a fully multi-dimensional syntax.
But this rings a bell in my head: are you sure that it's really XSP that
you like? or rather a collection of "aspects" that XSP itself has?
Would it be better to take the good part of these aspects and carefully
craft a syntax extension for the Java language, much like the AspectJ
folks are doing, rather than use XSP a skeleton to provide
multi-dimensionality to mono-dimensional programming languages?
Hey, look: I don't have an answer for this! I've been fighting with the
limitations of the OOP paradigm since I proposed the creation of Avalon
three years ago and I've been very happy to find many people like you
impressed and intrigued by these new concepts such as SoC, AOP, design
patterns and all other modern software engineering paradigms.
But deep in my heart, using XSP as a way to turn an OOP language into an
AOP one, it's a hack: sure, it can be done, but it might include hidden
mistakes that are not visible at first. One is the XML markup syntax
which is totally code unfriendly. Another is the intrinsic complexity of
the XML model: maybe there is a simpler syntax to add these concepts.
Anyway, whatever happens it's good and healthy to discuss these things.
> > > Aspects of
> > > server processing can be abstracted by tags, and modularised by
> namespace
> > > prefixing.
> >
> > Yes, but I believe that it would be *much* better to avoid using the XML
> > syntax for that if all you want is code generation.
>
> I agree; server-side presentation processing is my sole concern here.
Ah, ok. I was talking more generally.
> > > Even language and platform choice are aspects unders XSP's remit
> > > (witness AxKit). Surely too useful for just pages (which are becoming
> an
> > > outmoded concept anyway). Besides, being eXtensible conflicts with
> being
> > > restricted to page serving...
> >
> > Well, eXtensible doesn't mean "must do everything and brew coffee"
>
> Sure...thanks for trying to set me straight. While being fully aware of the
> dangers of FS, I also think you have to recognise the futility of not
> following ideas through to full utility. And XSP + logicsheets strike me as
> a very worthy combo for further development.
Oh, totally.
My role in this project has always been that of fueling innovation by
vaporizing random thoughts in the air and ignite it. Sort of mental
napalm, if you wish :)
But at the same time, balance this role with FS devil's advocate since
it's incredibly easy to get burned out by the powerful sensation of
intellectual creationism, which, in turn, becomes ego denfense,
code-less pride and, ultimately, negative social energy.
Careful: I'm not saying this is your case, not even close. Just wanted
to outline the path I try to follow and when I smell FS, I have to say
so.... then you are forced to go back and rethink about how much of FS
there is in your reasoning and you "clean it up", by removing everything
but the core.
Normally, it's in the core that the ideas reside.
And the process of removing FS from a intellectual creation, it's both a
difficul and a very stimulating one.
The fact that so many people use these design metodologies themselves
because they learned them from me makes me even more proud than all my
other technological achievements.
So, yes, I completely recognize the "futility of not following ideas
through to full utility". Absolutely, it's my creed! But every change
increases geometrically the number of variables it influences, so every
step forward must be carefully elaborated.
You might wonder: how can this work, then? well, just like debugging,
design decomposition and FS debugging is parallelizable and we are more
and more every day.
> > > IMHO, XSP's scope should be broadened to include server processes
> > (sitemaps,
> > > actions, ...), and XML fragment generation.
> >
> > As for XML fragment generation, this will be already in place once
> 'content
> > aggregation' is implemented.
> >
> > As for sitemaps and actions, I completely disagree: if you mean that java
> > falls short since it's not really aspect oriented, well, I totally agree
> > with you, but if you believe that using the XML syntax to add aspects to
> > java, well, I believe this is big time FS.
>
> See opening statements...I'm not trying to use XML to add aspects to
> anything - I'm merely noting the facility of XSP + logicsheets to delineate
> aspects within an XML server system...what I'm wondering is, can this power
> can be successfully and appropriately utilised elsewhere (ie other than just
> page generation)?
Good question.
> > > I truly believe this would be
> > > powerful beyond belief (esp with recursive sitemap calling, and
> > sub-pipeline
> > > includes)
> >
> > recursive sitemap calling? are you kidding? Please, this is *exactly* the
> > reasoning path that leads to flexibility syndrome: if 'a' and 'b' are
> great,
> > extending to 'z' will make it better. This is, generally, wrong since it
> > doesn't take into consideration the 'costs' of such an approach. Cost in
> > both learning, using and, even more important, maintaining.
>
> OK - that was the 5am clarity statement. Forgive my hyperbole, but please
> don't dismiss me out of hand.
:) ok
> I was thinking here of XSP's potential as a
> general purpose factory for server components other than XSPGenerators...it
> would be a
> natural for this as it has already started to prove itself as an integration
> technology; it would make my life simpler for one to have that flexibility
> in component construction available from sitemap calls other than
> map:generate.
Ah, now I get you: yes, Ricardo and I have been talking about this
extensively, on how to use the concepts of XSP to generate other parts
of Cocoon rather than generators.
Of course, transformers come to mind
> Decreasing learning costs and improving maintenance is my middle name!
Great to hear that :)
> And also _would_ be a potential benefit of expanding XSP's remit.
> Decreased learning cost - you just have
> to learn XSP. Decreased maintanence - XSP markup has demonstrated it's
> utility in separating concerns, and capturing aspects.
You'll be happy to hear that this is exactly what we discussed: how to
make XSP 1.1 more general (one thing is to allow to avoid the use of the
xsp: namespace entirely) and separate the code generation from the
aspect aggregation semantics.
But we decided to wait until the Cocoon2 core design stabilizes before
sparkling yet another design quest. Hope you agree with me that too many
design irons in the fire could dissipate all the creativity energy and
kill the fire.
> > And, last but not least, understanding the impact over SoC and the cost
> > metrics of a web publishing framework: making a sitemap programmable
> > directly is not only dangerous, is WRONG.
> >
> > I repeat: WRONG!
>
> Again I agree: *WRONG!*. So here's where you'd start to think of improving
> XSP instead, precisely to address your concerns. And if we agree that the
> language independance of XSP pages has to an extent encapsulated the "choice
> of implementation language" aspect, then _any_ language specific programming
> constructs in XSP are WRONG, since they break this encapsulation!
Totally!
> Following this line of reasoning, the first thing you'd add to XSP would be
> the option to insist on only pure markup in an XSP page, no recourse to the
> underlying programming language. This is definitely a direction I'd like to
> see for XSP, since it would encourage good style and portability, as well as
> the development of more powerful, flexible, and self-contained logicsheets.
Great! This is *exactly* why we want the xsp: namespace out of the way!
You should be able to write things like
<page>
<para>Today is <date:today/></para>
</page>
and forget it!
This allows you to go to document writers and say "look, if you want the
date, use this tag and it will magically appear". This more or less the
same concept of word processor "fields" and writers love them!
Forcing them to encapsulate the page into
<xsp:page>
<page>
<para>Today is <date:today/></para>
</page>
</xsp:page>
is not different from something like
<?xsp?>
<page>
<para>Today is <date:today/></para>
</page>
which is totally bad!!! (as 10 years of HyTime limbo clearly showed!)
> An XSP sitemap would be a sterling example to future logicsheet authors,
> precisely because programmability would be disabled, and the logicsheet
> represent all possible configurations of a self-contained and powerful XML
> server component.
Oh, I get you now. Yeah, in fact, this is already in place, more or
less. The sitemap compilation uses the same machinery XSP uses (Ricardo
wanted to refactor it out even more because there is some overlap left)
and yes, the sitemap markup can be seen as, more or less, taglibs.
Now that I think about it, the use of aspects in the sitemap (actions?
security?) could be associated to a different namespace.... hmmm I
wonder where this would lead... good reasoning though...
Anyway, the ultimate goal for XSP is to be so thin it becomes
transparent :)
> An additional restriction to consider would be to allow a logicsheet to
> declare itself uncompatible with anything but "friend" logicsheets, or at
> least to declare that they can only be used in certain restricted contexts.
> This
> could ensure markup mixing only occured up to the point anticipated by the
> logicsheet authors (if this were appropriate). For example a sitemap
> logicsheet could declare that the flowmap logicsheet was the only other
> permissable markup in such hypothetical XSP components. This again would
> help enforce separation.
Agreed. This is where the SiLLy language comes in, but Ricardo should be
the one to talk more about this.
> > because who administers the sitemap (the usability engineer, you might
> want
> > to call it) is almost never a programmer (programmers, by definition, have
> a
> > distorted view of usability anyway) and publishing systems have a very
> well
> > defined set of aspects, components and behaviors that must not be left to
> > everyone to rediscover or reinvent.
>
> Again I say make it a feature of XSP to allow disabling of programming
> constructs, and even allow disabling other logicsheets (ie, allow to specify
> that a logicsheet can only be used standalone). This I believe would
> benefit XSP; in general I believe expanding the remit of XSP would lead to
> a synergy between the development of XSP with the development of integrated
> XML
> technology solutions within it. With appropriate refinements in place, I
> don't see the obstacle to having an XSP sitemap, rather I see the benefit.
Now that I understand you, I totally agree.
> > This is what a framework is: experience distilled into practices.
>
> I know this. Experience can also be distilled into combinations of markup
> constructs. This is the driving force for the creation of XSP
> logicsheets...but so long as XSP is restricted to pages, and not more
> general XML server processes, I'm not convinced how strong this driving
> force will be.
>
> Besides, some logicsheet tags already sit very uncomfortably between
> xsp:page tags, IMO, and this alone should be enough to start forcing a new
> development in the language. A large proportion of the ldap, esql, and
> sendmail tags should really belong in a new XSP construct for marking up XML
> server processes. What does sending an email or updating a database have to
> do with generating a page? And as for the SOAP taglib....
>
> I think this alone is worth some attention...
Yes, yes, I agree!!
> > >, and it could be done without breaking the current XSP. In a
> > > stroke, XSP's profile would be boosted, and C2 would be less proprietary
> > > (becoming a framework for XSP publishing components). C2's codebase
> would
> > > also presumably shrink and be rationalised.
> >
> > proprietary? rationalized? are we talking about the same Cocoon?
>
> I'm terribly sorry! Proprietary could hardly be a worse word to use for one
> of the most open of open source projects. But still, saying "cocoon has
> an XSP language for integrating technologies with markup constructs, but
> only within "pages", whatever they are, and it also has a sitemap" sounds
> more proprietary to me than "cocoon is a platform for integrating
> XML server technologies using XSP, an extensible XML server processing
> language"
Bad terminology but good point. In fact, now that I understand you, I
can tell you that many core developers feel exactly the same as you on
this and, unfortunately, Ricardo's lack of time (and intrinsic
complexity of the matter!) has been deprimental to the whole cause.
But I'm sure things will change as Cocoon2 stabilizes and rough edges
will be smoothed.
> I used the term rationalised because at the moment the sitemap and XSP pages
> need to be pre-compiled, cached, re-compiled, aggregated, etc in two similar
> but different ways. If another technology, eg a flowmap were to be added
> that operated in a third "the same but different" way, would this not be an
> indicator that a unification should be sought? Such a unification would
> presumably rationalise parts of the codebase.
Have you talked with Ricardo lately? :) Gosh, these are more or less the
same words he's been using. I'm positive that if you give him a hand,
he'll be pleased to show you his intentions for this 'rationalization'.
> XSP's current an future structure is (and should be) an open invitation to
> extension, integration, and continued development. I need convinced
> the same can be said as easily of the sitemap.
Agreed, even if solidity of contracts (that is markup, interfaces and
the like) is a great value and back incompatibility must be sacrificed
for the sake of 'elegance' only when it's valuable to do so. (like we
did with Cocoon2)
> > > (conclusion reached after following Uli's application rant on
> > cocoon-users,
> > > and developing my own C2 web-app, writing action after action to do the
> > same
> > > thing for different forms, longing for XSP actions, feeling locked in by
> > > proprietary sitemap. Just the usual $0.02 worth in other words).
> >
> > I don't follow cocoon-users and I believe that placing a rant on
> > cocoon-users is totally meaningless.
>
> When Uli used the term rant, it was only in humility I'm sure. The thread
> he started should have been entitiled "a timely expose and invitation
> to discussion of cocoon in web-apps". Several other threads on
> cocoon-users have gone this way recently too...
>
> > Cocoon was not designed with webapps in mind, admittely, not even Cocoon2
> so
> > far and the 'action proposal' is not enough thought out to represent a
> clear
> > design (even Giacomo agrees with me on this).
> >
> > Admittedly, this is a problem, but moving XSP to cover everything results
> in
> > costs many will not be able to afford.
>
> I hope I'm not being dim-witted, but I still don't quite understand what
> these costs might be... Unification of concept isn't a cost. The sitemap
> could probably
> already be hacked into an XSP page (using inner classes perhaps?) as it
> stands (not that I'd recommend this). Some simple refinements to XSP could
> make for the simple, powerful and flexible configuration of a myriad cocoon
> components, as well as broadening XSP's scope. I'm afraid I am still in
> need of further enlightenment as to why this is not appropriate...
No, forget this, it was based on my wrong understanding of what you mean
by "refactoring and integration". Now I'm confident I agree with you on
almost anything you've been saying.
> > Do you want a design that brings Cocoon's publishing elegance to include
> the
> > functionality required by web applications? I do. I feel this is the only
> > thing that might impact the Cocoon API and thus, the only thing that stops
> > us for entering 'beta' state.
> >
> > How do we do that? are actions and HTTP action handlers enough? how
> reusable
> > can be make actions? how granular the MVC patterns can be applied to the
> > generation stage? how much overlap there is between existing solutions
> like
> > Turbine or Struts, how much can we reuse of their models?
> >
> > Making the sitemap directly programmable is nothing different from writing
> a
> > big servlet that uses Cocoon components as it wishes. Result: 'subversion
> of
> > control'. Another big anti-pattern.
>
> Just to reiterate, I don't recommend this. I do wonder though of the
> potential in new XSP constructs (some being explicitly unprogrammable
> except through logicsheet markup), and consequently of XSP's suitability
> across the board as the language of XML servers.
Sorry, this was the contextual mistake that stirred the discussion in
the wrong direction. Glad to find the context reestablished.
> > > (and thanks to Paul Russel for the interesting reply to similar email on
> > > cocoon users...hope for the same, to shut me up once and for all about
> > > xsp sitemaps, or otherwise:)
> >
> > Cocoon was designed with the idea that POST actions were handled by
> > something else. This has never been stated, but after careful thinking I
> > believe there is a specific asymmetry in how the system was designed.
> > Result: in Cocoon, GET is natural, POST is ackward.
> >
> > This is what generates friction and ranting.
> >
> > But I reanalized the architecture and found no evidence of this asymmetry
> in
> > the design, it's just a consequence of lack of focus on web applications.
> > Cocoon maps the IoC model of servlets and, just like servlets, it's
> totally
> > agnostic on how you build your web application, unlike frameworks like
> > Turbine or Struts that create patterns internally at the generation stage.
> >
> > Cocoon personalization is based on generators: just like pure servlet
> > programming is hard and expensive, pure generator programming by code is
> > hard and expensive. So, what do we do?
> >
> > Following the JSP patterns, we created the Cocoon equivalent of JSP model
> 1
> > with XSP, but we stopped there: XSP were not designed with model 2 in
> mind,
> > thus MVC is not implemented in its design, but it's left to the ability of
> > the XSP author.
> >
> > There are a few questions that we need to answer:
> >
> > 1) how do we implement MVC in generators? (extend/modify XSP or use
> things
> > like Velocity/WebMacro)
> > 2) are actions general enough to belong to the sitemap?
> > 3) sitemaps are declarative pattern matching based on request and there
> is
> > no notion of flow, which is left implicit inside the web application. Is
> > there a way to identify a "flowmap"? Is this information useful? can this
> > enforce the use of top/down design on web applications, working along with
> > the usability engineer?
> >
> > making the sitemap more programmable is not an advancement, it's a hack.
>
> Just to reiterate, this was not what I was proposing.
Cool.
> > what we need is more thinking not rants.
>
> I'm thinking - I'm thinking!! I'm also an experienced developer with some
> time on my hands (became a student again..ahhhh relief!)...I'd like to be
> able to find common ground here, and hopefully muck in...
That's great.
Ricardo, if you find the time, this call is for you :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Allan Erskine <a....@cs.ucl.ac.uk>.
Thanks for the reply. I a bit feel misrepresented on some parts - my
fault though...(original message was one of these 5am moments
of "clarity")...I've tried to redress this below; hopefully my suggestions
won't appear quite as 'out there' this time...apologies to those that regard
some of this OT....
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "cocoon-dev" <co...@xml.apache.org>
Sent: Friday, February 23, 2001 12:59 PM
Subject: Re: [C2] XSP and apects (was: log performance penalties)
> ----- Original Message -----
> From: "Allan Erskine" <a....@cs.ucl.ac.uk>
> To: <co...@xml.apache.org>
> Sent: Friday, February 23, 2001 5:05 AM
> Subject: [C2] XSP and apects (was: log performance penalties)
>
>
> > ----- Original Message -----
> > From: "Stefano Mazzocchi" <st...@apache.org>
> >
> > > Of course, the real solution would be to use AspectJ to code Cocoon,
but
> > > I'd rather wait until AspectJ stabilizes before moving to aspect
> > > oriented programming. [for those of you who don't know what I'm
talking
> > > about, look at www.aspectj.org for more info on ASP for Java]
> > >
> >
> > XSP seems nothing short of an aspect abstraction mechanism.
>
> Well, thanks for saying this. Interesting enough, this is exactly what
> Ricardo and I were discussing a months ago privately, the only problem is
> the XML syntax which is very unfriendly with code.
>
> So, while I agree with your vision, I'd suggest to be careful: XSP was
> designed with SoC in mind as well as ASP. So it's very likely that you
> percieve both as the same, but it's logically wrong since XSP (at least
1.0,
> the current) is targetted to server page generation, not to code
generation
> in general.
This had occurred to me. Since XSP and
logicsheets were designed with SoC in mind, might I have confused aspects
with concerns and pointed out the startlingly obvious?
Well, hopefully not! Here's where I was coming from...
Assuming a "concern" in this context is taken as delimiting a
broad area of interest, such as presentation or application logic, I
believe that my use of the word aspect is actually closer to what it usually
means in AOP, namely a feature that crosscuts many system components.
The difference between implementing aspects in a general purpose programming
language (like Java) and implementing aspects in a restricted purpose, but
extensible language (like XSP) lies in the manner in which aspects are
modularised/captured.
In aspectJ, the aspect construct is provided as a modularisation unit for
crosscutting concerns.
In XSP, what appears to happen is that markup is chosen to
represents and encapsulate what would otherwise be a crosscutting feature,
that is to say,
markup-constructs are being deliberately chosen to capture aspects.
(regardless of whether the
crosscutting feature/aspect represents a complete concern area).
And so my proposition is just the simple observation that as well as being
pivotal in separating the concerns in cocoon's "pyramid of contracts" model,
XSP markup is flexible enough to capture aspects that would crosscut the
system if hardcoded. This is why I'm a *fan* of XSP, and would seek to
expand and refine it's role.
I hope this sounds reasonable...
> > Aspects of
> > server processing can be abstracted by tags, and modularised by
namespace
> > prefixing.
>
> Yes, but I believe that it would be *much* better to avoid using the XML
> syntax for that if all you want is code generation.
I agree; server-side presentation processing is my sole concern here.
> > Even language and platform choice are aspects unders XSP's remit
> > (witness AxKit). Surely too useful for just pages (which are becoming
an
> > outmoded concept anyway). Besides, being eXtensible conflicts with
being
> > restricted to page serving...
>
> Well, eXtensible doesn't mean "must do everything and brew coffee"
Sure...thanks for trying to set me straight. While being fully aware of the
dangers of FS, I also think you have to recognise the futility of not
following ideas through to full utility. And XSP + logicsheets strike me as
a very worthy combo for further development.
> > IMHO, XSP's scope should be broadened to include server processes
> (sitemaps,
> > actions, ...), and XML fragment generation.
>
> As for XML fragment generation, this will be already in place once
'content
> aggregation' is implemented.
>
> As for sitemaps and actions, I completely disagree: if you mean that java
> falls short since it's not really aspect oriented, well, I totally agree
> with you, but if you believe that using the XML syntax to add aspects to
> java, well, I believe this is big time FS.
See opening statements...I'm not trying to use XML to add aspects to
anything - I'm merely noting the facility of XSP + logicsheets to delineate
aspects within an XML server system...what I'm wondering is, can this power
can be successfully and appropriately utilised elsewhere (ie other than just
page generation)?
> > I truly believe this would be
> > powerful beyond belief (esp with recursive sitemap calling, and
> sub-pipeline
> > includes)
>
> recursive sitemap calling? are you kidding? Please, this is *exactly* the
> reasoning path that leads to flexibility syndrome: if 'a' and 'b' are
great,
> extending to 'z' will make it better. This is, generally, wrong since it
> doesn't take into consideration the 'costs' of such an approach. Cost in
> both learning, using and, even more important, maintaining.
OK - that was the 5am clarity statement. Forgive my hyperbole, but please
don't dismiss me out of hand. I was thinking here of XSP's potential as a
general purpose factory for server components other than XSPGenerators...it
would be a
natural for this as it has already started to prove itself as an integration
technology; it would make my life simpler for one to have that flexibility
in component construction available from sitemap calls other than
map:generate.
Decreasing learning costs and improving maintenance is my middle name! And
also _would_ be a potential benefit of expanding XSP's remit. Decreased
learning cost - you just have
to learn XSP. Decreased maintanence - XSP markup has demonstrated it's
utility in separating concerns, and capturing aspects.
> And, last but not least, understanding the impact over SoC and the cost
> metrics of a web publishing framework: making a sitemap programmable
> directly is not only dangerous, is WRONG.
>
> I repeat: WRONG!
Again I agree: *WRONG!*. So here's where you'd start to think of improving
XSP instead, precisely to address your concerns. And if we agree that the
language independance of XSP pages has to an extent encapsulated the "choice
of implementation language" aspect, then _any_ language specific programming
constructs in XSP are WRONG, since they break this encapsulation!
Following this line of reasoning, the first thing you'd add to XSP would be
the option to insist on only pure markup in an XSP page, no recourse to the
underlying programming language. This is definitely a direction I'd like to
see for XSP, since it would encourage good style and portability, as well as
the development of more powerful, flexible, and self-contained logicsheets.
An XSP sitemap would be a sterling example to future logicsheet authors,
precisely because programmability would be disabled, and the logicsheet
represent all possible configurations of a self-contained and powerful XML
server component.
An additional restriction to consider would be to allow a logicsheet to
declare itself uncompatible with anything but "friend" logicsheets, or at
least to declare that they can only be used in certain restricted contexts.
This
could ensure markup mixing only occured up to the point anticipated by the
logicsheet authors (if this were appropriate). For example a sitemap
logicsheet could declare that the flowmap logicsheet was the only other
permissable markup in such hypothetical XSP components. This again would
help enforce separation.
> because who administers the sitemap (the usability engineer, you might
want
> to call it) is almost never a programmer (programmers, by definition, have
a
> distorted view of usability anyway) and publishing systems have a very
well
> defined set of aspects, components and behaviors that must not be left to
> everyone to rediscover or reinvent.
Again I say make it a feature of XSP to allow disabling of programming
constructs, and even allow disabling other logicsheets (ie, allow to specify
that a logicsheet can only be used standalone). This I believe would
benefit XSP; in general I believe expanding the remit of XSP would lead to
a synergy between the development of XSP with the development of integrated
XML
technology solutions within it. With appropriate refinements in place, I
don't see the obstacle to having an XSP sitemap, rather I see the benefit.
> This is what a framework is: experience distilled into practices.
I know this. Experience can also be distilled into combinations of markup
constructs. This is the driving force for the creation of XSP
logicsheets...but so long as XSP is restricted to pages, and not more
general XML server processes, I'm not convinced how strong this driving
force will be.
Besides, some logicsheet tags already sit very uncomfortably between
xsp:page tags, IMO, and this alone should be enough to start forcing a new
development in the language. A large proportion of the ldap, esql, and
sendmail tags should really belong in a new XSP construct for marking up XML
server processes. What does sending an email or updating a database have to
do with generating a page? And as for the SOAP taglib....
I think this alone is worth some attention...
> >, and it could be done without breaking the current XSP. In a
> > stroke, XSP's profile would be boosted, and C2 would be less proprietary
> > (becoming a framework for XSP publishing components). C2's codebase
would
> > also presumably shrink and be rationalised.
>
> proprietary? rationalized? are we talking about the same Cocoon?
I'm terribly sorry! Proprietary could hardly be a worse word to use for one
of the most open of open source projects. But still, saying "cocoon has
an XSP language for integrating technologies with markup constructs, but
only within "pages", whatever they are, and it also has a sitemap" sounds
more proprietary to me than "cocoon is a platform for integrating
XML server technologies using XSP, an extensible XML server processing
language"
I used the term rationalised because at the moment the sitemap and XSP pages
need to be pre-compiled, cached, re-compiled, aggregated, etc in two similar
but different ways. If another technology, eg a flowmap were to be added
that operated in a third "the same but different" way, would this not be an
indicator that a unification should be sought? Such a unification would
presumably rationalise parts of the codebase.
XSP's current an future structure is (and should be) an open invitation to
extension, integration, and continued development. I need convinced
the same can be said as easily of the sitemap.
> > (conclusion reached after following Uli's application rant on
> cocoon-users,
> > and developing my own C2 web-app, writing action after action to do the
> same
> > thing for different forms, longing for XSP actions, feeling locked in by
> > proprietary sitemap. Just the usual $0.02 worth in other words).
>
> I don't follow cocoon-users and I believe that placing a rant on
> cocoon-users is totally meaningless.
When Uli used the term rant, it was only in humility I'm sure. The thread
he started should have been entitiled "a timely expose and invitation
to discussion of cocoon in web-apps". Several other threads on
cocoon-users have gone this way recently too...
> Cocoon was not designed with webapps in mind, admittely, not even Cocoon2
so
> far and the 'action proposal' is not enough thought out to represent a
clear
> design (even Giacomo agrees with me on this).
>
> Admittedly, this is a problem, but moving XSP to cover everything results
in
> costs many will not be able to afford.
I hope I'm not being dim-witted, but I still don't quite understand what
these costs might be... Unification of concept isn't a cost. The sitemap
could probably
already be hacked into an XSP page (using inner classes perhaps?) as it
stands (not that I'd recommend this). Some simple refinements to XSP could
make for the simple, powerful and flexible configuration of a myriad cocoon
components, as well as broadening XSP's scope. I'm afraid I am still in
need of further enlightenment as to why this is not appropriate...
> Do you want a design that brings Cocoon's publishing elegance to include
the
> functionality required by web applications? I do. I feel this is the only
> thing that might impact the Cocoon API and thus, the only thing that stops
> us for entering 'beta' state.
>
> How do we do that? are actions and HTTP action handlers enough? how
reusable
> can be make actions? how granular the MVC patterns can be applied to the
> generation stage? how much overlap there is between existing solutions
like
> Turbine or Struts, how much can we reuse of their models?
>
> Making the sitemap directly programmable is nothing different from writing
a
> big servlet that uses Cocoon components as it wishes. Result: 'subversion
of
> control'. Another big anti-pattern.
Just to reiterate, I don't recommend this. I do wonder though of the
potential in new XSP constructs (some being explicitly unprogrammable
except through logicsheet markup), and consequently of XSP's suitability
across the board as the language of XML servers.
> > (and thanks to Paul Russel for the interesting reply to similar email on
> > cocoon users...hope for the same, to shut me up once and for all about
> > xsp sitemaps, or otherwise:)
>
> Cocoon was designed with the idea that POST actions were handled by
> something else. This has never been stated, but after careful thinking I
> believe there is a specific asymmetry in how the system was designed.
> Result: in Cocoon, GET is natural, POST is ackward.
>
> This is what generates friction and ranting.
>
> But I reanalized the architecture and found no evidence of this asymmetry
in
> the design, it's just a consequence of lack of focus on web applications.
> Cocoon maps the IoC model of servlets and, just like servlets, it's
totally
> agnostic on how you build your web application, unlike frameworks like
> Turbine or Struts that create patterns internally at the generation stage.
>
> Cocoon personalization is based on generators: just like pure servlet
> programming is hard and expensive, pure generator programming by code is
> hard and expensive. So, what do we do?
>
> Following the JSP patterns, we created the Cocoon equivalent of JSP model
1
> with XSP, but we stopped there: XSP were not designed with model 2 in
mind,
> thus MVC is not implemented in its design, but it's left to the ability of
> the XSP author.
>
> There are a few questions that we need to answer:
>
> 1) how do we implement MVC in generators? (extend/modify XSP or use
things
> like Velocity/WebMacro)
> 2) are actions general enough to belong to the sitemap?
> 3) sitemaps are declarative pattern matching based on request and there
is
> no notion of flow, which is left implicit inside the web application. Is
> there a way to identify a "flowmap"? Is this information useful? can this
> enforce the use of top/down design on web applications, working along with
> the usability engineer?
>
> making the sitemap more programmable is not an advancement, it's a hack.
Just to reiterate, this was not what I was proposing.
> what we need is more thinking not rants.
I'm thinking - I'm thinking!! I'm also an experienced developer with some
time on my hands (became a student again..ahhhh relief!)...I'd like to be
able to find common ground here, and hopefully muck in...
- Allan
> Stefano.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
Re: Errr, what is IoC?
Posted by Eung-ju Park <co...@isoft.co.kr>.
IoC = Inversion of Control.
see http://jakarta.apache.org/avalon/inversion-of-control.html
:-)
----- Original Message -----
From: "Tagunov Anthony" <at...@nnt.ru>
To: <co...@xml.apache.org>
Sent: Monday, February 26, 2001 1:52 AM
Subject: Errr, what is IoC?
> On Fri, 23 Feb 2001 13:59:39 +0100, Stefano Mazzocchi wrote:
>
> >Cocoon maps the IoC model of servlets and, just like servlets, it's
totally
>
> Please, excuse my ignorance, but.. SoC = separation of conserns, what is
IoC?
>
> Best regards, Tagunov Anthony
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
Errr, what is IoC?
Posted by Tagunov Anthony <at...@nnt.ru>.
On Fri, 23 Feb 2001 13:59:39 +0100, Stefano Mazzocchi wrote:
>Cocoon maps the IoC model of servlets and, just like servlets, it's totally
Please, excuse my ignorance, but.. SoC = separation of conserns, what is IoC?
Best regards, Tagunov Anthony
Re: AW: log performance penalties
Posted by Giacomo Pati <gi...@apache.org>.
Berin Loritsch wrote:
> Carsten Ziegeler wrote:
> > > Stefano Mazzocchi [mailto:stefano@apache.org] wrote:
> > >
> > > Tagunov Anthony wrote:
> > >> Sure, this approach is not universal..
> > >>
> > >> 1)
> > >> As for number of parameters:
> > >> i personally see no trouble in
> > >> having 9 .log methods with number of parameters from 1 to 9
> > >> respecitvely, if it saves performance! And I beleive there's a sane
> > >> limit that a regular log request does not come over..
> > >
> > >The solution is to remove the code completely.
> > >
> > >I'm not sure how many of you know this but this Java code
> > >
> > > final boolean LOG = false;
> > > if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
> > >test");
> > >
> > >is compiled into
> > >
> > > final boolean LOG = false;
> > >
> > >that's it! the code is gone! try it yourself with javap.
I belive this is because javac knows at compiletime that LOG cannot be
anything else that false.
> > >
> > >This is the fastest solution available: no code executed no time lost.
> > >
> > >Of course, this requires a pretty good 'coding style' and coherence
> > >thruout the entire code and makes it more unreadable for those who are
> > >not aware of this java feature... but it's much better than having
> > >things like
> > >
> > >// #ifdef LOG
> > > if (logger.debugIsActive()) logger.debug("this" + is + "a test");
> > >// #endif
> > >
> > >which must be preprocessed before generating the code.
> > >
> > >Of course, the real solution would be to use AspectJ to code Cocoon, but
> > >I'd rather wait until AspectJ stabilizes before moving to aspect
> > >oriented programming. [for those of you who don't know what I'm talking
> > >about, look at www.aspectj.org for more info on ASP for Java]
> >
> > I would suggest we start converting/implementing the logging in the way
> > Stefano suggested. Either by
> > 1. if (logger.debugIsActive()) logger.debug(...)
> > or
> > 2. if (LOG && logger.debugIsActive()) logger.debug(...)
> >
> > Allthough I see the advantage in 2. I would vote for 1., because logging
> > can be controlled simply by changing the configuration without
> > recompilation. Number 2. would require changing many places for turning
> > LOG on and off. Or has something like
> > class Cocoon {
> > public static final boolean LOG = true;
> > }
Well, haven't tried it but I think this will not produce the same results as
the example above from Stefano because javac might not necessaraly know the
value of Cocoon.LOG at compile time (I must admit I haven't checked it
out).
> >
> > with if (Cocoon.LOG && logger.debugIsActive()) the same effective? Then I
> > could imagine to use 2.
> >
> > What do you think? In which way should we start converting?
>
> The final solution you proposed would be best, as we would not have
> a Cocoon Logger class floating around. Don't be locked into
> public static final and setting it there.
>
> You have two choices with that approach:
>
> Modify Ant to build a LOGGABLE version or LOG_DISABLED version of
> Cocoon. This has the advantage of placing the boolean in the
> Constants file:
>
> public interface Constant {
> String LOG = "{$DO.LOGGING}";
> ........
> }
I propose we should be able to configure the amount of log information by
means of the log-level in the web.xml file AND have it perform accordingly
(think of a C2 binary distribution which should be available someday).
> Modify an object to provide a static function that records whether
> to log or not:
>
> public class LogUtil {
> public static Logger getLogger();
> public static void setLogger();
>
> public static boolean doLog();
> ....
> }
Giacomo
Re: AW: log performance penalties
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > Stefano Mazzocchi [mailto:stefano@apache.org] wrote:
> > Tagunov Anthony wrote:
> >
> >> Sure, this approach is not universal..
> >>
> >> 1)
> >> As for number of parameters:
> >> i personally see no trouble in
> >> having 9 .log methods with number of parameters from 1 to 9 respecitvely, if
> >> it saves performance! And I beleive there's a sane limit that a regular
> >> log request does not come over..
> >
> >The solution is to remove the code completely.
> >
> >I'm not sure how many of you know this but this Java code
> >
> > final boolean LOG = false;
> > if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
> >test");
> >
> >is compiled into
> >
> > final boolean LOG = false;
> >
> >that's it! the code is gone! try it yourself with javap.
> >
> >This is the fastest solution available: no code executed no time lost.
> >
> >Of course, this requires a pretty good 'coding style' and coherence
> >thruout the entire code and makes it more unreadable for those who are
> >not aware of this java feature... but it's much better than having
> >things like
> >
> >// #ifdef LOG
> > if (logger.debugIsActive()) logger.debug("this" + is + "a test");
> >// #endif
> >
> >which must be preprocessed before generating the code.
> >
> >Of course, the real solution would be to use AspectJ to code Cocoon, but
> >I'd rather wait until AspectJ stabilizes before moving to aspect
> >oriented programming. [for those of you who don't know what I'm talking
> >about, look at www.aspectj.org for more info on ASP for Java]
> >
> I would suggest we start converting/implementing the logging in the way Stefano suggested.
> Either by
> 1. if (logger.debugIsActive()) logger.debug(...)
> or
> 2. if (LOG && logger.debugIsActive()) logger.debug(...)
>
> Allthough I see the advantage in 2. I would vote for 1., because logging can be controlled simply by changing the configuration without recompilation. Number 2. would require changing many places for turning LOG on and off.
> Or has something like
> class Cocoon {
> public static final boolean LOG = true;
> }
>
> with if (Cocoon.LOG && logger.debugIsActive()) the same effective? Then I could imagine to use 2.
>
> What do you think? In which way should we start converting?
The final solution you proposed would be best, as we would not have
a Cocoon Logger class floating around. Don't be locked into
public static final and setting it there.
You have two choices with that approach:
Modify Ant to build a LOGGABLE version or LOG_DISABLED version of
Cocoon. This has the advantage of placing the boolean in the
Constants file:
public interface Constant {
String LOG = "{$DO.LOGGING}";
........
}
Modify an object to provide a static function that records whether
to log or not:
public class LogUtil {
public static Logger getLogger();
public static void setLogger();
public static boolean doLog();
....
}
AW: log performance penalties
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Stefano Mazzocchi [mailto:stefano@apache.org] wrote:
> Tagunov Anthony wrote:
>
>> Sure, this approach is not universal..
>>
>> 1)
>> As for number of parameters:
>> i personally see no trouble in
>> having 9 .log methods with number of parameters from 1 to 9 respecitvely, if
>> it saves performance! And I beleive there's a sane limit that a regular
>> log request does not come over..
>
>The solution is to remove the code completely.
>
>I'm not sure how many of you know this but this Java code
>
> final boolean LOG = false;
> if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
>test");
>
>is compiled into
>
> final boolean LOG = false;
>
>that's it! the code is gone! try it yourself with javap.
>
>This is the fastest solution available: no code executed no time lost.
>
>Of course, this requires a pretty good 'coding style' and coherence
>thruout the entire code and makes it more unreadable for those who are
>not aware of this java feature... but it's much better than having
>things like
>
>// #ifdef LOG
> if (logger.debugIsActive()) logger.debug("this" + is + "a test");
>// #endif
>
>which must be preprocessed before generating the code.
>
>Of course, the real solution would be to use AspectJ to code Cocoon, but
>I'd rather wait until AspectJ stabilizes before moving to aspect
>oriented programming. [for those of you who don't know what I'm talking
>about, look at www.aspectj.org for more info on ASP for Java]
>
I would suggest we start converting/implementing the logging in the way Stefano suggested.
Either by
1. if (logger.debugIsActive()) logger.debug(...)
or
2. if (LOG && logger.debugIsActive()) logger.debug(...)
Allthough I see the advantage in 2. I would vote for 1., because logging can be controlled simply by changing the configuration without recompilation. Number 2. would require changing many places for turning LOG on and off.
Or has something like
class Cocoon {
public static final boolean LOG = true;
}
with if (Cocoon.LOG && logger.debugIsActive()) the same effective? Then I could imagine to use 2.
What do you think? In which way should we start converting?
Carsten
Re: [C2] XSP and apects (was: log performance penalties)
Posted by Stefano Mazzocchi <st...@apache.org>.
----- Original Message -----
From: "Allan Erskine" <a....@cs.ucl.ac.uk>
To: <co...@xml.apache.org>
Sent: Friday, February 23, 2001 5:05 AM
Subject: [C2] XSP and apects (was: log performance penalties)
> ----- Original Message -----
> From: "Stefano Mazzocchi" <st...@apache.org>
>
> > Of course, the real solution would be to use AspectJ to code Cocoon, but
> > I'd rather wait until AspectJ stabilizes before moving to aspect
> > oriented programming. [for those of you who don't know what I'm talking
> > about, look at www.aspectj.org for more info on ASP for Java]
> >
>
> XSP seems nothing short of an aspect abstraction mechanism.
Well, thanks for saying this. Interesting enough, this is exactly what
Ricardo and I were discussing a months ago privately, the only problem is
the XML syntax which is very unfriendly with code.
So, while I agree with your vision, I'd suggest to be careful: XSP was
designed with SoC in mind as well as ASP. So it's very likely that you
percieve both as the same, but it's logically wrong since XSP (at least 1.0,
the current) is targetted to server page generation, not to code generation
in general.
> Aspects of
> server processing can be abstracted by tags, and modularised by namespace
> prefixing.
Yes, but I believe that it would be *much* better to avoid using the XML
syntax for that if all you want is code generation.
> Even language and platform choice are aspects unders XSP's remit
> (witness AxKit). Surely too useful for just pages (which are becoming an
> outmoded concept anyway). Besides, being eXtensible conflicts with being
> restricted to page serving...
Well, eXtensible doesn't mean "must do everything and brew coffee"
> IMHO, XSP's scope should be broadened to include server processes
(sitemaps,
> actions, ...), and XML fragment generation.
As for XML fragment generation, this will be already in place once 'content
aggregation' is implemented.
As for sitemaps and actions, I completely disagree: if you mean that java
falls short since it's not really aspect oriented, well, I totally agree
with you, but if you believe that using the XML syntax to add aspects to
java, well, I believe this is big time FS.
> I truly believe this would be
> powerful beyond belief (esp with recursive sitemap calling, and
sub-pipeline
> includes)
recursive sitemap calling? are you kidding? Please, this is *exactly* the
reasoning path that leads to flexibility syndrome: if 'a' and 'b' are great,
extending to 'z' will make it better. This is, generally, wrong since it
doesn't take into consideration the 'costs' of such an approach. Cost in
both learning, using and, even more important, maintaining.
And, last but not least, understanding the impact over SoC and the cost
metrics of a web publishing framework: making a sitemap programmable
directly is not only dangerous, is WRONG.
I repeat: WRONG!
because who administers the sitemap (the usability engineer, you might want
to call it) is almost never a programmer (programmers, by definition, have a
distorted view of usability anyway) and publishing systems have a very well
defined set of aspects, components and behaviors that must not be left to
everyone to rediscover or reinvent.
This is what a framework is: experience distilled into practices.
>, and it could be done without breaking the current XSP. In a
> stroke, XSP's profile would be boosted, and C2 would be less proprietary
> (becoming a framework for XSP publishing components). C2's codebase would
> also presumably shrink and be rationalised.
proprietary? rationalized? are we talking about the same Cocoon?
> (conclusion reached after following Uli's application rant on
cocoon-users,
> and developing my own C2 web-app, writing action after action to do the
same
> thing for different forms, longing for XSP actions, feeling locked in by
> proprietary sitemap. Just the usual $0.02 worth in other words).
I don't follow cocoon-users and I believe that placing a rant on
cocoon-users is totally meaningless.
Cocoon was not designed with webapps in mind, admittely, not even Cocoon2 so
far and the 'action proposal' is not enough thought out to represent a clear
design (even Giacomo agrees with me on this).
Admittedly, this is a problem, but moving XSP to cover everything results in
costs many will not be able to afford.
Do you want a design that brings Cocoon's publishing elegance to include the
functionality required by web applications? I do. I feel this is the only
thing that might impact the Cocoon API and thus, the only thing that stops
us for entering 'beta' state.
How do we do that? are actions and HTTP action handlers enough? how reusable
can be make actions? how granular the MVC patterns can be applied to the
generation stage? how much overlap there is between existing solutions like
Turbine or Struts, how much can we reuse of their models?
Making the sitemap directly programmable is nothing different from writing a
big servlet that uses Cocoon components as it wishes. Result: 'subversion of
control'. Another big anti-pattern.
> (and thanks to Paul Russel for the interesting reply to similar email on
> cocoon users...hope for the same, to shut me up once and for all about
> xsp sitemaps, or otherwise:)
Cocoon was designed with the idea that POST actions were handled by
something else. This has never been stated, but after careful thinking I
believe there is a specific asymmetry in how the system was designed.
Result: in Cocoon, GET is natural, POST is ackward.
This is what generates friction and ranting.
But I reanalized the architecture and found no evidence of this asymmetry in
the design, it's just a consequence of lack of focus on web applications.
Cocoon maps the IoC model of servlets and, just like servlets, it's totally
agnostic on how you build your web application, unlike frameworks like
Turbine or Struts that create patterns internally at the generation stage.
Cocoon personalization is based on generators: just like pure servlet
programming is hard and expensive, pure generator programming by code is
hard and expensive. So, what do we do?
Following the JSP patterns, we created the Cocoon equivalent of JSP model 1
with XSP, but we stopped there: XSP were not designed with model 2 in mind,
thus MVC is not implemented in its design, but it's left to the ability of
the XSP author.
There are a few questions that we need to answer:
1) how do we implement MVC in generators? (extend/modify XSP or use things
like Velocity/WebMacro)
2) are actions general enough to belong to the sitemap?
3) sitemaps are declarative pattern matching based on request and there is
no notion of flow, which is left implicit inside the web application. Is
there a way to identify a "flowmap"? Is this information useful? can this
enforce the use of top/down design on web applications, working along with
the usability engineer?
making the sitemap more programmable is not an advancement, it's a hack.
what we need is more thinking not rants.
Stefano.
[C2] XSP and apects (was: log performance penalties)
Posted by Allan Erskine <a....@cs.ucl.ac.uk>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
> Of course, the real solution would be to use AspectJ to code Cocoon, but
> I'd rather wait until AspectJ stabilizes before moving to aspect
> oriented programming. [for those of you who don't know what I'm talking
> about, look at www.aspectj.org for more info on ASP for Java]
>
XSP seems nothing short of an aspect abstraction mechanism. Aspects of
server processing can be abstracted by tags, and modularised by namespace
prefixing. Even language and platform choice are aspects unders XSP's remit
(witness AxKit). Surely too useful for just pages (which are becoming an
outmoded concept anyway). Besides, being eXtensible conflicts with being
restricted to page serving...
IMHO, XSP's scope should be broadened to include server processes (sitemaps,
actions, ...), and XML fragment generation. I truly believe this would be
powerful beyond belief (esp with recursive sitemap calling, and sub-pipeline
includes), and it could be done without breaking the current XSP. In a
stroke, XSP's profile would be boosted, and C2 would be less proprietary
(becoming a framework for XSP publishing components). C2's codebase would
also presumably shrink and be rationalised.
(conclusion reached after following Uli's application rant on cocoon-users,
and developing my own C2 web-app, writing action after action to do the same
thing for different forms, longing for XSP actions, feeling locked in by
proprietary sitemap. Just the usual $0.02 worth in other words).
(and thanks to Paul Russel for the interesting reply to similar email on
cocoon users...hope for the same, to shut me up once and for all about
xsp sitemaps, or otherwise:)
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Monday, February 19, 2001 12:29 AM
Subject: Re: log performance penalties
> Tagunov Anthony wrote:
>
> > Sure, this approach is not universal..
> >
> > 1)
> > As for number of parameters:
> > i personally see no trouble in
> > having 9 .log methods with number of parameters from 1 to 9
respecitvely, if
> > it saves performance! And I beleive there's a sane limit that a regular
> > log request does not come over..
>
> The solution is to remove the code completely.
>
> I'm not sure how many of you know this but this Java code
>
> final boolean LOG = false;
> if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
> test");
>
> is compiled into
>
> final boolean LOG = false;
>
> that's it! the code is gone! try it yourself with javap.
>
> This is the fastest solution available: no code executed no time lost.
>
> Of course, this requires a pretty good 'coding style' and coherence
> thruout the entire code and makes it more unreadable for those who are
> not aware of this java feature... but it's much better than having
> things like
>
> // #ifdef LOG
> if (logger.debugIsActive()) logger.debug("this" + is + "a test");
> // #endif
>
> which must be preprocessed before generating the code.
>
> Of course, the real solution would be to use AspectJ to code Cocoon, but
> I'd rather wait until AspectJ stabilizes before moving to aspect
> oriented programming. [for those of you who don't know what I'm talking
> about, look at www.aspectj.org for more info on ASP for Java]
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
Re: log performance penalties
Posted by Stefano Mazzocchi <st...@apache.org>.
Tagunov Anthony wrote:
> Sure, this approach is not universal..
>
> 1)
> As for number of parameters:
> i personally see no trouble in
> having 9 .log methods with number of parameters from 1 to 9 respecitvely, if
> it saves performance! And I beleive there's a sane limit that a regular
> log request does not come over..
The solution is to remove the code completely.
I'm not sure how many of you know this but this Java code
final boolean LOG = false;
if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
test");
is compiled into
final boolean LOG = false;
that's it! the code is gone! try it yourself with javap.
This is the fastest solution available: no code executed no time lost.
Of course, this requires a pretty good 'coding style' and coherence
thruout the entire code and makes it more unreadable for those who are
not aware of this java feature... but it's much better than having
things like
// #ifdef LOG
if (logger.debugIsActive()) logger.debug("this" + is + "a test");
// #endif
which must be preprocessed before generating the code.
Of course, the real solution would be to use AspectJ to code Cocoon, but
I'd rather wait until AspectJ stabilizes before moving to aspect
oriented programming. [for those of you who don't know what I'm talking
about, look at www.aspectj.org for more info on ASP for Java]
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: log performance penalties
Posted by Tagunov Anthony <at...@nnt.ru>.
Hello, Cocooners!
On Sun, 18 Feb 2001 16:33:31 +0100, Stefano Mazzocchi wrote:
>Tagunov Anthony wrote:
>>
>> Hello, evrybody!
>>
>> On Thu, 15 Feb 2001 15:49:24 +0100, Stefano Mazzocchi wrote:
>>
>> >I'm looking at the changes made to Cocoon while I was away:
>> >
>> >are you guys aware of the fact that something like
>> >
>> > getLogger().debug("Making URL from " + location);
>>
>> Maybe doing something like getLogger().debug("Making URL from",location)
>> would make things easier?
>
>Hmmm, what if you want to log something like
>
> "this " + code + " has been " + action + " at time " + time
>
>???
Sure, this approach is not universal..
1)
As for number of parameters:
i personally see no trouble in
having 9 .log methods with number of parameters from 1 to 9 respecitvely, if
it saves performance! And I beleive there's a sane limit that a regular
log request does not come over..
2)
parameter types, yes, this is the real trouble
there's one more trick from my practice that i can propose:
to log "this " + code + " has been " + action + " at time " + time one
could
getLogger().debug("this"); getLogger().debug(code); getLogger().debug("has been")... getLogger().debugNewLine();
and the logger would have
debug(int), debug(String), debug(Time) methods and would sum up them in it's internal
(kept per-thread) StringBuffer (so there's either a logger instance per thread, or
each logger keeps per-thread information). The call degubNewLine() would actuall
take the whole accumulated buffer and put it to the log.
I used this approach in .cpp programs to avoid hussle with putting
"this"+code+"has been" before doing a log() call. In C this resulted in even
shorter and more understandable code. In Java it won't, but if it save
performance..
>> I'm speaking about implementing things like debub(String), debug(String,String), debug(String,String,String)?
>> That's what i do for my applications (non-cocoon)
>
>It's in these situations I wished java was aspect oriented :(
>
>--
>Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
><st...@apache.org> Friedrich Nietzsche
>--------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
Re: log performance penalties
Posted by Stefano Mazzocchi <st...@apache.org>.
Tagunov Anthony wrote:
>
> Hello, evrybody!
>
> On Thu, 15 Feb 2001 15:49:24 +0100, Stefano Mazzocchi wrote:
>
> >I'm looking at the changes made to Cocoon while I was away:
> >
> >are you guys aware of the fact that something like
> >
> > getLogger().debug("Making URL from " + location);
>
> Maybe doing something like getLogger().debug("Making URL from",location)
> would make things easier?
Hmmm, what if you want to log something like
"this " + code + " has been " + action + " at time " + time
???
> I'm speaking about implementing things like debub(String), debug(String,String), debug(String,String,String)?
> That's what i do for my applications (non-cocoon)
It's in these situations I wished java was aspect oriented :(
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: log performance penalties
Posted by Tagunov Anthony <at...@nnt.ru>.
Hello, evrybody!
On Thu, 15 Feb 2001 15:49:24 +0100, Stefano Mazzocchi wrote:
>I'm looking at the changes made to Cocoon while I was away:
>
>are you guys aware of the fact that something like
>
> getLogger().debug("Making URL from " + location);
Maybe doing something like getLogger().debug("Making URL from",location)
would make things easier?
I'm speaking about implementing things like debub(String), debug(String,String), debug(String,String,String)?
That's what i do for my applications (non-cocoon)
>is translated by java compilers into
>
> StringBuffer sb = new StringBuffer("Making URL from ");
> sb.append(location);
> getLogger().debug(sb.toString());
>
>which generates
>
> 1) a new stringbuffer object
> 2) a new String
>
>even if debug log channel is disabled?
Best regards, Tagunov Anthony