Re: [RT] Simplifying component handling
> On 30.12.2005 19:09, Carsten Ziegeler wrote:
> > Way too much code me thinks. So what about:
> >
> > class MyComponent implements SOMETHING, ThreadSafe {
> > protected final ClassA compA;
> > protected final ClassB compB;
> >
> > public MyComponent(ClassA a, ClassB b) {
> > compA = a;
> > compB = b;
> > }
> > }
I've tried this (with Jakarta Commons Attributes) and the end result
can be summarized as "it is barely worth it" in terms of added
complexity and behind-the-scenes magic. Technically it is a huge
success. But the price you pay is that it makes the code that much
more non-standard.
This is also for a closed code base that has a fixed team of a few
developers. For open source, having additional magic would probably be
even more expensive in terms of complexity, initial threshold for
developers, and embeddability.
(Regarding the lower embeddability: This is my main problem with
Commons Logging. It has magic all right - just not the right magic!)
For Cocoon, I'd recommend against it. So what if the code is a little
bit bigger, if it means that it can actually be understood without
knowing a hundred additional, Cocoon-specific contracts up front.
/LS
Re: [FFT] Kitchen Sink
On 12/15/05, Mats Norén <[EMAIL PROTECTED]> wrote: > Leo Sutic wrote: > > Took a look at it. > > > > It still requires a lot of knowledge of the underlying EJB platform. > > It does? > I looked at the samples in CVS and in > jboss-seam-1.0beta1/examples/noejb there is an example with POJO:s and > Hibernate. Ok, I missed that. > I for one would love to see something similar to the idea you outlined > within Cocoon NG or whatever it will be called in the end. :) > Do you have any thoughts on how such a language could be developed? Blood, sweat and tears. Throw in a multitude of false starts, dead ends and frustration. :) I think I'd start by trying to define what a webapp is. The problem is that this is a moving target. Any language you come up with is probably obsolete in a week or so. /LS
Re: [FFT] Kitchen Sink
Took a look at it. It still requires a lot of knowledge of the underlying EJB platform. And it has xml config files. Not quite what I had in mind. /LS On 12/14/05, Mats Norén <[EMAIL PROTECTED]> wrote: > Hmmm...have you looked at JBoss SEAM? ;)
[FFT] Kitchen Sink
I pretty much agrees with what Berin has been saying - and I also
agree with Stefano.
Berin is right in that we must strive for simplicity.
Stefano is right in that a (somewhat) complex system is required to
solve even more complex problems.
The problem with Cocoon as I see it is this:
Think about Java. It is a fairly simple language, right? You can do a
"Hello World" pretty easily. But you can also do some fairly complex
things with it.
The thing is this: You don't need to know the internal workings of the
JRE or compiler in order to do this. You are abstracted away from it.
Sometimes you have to look a thing or two up, but then you're doing
some pretty advanced stuff.
Cocoon lacks this abstraction. You need to know about its internals to
do even basic stuff.
If I can write both a blog and Cocoon in Java, why can't I use Cocoon
for writing a blog? Why this "that problem is too simple for Cocoon."
Maybe it is, but is that the problem's fault?
So what's my recipe for success? Get that abstraction in place. Cocoon
should be *a language for writing web apps*. Now we have XML, XSL,
Javaflow, JSFlow, and a host of other languages. What if Java wasn't
one language, but you had to write a JCL file to go with you java
Hello World, a bunch of headers, and so on.
That language can then be modularized so that it can be extended, or
so that parts of it can be reused - but I think the facade that has to
be presented to the user has to be focused on one thing, and the user
shouldn't have to look behind it (in 99.9% of the cases).
package sample;
@website
class MyHomepage {
// Set by runtime execution environment.
@dependency
protected Translator translator;
@uri ({"/", "/index.html"})
public Response mainPage () {
return new StreamResponse (new File ("index.html"));
}
@uri ({"/hello"})
@pipeline (MyLookAndFeel)
public Response helloWorld (String who, String language) {
// Must be called /hello?who=...&language=...
return new StringResponse (
translator.translate ("Hello " + who + "!", language));
}
}
@pipeline
class MyLookAndFeel {
...
}
I skip things like "how do you use XSL" and so on - I'm making this up
as I type, and it will take months to architect a proper language.
I see the system as having two parts:
1. A language for writing webapps. It can (should perhaps) be java
with annotations or other facility for extending it.
2. An *embeddable* execution environment that will run webapps written
in (1). This ***must*** be decoupled from any specific servlet
container, and should not try to be an app server in itself. For
example - class loading should not go here.
By having this one language, writing tools for it is simpler. If an
AST parser is provided for tool writers, it is even easier, and
anything you can do in XSL with the current XML sitemap or xsp or ...
can be done. You can also have code generators for websites.
I think this is what Cocoon has been evolving toward, and a lot of the
pain is that the problem ("make up a language for webapps") is just so
*hard*. Cocoon has gone from XSP to Logic Sheets (which I never
understood) to XSL to JavaFlow to... We have tried to create the one
language for the web, but done so incrementally and under pressure to
deploy. "Let's take C. Let's add some macros... let's add some more
macros..."
Stefano also noted that there is a whole lot of talk and not much code
being hammered out. True. In no way am I demanding that you develop
the above. I might write it myself, given time. See this as just food
for thought.
Anyway, my two cents.
/LS
Re: [RT] Is Cocoon Obsolete?
On 9/30/05, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > How do you feel about this? Stefano, you always have very interesting RTs. (They're pretty structured, too, so I wonder if you shouldn't tag them [PT] for Philosophical Thought or [HT] for Hard Thought.) I think you're right on your observations, and wrong on your conclusion. It is true that the web browser client is getting more and more sophisticated. Right now FireFox is a step ahead, but IE will catch up. They're not likely to regress anyway. But consider this: 1. Even with AJAX etc. *something* has to produce all that XML that is to go out to the client. So just because we're seeing less and less need to use spiffy stylesheets to get the *visual* effects we want, having an XML processing engine is definitely something that's needed. 2. Given that: + Processing power is cheap. + Data transfer is expensive. We have oodles of processing power and comparatively limited bandwidth (whether it be between CPU and RAM, or CPU and CPU over network). So there will always be a need to server up things pre-digested for the client. Especially if the processing involves discarding lots of data. So research-wise you may be right in the sense that the revolution has happened, and it is behind us. But we're still coming up with new ways to improve the post-revolution world. That may not be as sexy, but it is part of a technology maturing. Actually, I'd say that of the things Cocoon brought the servlet world, the architecture and framework are the two most valuable parts. The fact that you can make this framework transform XML into neat HTML is neat and all, but it pales in comparison. And those two parts will not be obsolete for a long, long time. /LS
Re: ThreadSafe Transformers
On Wed, 22 Sep 2004 11:26:22 -0400, Vadim Gritsenko <[EMAIL PROTECTED]> wrote: > And keep in mind that ComponentSelector from o.a.c.c.t.sitemap is > selector specifically for sitemap components... Makes sense. If it's a different contract, then we can extend it as needed. /LS
Re: ThreadSafe Transformers
Like the idea (and we can extend it to Generators, Serializers, etc.), but:
Instinctively dislike the hack in the component selector.
/LS
On Wed, 22 Sep 2004 10:31:01 -0400, Vadim Gritsenko
<[EMAIL PROTECTED]> wrote:
> Y'all,
>
> Some time ago I remember discussions about making transformers
> threadsafe, major changes, about Cocoon 3, etc. Yesterday it occured to
> me that Transformers can easily be made ThreadSafe with only additions
> to current Cocoon architecture without any major rewrites. It can be
> done in this way:
>
> Add new interface marking threadsafe transformer:
> public interface TransformerFactory {
> Transformer getTransformer();
> }
>
> Override select method in ComponentSelector:
> public Component select(Object hint) throws ComponentException {
> Component component = super.select(hint);
> if (this.roleId == TRANSFORMER) {
> if (component instanceof TransformerFactory) {
> return ((TransformerFactory)component).getTransformer();
> }
> }
>
> return component;
> }
> (it is in org.apache.cocoon.components.treeprocessor.sitemap package)
>
> Modify existing transformer so that transformer class implements
> TransformerFactory, ThreadSafe, and nested class TransformerImpl
> implements Transformer, CacheableProcessingComponent (and it can extend
> AbstractXMLPipe). On the example of EncodeURLTransformer:
> public class EncodeURLTransformer
> implements TransformerFactory, Configurable, ThreadSafe {
>
> public void configure(Configuration config) {...}
>
> public Transformer getTransformer() {
> return new TransformerImpl();
> }
>
> private class TransformerImpl
> extends AbstractTransformer
> implements CacheableProcessingComponent {
>
> public void setup(SourceResolver resolver,
> Map objectModel,
> String source,
> Parameters parameters) {...}
>
> public Serializable getKey() {...}
>
> public SourceValidity getValidity() {...}
>
> public void startElement(String uri,
> String name,
> String raw,
> Attributes attributes) {...}
> ...
> }
> }
>
> Thus ThreadSafe transformer is a factory creating instances of SAX pipes
> performing actual transformation. Pluses of this approach, as I see it, are:
> * Transformer is ed / contextualize()d / service()ed /
>configure()d / etc just once. Saves CPU cycles.
> * Transformer global configuration / context / components
>stored in single instance of ThreadSafe transformer instead
>of beeing copied in each instance of usual pooled
>transformer. Saves memory.
> * Users of ComponentSelector still receive instance of
>Transformer as they used to expect. Backward compatibility.
>
> Now question; is it a good idea to check in this code into 2.2? Any
> drawbacks of this approach?
>
> Thanks,
> Vadim
>
>
Re: Sharing cocoon.jar between multiple web aplications
On Wed, 8 Sep 2004 14:32:01 -0400, peter royal <[EMAIL PROTECTED]> wrote: > On Sep 8, 2004, at 11:17 AM, ÄURDINA Michal wrote: > > The problem arise only when one web application calls other web > > application to generate its output (via getRequestDispatcher.include() > > - crosscontext must be enabled). Then both webapps use the same static > > field instance in the same thread. And if both are calling method on > > the same class i.e. Cocoon.process(), then called web application can > > rewrite the value saved by calling web application. > > ah, gotcha. > > why not just put cocoon.jar per-webapp then, and put the rest of the > deps at the ear level? :) Because the other deps may include cocoon components (generators etc). The cocoon jar will suck all the other libs with it. The problem seems to be that the stack is assumed to be empty at start of processing, otherwise it doesn't matter. Would it be possible to instead put some kind of "barrier" on the stack at startProcessing, and remove it at endProcessing? It would be empty to the thread handling the request, because it can't see beyond the barrier. /LS
Re: [RT] Concerns surrounding CocoonNG
Niclas, the problem I have with Merlin/Metro is this: http://marc.theaimsgroup.com/?l=avalon-dev&m=108965397729686&w=2 Do you have ANY idea just how incredibly hard it has been to develop for Merlin? I've been trying to get a whole platform out the door here at Sony and was held up for MONTHS because of the huge changes between Merlin 3.0 and Merlin 3.3. Perhaps this was just a freak accident, where slight changes turned out to have large and unanticipated effects. Nevertheless, it is *precisely* the reason why Cocoon is migrating away from Avalon and is looking into Pier's kernel. The reason we're interested in it has not so much to do with classloading, strong contracts etc., which can be implemented if anyone cares enough for them. It's the fact that the Kernel is *completely under our control*, so we'll never have the system break because of changes to the kernel. Therefore I'm +1 on Pier's kernel. I'm sure Merlin/Metro has a place somewhere, maybe inside the "blocks", maybe somewhere else, but considering switching to it at this point in time is simply reckless. /LS
Re: [fyi] one liners from me
On Thu, 22 Jul 2004 06:30:48 -0400, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > my wrists hurt *very* bad from too much f*g typing about f***ing > fixing f***ing communities that don't have a grip on reality and that > are hurting us. On Wed, 21 Jul 2004 19:28:57 -0400, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > Avalon is dying (and I'm personally trying to killing it faster) Add up those two quotes and I think anyone here can figure out where Stefano is right now. It's a nasty place, trust me, that's why I (and many with me) left it. I'm +1 for cutting Stefano some slack here and just postpoining any discussion for a couple of days. I never got to the point of my wrists aching, but the *exhaustion* and *frustration* gets to you after a while, too. > Stefano, who has much better things to do to damage his physical and > mental health. You forgot the "than" between the "do" and "to", but I guess that just made the quote somewhat more profound. /LS
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Ugo Cei wrote:
> Since I'm getting more and more bored with my daytime job, I ended up
> doing something:
>
> http://wiki.apache.org/cocoon/ButterflyManifesto
>
> Comments are welcome, flames > /dev/null.
Comments:
1. "Butterfly is an experiment aiming to implement a (simplified)
Cocoon clone but based on Spring instead of Hibernate" Don't you mean:
"based on Spring instead of Avalon"
2. "Strive for 100% unit test coverage" A bit of a red herring. You
don't want code coverage as much as state coverage. For example:
/** Divides two numbers. If b == 0, returns 0. */
public static void divide (int a, int b) { return a/b; }
Test:
public void testDivide () { assert divide (4, 2) == 2 };
Which doesn't test the case where b == 0.
/LS
Cost of Synchronization
Every now and then the subject comes up: Are we losing performance due to methods being synchronized? Some figures (for Java1.3.1, but anyway): http://www.cs.umd.edu/~pugh/IsCodeOptimizationRelevant.pdf Performance (2 processor Ultra 60) - HotSpot (1.3 beta) - Original: 4788 - Altered: 4923 (+3%) [This is the un-synchronized version] - Exact VM (1.2.2) - Original: 6649 - Altered: 6874 (+3%) [This is the un-synchronized version] - Not a big win (3%) - Which JVM used more of an issue - Exact JVM does a better job of interfacing with Solaris networking libraries? Some quotes: Lessons: ... But the real problem was the algorithm Cost of stupidity higher than cost of synchronization I found this via Ted Leung - http://www.sauria.com/blog Quite a cool blog, BTW. He comes up with gems fairly regularly. /LS
Re: VERY odd exceptions...
On Wed, 26 May 2004 09:24:50 -0400, Berin Loritsch
<[EMAIL PROTECTED]> wrote:
> The more correct version would be:
>
> public class MyClass {
> private volatile int counter; //atomic
>
> public someMethod() {
> ++counter;
> }
> }
>
> Only longs on up should be actually synchronized.
No, because a ++ is still a load-add-store, volatile only makes this
equivalent to:
int temp = 0;
synchronized (lock) {
temp = counter;
}
temp = temp + 1;
synchronized (lock) {
counter = temp;
}
Of course some other thread can jump in between the synchronized
blocks and modify the counter variable.
longs should be synchronized because they are written in two
instructions, meaning that while you may get a stale value when
accessing an unsynchronized int, you might just get a jumble of bits
when reading an unsync long (you may read id *while the write is in
progress*).
> I agree that either approach *will* without a doubt cause a bottleneck
> and hurt the scalability of Cocoon.
I disagree. I'm sure the time spent synchronizing on two blocks as
small as that will not have any impact that can be measured.
Of course, when the sitemap is up for reloading, we can't accept any
new requests (otherwise you get starvation). Perhaps putting a
read-write lock around the treeprocessor would be better and easier?
/LS
RE: [VOTE RESULTS] Make ProcessingException extend CascadingRuntimeException
These things were discussed to death at Avalon. My personal guideline is this: If you have -1's you don't have consensus. Unless you have consensus, you shouldn't implement whatever it is you propose. As for the problem with someone being completely uncooperative, well... /LS > From: Ugo Cei [mailto:[EMAIL PROTECTED]
RE: [VOTE RESULTS] Make ProcessingException extend CascadingRuntimeException
> From: Ugo Cei [mailto:[EMAIL PROTECTED] > > Therefore, ProcessingException should really be ProcessingError - > > since you're not expected to recover from it. Or extend Throwable > > directly. > > Well that's more radical than my proposal! You won't catch it even if > you do "catch(Exception e)". That's the point. A ProcessingException means that all elements of the pipeline should just *stop*. They shouldn't try to recover (IoC), proceed (IoC) or try some backup solution (IoC again). Just stop, exit, and let the Processor/sitemap logic handle it. > I warn you that even Sun is not sure about what constitutes > an Error, as in the Javadoc it says: > > "An Error is a subclass of Throwable that indicates serious problems > that a reasonable application should not try to catch. I think that fits ProcessingException just fine. The JavaDoc talks about "application", but you should understand this in the proper context. If your code is a Cocoon component, then you should read this as: "An Error is a subclass of Throwable that indicates serious problems that a reasonable Cocoon component should not try to catch." I.e. the meaning of "application" is highly context-dependent. What we have done is to create an application environment - call it Cocoon OS if you want - where you run web applications consisting of components. Just because you don't launch something from the command line doesn't mean that it isn't an application. /LS
RE: [VOTE RESULTS] Make ProcessingException extend CascadingRuntimeException
I change my non-binding vote to -1.
Motivation:
When you have a block of code that uses other modules, you often end up
doing:
try {
...
} catch (Exception e) {
// Whatever the cause, it didn't work.
throw new MyException (e);
}
Since RuntimeException isa Exception, this will catch and wrap
RuntimeExceptions as well.
This sort-of defeats what we're trying to achieve with
ProcessingException,
which is to make it bypass all wrapping and so on and go directly to the
bottom of the stack.
Therefore, ProcessingException should really be ProcessingError - since
you're not expected to recover from it. Or extend Throwable directly.
/LS
> From: Ugo Cei [mailto:[EMAIL PROTECTED]
RE: [VOTE] Make ProcessingException extend CascadingRuntimeException
I'm not a committer, but +1 from me. The ProcessingException isn't supposed to be caught by the immediate client, but propagated all the way up the stack. It therefore seems unneccessary to burden the intermediate layers with having to declare "throws ProcessingException". /LS > From: Unico Hommes [mailto:[EMAIL PROTECTED]
RE: CocoonComponentManager
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > Now, I personally think, if we change this, we should first > use the improved code from the 2.2 base as it has less static > methods and is in some respects cleaner and then see what we > can do with the remaining stuff. But that's just my opinion. The 2.2 branch will probably be very different from the existing code, with blocks etc., so perhaps this will be a non-issue by then. /LS
RE: CocoonComponentManager
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > This would give everyone access to the info (ok, the current > static methods are accessible as well) and imho makes it more > visible. I think it'd make it less visible. For example, you can pass the CocoonContext only to specific components, while the statics are available everywhere. > Just curious, why do want to do this? Do you just want to use > the TreeProcessor as a processor for a custom XML? Or are you > using the TreeProcessor to process a sitemap in a different > environment? Now, I think, if the TreeProcessor is used for > custom XML, then you could use the TreeBuilder I think (I'm > not that sure). If you want to process a sitemap, you need > the dependency to the cocoon stuff anyway. I will process a reduced sitemap. Just generators, actions, transformers and serializers. Nothing more. In theory I could define my own pipeline language, write my own components, and so on, but I figured I'd try to re-use as much of Cocoon as possible. Specifically, I will not be using flow, continuations or subsitemaps. /LS
CocoonComponentManager
I've recently started thinking about embedding Cocoon in another application. One of the issues that I have is the CocoonComponentManager - since I use another component manager in the application, I'd like to just host the TreeProcessor in that manager. The issue I have is that CocoonComponentManager exposes a number of static methods that makes it imposible to replace. I.e. you have components (TreeProcessor) that really do care about what container they are in. I can't subclass the CocoonComponentManager, since TreeProcessor refers to the class by name. But what I could do is this (and this is what I propose to do): Move the static methods out from CocoonComponentManager and put them in the Context. The CocoonComponentManager could then expose those methods via a custom InternalCocoonContext interface that extends the Context interface. This would remove all static methods, and I'd be able to host a TreeProcessor in many other containers. /LS
RE: [forms] recursive event loops
UnrealScript solves this another way: http://unreal.epicgames.com/UnrealScript.htm: Singular: The "singular" keyword, which appears immediately before a function declaration, prevents a function from calling itself recursively. The rule is this: If a certain actor is already in the middle of a singular function, any subsequent calls to singular functions will be skipped over. This is useful in avoiding infinite-recursive bugs in some cases. For example, if you try to move an actor inside of your "Bump" function, there is a good chance that the actor will bump into another actor during its move, resulting in another call to the "Bump" function, and so on. You should be very careful in avoiding such behaviour, but if you can't write code with complete confidence that you're avoiding such potential recursive situations, use the "singular" keyword. Disclaimer: I can't write UnrealScript to save my life, so I don't know how useful this is in reality. /LS > From: Bruno Dumon [mailto:[EMAIL PROTECTED]
RE: [RT] Checked exceptions considered harmful
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch
>
> Leo Sutic wrote:
>
> >>As soon as you declare it, the compiler will require a
> >>try/catch or throws clause--even if it is a RuntimeException.
> >
> >
> > No.
> >
> > public class Hack {
> >
> > public void method () {
> > method2 ();
> > }
> >
> > public void method2 () throws IllegalArgumentException {
> > throw new IllegalArgumentException ("Yadda");
> > }
> >
> > public static void main (String[] args) {
> > Hack h = new Hack ();
> > h.method();
> > }
> > }
>
> Really? I did the exact same thing and got an error during
> compilation. It must be a stricter IDE specific compiler.
> I'm not sure that we can count on that continuing to be the
> case forever though.
No, but they have to change the Java language spec for it to
happen:
http://java.sun.com/docs/books/jls/second_edition/html/exceptions.doc.ht
ml
"The runtime exception classes (RuntimeException and its
subclasses) are exempted from compile-time checking"
/LS
RE: [RT] Checked exceptions considered harmful
> From: Leo Sutic [mailto:[EMAIL PROTECTED]
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch
> >
> > > For example, Hejlsberg lists as one bad thing about rethrowing
> > > exceptions that you loose the stack trace. But if the
> Exception is
> > > supposed to be handled, then who cares about the stack trace?
> >
> > If you rethrow the exact same exception, shouldn't the stack
> > trace remain in tact? If you throw a wrapped exception, then
> > you can still get to the original stack trace. The stack
> > trace is important to developers because it helps pinpoint
> > the exact place where the problem occurred.
>
> Hejlsberg meant the case where an Exception is re-thrown and
> not wrapped.
And by that I mean re-thrown-as-another-Exception:
try {
} catch (SomeException se) {
throw new SomeOtherException ();
}
/LS
RE: [RT] Checked exceptions considered harmful
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch
>
> > For example, Hejlsberg lists as one bad thing about rethrowing
> > exceptions that you loose the stack trace. But if the Exception is
> > supposed to be handled, then who cares about the stack trace?
>
> If you rethrow the exact same exception, shouldn't the stack
> trace remain in tact? If you throw a wrapped exception, then
> you can still get to the original stack trace. The stack
> trace is important to developers because it helps pinpoint
> the exact place where the problem occurred.
Hejlsberg meant the case where an Exception is re-thrown and
not wrapped.
> As soon as you declare it, the compiler will require a
> try/catch or throws clause--even if it is a RuntimeException.
No.
public class Hack {
public void method () {
method2 ();
}
public void method2 () throws IllegalArgumentException {
throw new IllegalArgumentException ("Yadda");
}
public static void main (String[] args) {
Hack h = new Hack ();
h.method();
}
}
/LS
RE: [RT] Checked exceptions considered harmful
> meaning: when cleaning out stuff, you shouldn't throw out the real > valuable parts (even if those were the cause that got you in the mess) I think you end up with something like: + If the thing you are signalling via an Exception could be made into a error return value that the client code *really should check for* as opposed to *can check for*, then make it a checked Exception. This ensures that the client code will check for it. + If what you are returning is guaranteed to be unrecoverable and stop any processing, throw an Error. + Else make it a RuntimeException. The whole point with checked Exceptions was to avoid the case when lazy programmers didn't properly check for ok return codes. /LS
RE: [RT] polymorphism and hotswapping
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > > Deferring, does that mean keeping the "old" block around as long as > > it's in use, while the "new" block is used by clients that have > > recently started using it? > > Exactly! This solves most (if not all) problems related to statefull > components, since the user would be guaranteed to use the > same component between lookup and release [1]. It also results in problems when the new and old block end up competing for a common resource. For example, if you have a HypersonicSQL block working with a bunch of files that make up the tables in the database, having a newer version of HSQL access those same files, even for a short moment, will result in corruption. In some cases, you can't have two blocks in parallell. /LS
RE: [RT] Checked exceptions considered harmful
> From: Ugo Cei [mailto:[EMAIL PROTECTED] > > [1] http://www.mindview.net/Etc/Discussions/CheckedExceptions > [2] http://www.artima.com/intv/jdom3.html > [3] http://www.artima.com/intv/handcuffs.html > [4] http://www.theserverside.com/articles/article.tss?l=RodJohnson > Interview (read inside the PDF of the sample chapter) > [5] http://www.artima.com/intv/solid.html Summary of these appear to be that the difference is if your code must handle exceptions gracefully (for example, as Gosling says, avionics), or if it is OK to just drop that web server request. What this further boils down to is the use of Exceptions for exceptional circumstances, or as a standard signalling mechanism. For example, in C# the idea is that a program should never throw any exceptions. If one is thrown, something has gone very very bad. You could say that Exceptions in C# are like Errors in Java. In Java, Exceptions are a signalling mechanism that is expected to be used during normal execution. For example, Hejlsberg lists as one bad thing about rethrowing exceptions that you loose the stack trace. But if the Exception is supposed to be handled, then who cares about the stack trace? So - checked exceptions work fine when you can and must handle the circumstances giving rise to them, while unchecked work fine if you're just expected to let them propagate and have them written to a log file at the bottom of the stack. (I still think one should declare known RuntimeExceptions in the throws clause. For example, if I know that the code will throw an IllegalArgumentException if the first argumetn is less than zero, I should declare the IllegalArgumentException.) /LS
RE: [RT] polymorphism and hotswapping
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > People, > > first of all, I apologize if I sounded somewhat harsh at time in the > past two weeks. It's been a hell of a time, 8 hour-long meeting in > highly political places (semantic web + jcp) and, boy, I didn't have > enough time between things to realize that here I was *not* > constantly under attack. Mate, I'm from Avalon. I have scar tissue ten meters deep, so I don't feel that much. > Do we really need hotswappability? Personally I have no need for it. The code is complex, and I am always a bit suspicious of relying on complex code. I also don't need to keep each individual server running all the time (can take them out of line one by one). However, would hotswap be useful during development of blocks? I know that many Cocoon developers (and webapp developers) like the ability to just hit "reload my app" when the make modifications. I also like the fact that stylesheets are reloaded when they change on disk, so I can make a stylesheet change, hit F5 to reload the page, and see my change. If I am going to store skins and resources inside blocks, I would like to be able to change them without restarting Cocoon. > Is it worth the price to pay for the complexity? The question is if we need to design for hotswap and/or implement it. I would like us to use the design work Pier has put into the new kernel, and make sure that the Cocoon core interfaces *support* hotswap. That is, if we later on wanted to add hotswap, we should be able to do so without changing the Cocoon core interfaces. I think we can come up with a client interface that's very easy to use and addresses the objections to the current interface (i.e. too ugly client code, too much responsibility on the client, etc.) But I don't think we have to *implement* hotswap at this moment. At least not all of it. The important part is to get blocks running. Hotswap of blocks is of lower priority, and I don't want the 2.2 to be stuck in development because hotswap is so hard to implement correctly. Get the blocks running, and then we can start thinking about how to get hotswap running. Finally, when we decide to allow hotswap, I want us to start off by realizing that we will only cover some cases when hotswap is possible. There will always be the pathological case where hotswapping simply isn't posible. But if we can say: "Hotswapping is possible under the following three conditions: (1) ... (2) ... (3) ...", then at least we will have hotswap - probably for 90% of the cases - and I think the complexity will be manageable. /LS
RE: [Kernel22] How to develop a component?
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > Leo Sutic wrote: > >>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > >> > >>again, from memory, the real tough part is the barrier that's > >>in place around the reference. > > > > I'd say the hard part is when A has significant state that isn't > > preserved when it dies. > > right! Any reason it can't be preserved? In theory no, in practice it isn't cost-effective to implement all that code. Therefore it won't be done. > reminds me of Persistable... > > > 1) A active > > 2) schedule swap of A with B > > 3) prepare swap to max extend (ie create and initialize B) > > 4) suspend A and all processes referencing A > > 5) swap > >1) stop A > 1.5) save A state > >2) kill A (if it doesn't respond) > 2.5) load A state into B > >3) start B > >4) update reference > > 6) resume A and all processes referencing A > > the problem is that step 5 just keeps getting more and more > expensive...and for all intents and purposes, needs to be atomic. The idea I'm looking at is when A and B interact via short sessions - for example, the time between a lookup and a release. As long as B is released by A when you swap, you can just kill it. Avalon semantics do not require B to maintain state across lookups. So you do the barrier thing: block or fail lookups until all B's have been released, the swap. /LS
RE: [Kernel22] How to develop a component?
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > again, from memory, the real tough part is the barrier that's > in place around the reference. I'd say the hard part is when A has significant state that isn't preserved when it dies. This makes it seem from client's perspective as if the process at the other end has simply forgotten about the commands it has been given previously. Hotswapping stateless stuff is easy. Stateful stuff - that's the hard part. /LS
RE: [Kernel22] How to develop a component?
> -Original Message- > From: Ralph Goers [mailto:[EMAIL PROTECTED] > Sent: den 8 april 2004 19:52 > To: '[EMAIL PROTECTED]' > Subject: RE: [Kernel22] How to develop a component? > > > I think you have captured this pretty well. Some thoughts: > > ALT1 - IMO the disadvantages are worse than they appear. > Yes, distributed apps and DB connections exhibit this > behavior, but when you are talking about ALL the cocoon > components having this behavior the code will turn into > nothing but error handling logic. This is just plain > non-workable in my view. > > ALT2 - Hmmm. You want to hot swap a singleton? Can you EVER > really do that? I have situations where you can have zero or one instance, but not two or more. For example, a DB has an upper limit to the number of connections it can handle. If a component is a client of the DB (it is a connection pool), I want to know that I either have no connection pool, or exactly one connection pool. If you suddenly run two side-by-side, then the new pool will never acquire a connection, while the old one will hold on to the ones it has acquired until it is released (and who knows when that may be). /LS
RE: [Kernel22] How to develop a component?
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > Leo Sutic wrote: > > This is contrary to Avalon semantics, where a component reference, > > once obtained, remains valid until it is released. > > right. It's contrary to java semantics, even. Not really. It is more like the semantics you have for remote objects. Except we don't throw RemoteException all the time. (But neither does AltRMI, if I remember correctly.) > Yep. Nothing to do with avalon-framework, though. I would say > you'd have to [...] > Agreed, its not very clean. I have listed some other thoughts that I and Pier have thrown back and forth below. > All this, however, does not mean: > > "If you have two blocks in the avalon sandbox, you could share them > between them, but there is no (easy? elegant?) way you can pass them > arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable > and runtime polymorphic." No, it doesn't. (Tell it to the person you quoted, though.) > IOW, What you have shown here is that new-style cocoon blocks are > incompatible with a standard assumption in most java code, namely, > that references will remain references. You have not shown that > these kinds of components cannot be used in an application where > you violate that assumption, only that it will result in headache. Yep. > I can't see how it is relevant whether a reference is obtained > through the avalon ServiceManager or through any other means. Yep. PROBLEM: We have a set of components communicating across defined interfaces. We want to be able to hot-swap the components. The interfaces are considered permanent and need not be how-swapped. DEFINITIONS: We'll consider the simplest case. Component: The component being swapped in this scenario. It consists of implementation code, no interfaces. We make no assumptions regarding the statefulness or statelessness of the component. Client: The code using the component. The client is probably another component, but we'll call it "client". Container: The container in which we find the client and the component. Wire: The connection between component and client. The important thing with this wire is that it can be severed by the container. A component (such as the client) obtain these wires by a lookup() operation, and releases them via a release() operation. It is not defined just how these two operations are done by the client, but the client can do them. SCENARIO: Client uses component. Component is to be hot-swapped. What does client percieve when component is swapped? I.e. from the client's point of view, what happens? And these are the alternatives that I know about... ALT1: Wires are severed immediately, the component is reloaded. Advantages: We know what happens with some certainty. The client will get a big fat InvalidWireException thrown in its face, and have to deal with it - but we know that this will happen and can thus code for it. This is what happens when you run a distributed app / DB connection pool, so it's really not something that's unheard of. Disadvantages: Coding for that InvalidWireException can turn into a mess. ALT2: Wires are left intact and the new component is loaded in parallell with the existing component. All future lookup() operations will return a wire to the new component, and the old component will be undeployed when all wires to it has been release()'d. Advantages: A smooth phasing-in of the new code. No exceptions thrown. Disadvantages: A bit of a problem if the component was supposed to be a singleton, or if it accesses some shared resource, such as a log file. Suddenly, you have two instances of something that should only have one instance. Additionally, you'll never know if there is some wire that's unreleased, so if you hotswapped a component due to a serious security fix, you can't ever find out if the new code is really running everywhere in the system. ALT3: Slap a read-write lock on every wire. When a component is about to be undeployed, get a write lock on every wire before severing them. Client must do a lock()/unlock() operation around blocks of code where it can't handle the severing of a wire. Advantages: Works perfectly well in theory. Disadvantages: Deadlocks - but we can make lock() fail instead of block to get around this. Perhaps. Harder to implement than alt 1 or 2. /LS
RE: [Kernel22] How to develop a component?
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > > > So, if I understand you correctly, the only difference is > that I can > > get an exception that I wasn't prepared to get when using Avalon. > > Yep, that's pretty much it. One more thing - since all components are proxied now, you'll incur a proxy overhead in the call. But that can be minimized by smart container code. (Which we will have, of course.) /LS
RE: [Kernel22] How to develop a component?
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > So, if I understand you correctly, the only difference is that I > can get an exception that I wasn't prepared to get when using > Avalon. Yep, that's pretty much it. > If that's try then I don't see any reason why this > wouldn't work with using the Avalon interfaces - I'm just > speaking of the interfaces not the implementation! It will work, but the thing is that people have started assuming that some things will work in certain ways. So while the interfaces will work in practice, they won't in theory, since there are some semantics that are gone. /LS
RE: [Kernel22] How to develop a component?
> -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: den 8 april 2004 16:24 > To: [EMAIL PROTECTED] > Subject: RE: [Kernel22] How to develop a component? > > > > > > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > > > > > How does the working code look like? > > > > The working code of what? > > > > The adapter / sandbox / compatibility layer? > > > The working code with some cocoon interfaces. I guess the > component interface for the stateful component is the same. > So, the different should be in the client.java code. Or am I wrong? The new code would be very similar. The new "Block" code uses Wirings instead of a ComponentManager/ServiceManager, but they are *very* similar. You should also include a comp.ensureWired() call at the top, to test if the block whose components you are using hasn't been reloaded since you last checked. (This call will also reload the block if it is scheduled for reload, but not yet reloaded). ***The biggest change however***, is that you have to be prepared for the event that a component that you have looked up may disappear due to block reloading. This simply did not happen with Avalon. So you may get an exception where you didn't get one before. Otherwise you should be fine. /LS
RE: [Kernel22] How to develop a component?
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > How does the working code look like? The working code of what? The adapter / sandbox / compatibility layer? /LS
RE: [Kernel22] How to develop a component?
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>
> Stefano Mazzocchi wrote:
> > If you have two blocks in the avalon sandbox, you could share them
> > between them, but there is no (easy? elegant?) way you can
> pass them
> > arond *OUTSIDE* the sandbox and still allow blocks to be
> hotswappable
> > and runtime polymorphic.
> >
> > [I would gladly be proven wrong here!]
>
> write a failing testcase that doens't require me to understand every
> little detail of cocoon internals and I could try.
Easy.
interface StatefulComponent {
public void login (); // never throws any exception, ever.
public void doOperation (); // never throws any exception, ever.
public void logout (); // never throws any exception, ever.
}
Client.java:
StatefulComponent comp = (StatefulComponent)
manager.lookup(StatefulComponent.ROLE);
try {
comp.login ();
// (1)
comp.doOperation ();
comp.logout ();
} finally {
manager.release (comp);
}
If a block reload of the implementation of StatefulComponent
occurs at (1), the comp proxy will be invalidated while in use,
and the operation will fail.
This is contrary to Avalon semantics, where a component reference,
once obtained, remains valid until it is released.
Of course there are ways to code around this (or ignore it) in
the vast majority of cases.
/LS
RE: [Kernel22] How to develop a component?
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > If you have two blocks in the avalon sandbox, you could share them > between them, but there is no (easy? elegant?) way you can pass them > arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable > and runtime polymorphic. > > [I would gladly be proven wrong here!] You will not be proven wrong for all cases of Avalon components, but for certain types of such components it is perfectly possible to pass them around outside of the sandbox. What remains is to figure out is under what conditions Avalon components can be passed around and hot-swapped. I think we'll capture something like 90%-95% of the business logic components that Carsten and I are worried about. The remaining 5%-10%? We'll deal with them when needed. /LS
RE: [Kernel22] How to develop a component?
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > So, like we already said before, it is *totally* possible to have a > block load avalon components thru an avalon sandbox (sort of a > avalon->cocoon adapter). This allows you to reuse your avalon > stuff "AS IS". But this also means that your block cannot expose those > components outside of that block. I don't think so. The fact that Avalon doesn't support hotswap in all cases does not mean that you can't write Avalon components that do support such a thing. Look at Composer.acquire() - does it matter if the object returned is a proxy to some internal Avalon object? No! You can have: +Block---+ | +-+Component | | +Composer--++ECM+ | | | | || |--+-+Component | | +--++---+ | | | +-+Component | ++ And then expose the components managed by the ECM via a proxy. However, those components must either: ...be written in such a way as to support the additional requirements that Cocoon has ...or have that functionality added via proxying etc. So I think Carsten's (and my) business logic, and all our Avalon components that we use across multiple projects and containers are perfectly safe. /LS
RE: [Kernel22] How to develop a component?
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi > > > So what do others think? > > Cocoon components will never work putside of Cocoon. But will non-Cocoon components work inside of Cocoon? If so, with how much work in adapting? Or can a general adapter be written that uses proxies etc? /LS
RE: [Kernel2.2] Comments
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > > On 1 Apr 2004, at 12:27, Leo Sutic wrote: > > > Can we add an attribute or something to each block saying > > "yes, I can be gracefully redeployed" or "when you undeploy me, > > you must cut all wires immediately"? > > I think you could achieve the same result by listening to the destroy() > event triggered by the framework when the block is undeployed. OK, so this even is guaranteed to be sent before the new block is deployed? /LS
Re: [Kernel2.2] Comments
I and Pier exchanged some emails off-list (since I didn't have
access to the list). Here goes:
> >From: Pier Fumagalli <[EMAIL PROTECTED]>
> >
> >On 31 Mar 2004, at 20:34, Leo Sutic wrote:
> >
> >>Pier,
> >>
> >>I'm out of [the] office, so I can't reply to the list. But it
> >>seems like we
> >>have different ideas about what will happen in some scenarios.
> >
> >No worries...
> >
> >>The scenario I'm thinking about is this:
> >>
> >> MyInterface object = (MyInterface) wires.lookup (
> >> MyInterface.class,
> >> "wiringname");
> >>
> >> ((Wire)object).ensureWired();
> >> try {
> >> // OK, object is wired
> >>
> >> object.doSomething ();
> >> object.doSomethingElse ();
> >>
> >> // At this point, the block we're using via
> >> // object is reloaded...
> >>
> >> object.doSomething() // What happens here?
> >> } finally {
> >> ((Wire)object).release() / dispose();
> >> }
> >>
> >>Question: What happens at the line marked with "// What happens
> >>here?"?
> >
> >My first though was that you would get an
> "IllegalStateException" (and
> >that's how it behaves right now). Once the wire is cut the
> instance of
> >the proxy is lost. Look here:
> >
> >http://cvs.apache.org/viewcvs.cgi/cocoon-2.2/src/kernel/org/apache/
> >cocoon/kernel/ProxyWire.java?annotate=1.4
> >
> >Lines from 259 to 275, especially 265, the instance is set to null
> >during a call to "cut()", and if you look at lines 243 to 248, you'll
> >notice that once the wire is cut, any call apart from
> release, dispose,
> >finalize or wired is going to throw an IllegalStateException.
> >
> >>Do I get an exception thrown (wire is cut)? Or does the call go
> >>through to the version of the block I had before it was
> reloaded (wire
> >>isn't cut)?
> >>
> >>What I *want* to happen is to have an Exception throws
> (forcibly cut
> >>the wire when the thing it is connected to is reloaded).
> >>
> >>What you have told me happens is that I will keep on using the old
> >>version until I call ensureWired() again. The reason I
> think that is
> >>dangerous is because bad code may forget to call
> ensureWired() and may
> >>forget to release the wire. If Exceptions are thrown I'll know that
> >>there's something wrong. If they aren't I'll just get corruption.
> >
> >Now, that's the evolution on my though, and what I asked to the
> >community to think about because I'm still unsure of what's the best
> >practice.
> >
> >We could consider a situation in which an undeployment of a block
> >doesn't actually forcedly CUT the wire, so, if I'm using a
> transformer,
> >for example, that transformer will render the entire page
> and will not
> >fail with an IllegalStateException.
> >
> >The block could be marked as "undeployed" and therefore the new
> >instance will always return the new wires for all new
> lookups. We would
> >have a block "undeployed" associated with some "stale" wires, and a
> >"deployed" block where new wires will be loaded from...
> >
> >It's a bad situation in which we're in because the JVM garbage
> >collector wouldn't be able to dispose of the old
> (undeployed) block, as
> >somehow we're still holding references to it, but on the
> other hand, it
> >would be a good situation for nicely developed blocks
> because it would
> >basically means that when I redeploy a transformer, all requests
> >processed with it would not fail miserably.
> >
> >Clear case scenario, if I "update" (replace the running
> instance) of my
> >XSLT transformer block on a live website, I want all requests to go
> >through anyway, and after 2 minutes, if someone is holding (still) a
> >wire, and the block was not garbage collected, well, I'm going to
> >forcedly cut all the wires, and exceptions will be thrown to anyone
> >holding the stale wires.
> >
> >You have to remember that redeployment is a manual operation
> (a human
> >being is actually doing it) and that person is going to be
&
RE: Email account utilization warning.
Return addresses are spoofed by the worm. Pay no attention to them. However, you can check the received-from headers in the email to see where it was sent from (some may be spoofed as well, so ignore the servers you don't trust). For example, I received this email from fumagalli exoffice.com: Received: from smtpin32.myhosting.com [10.5.8.3] by mail.inspireinfrastructure.com with ESMTP (SMTPD32-8.05) id A9205B7053E; Fri, 26 Mar 2004 07:59:12 -0500 Received: from rex ([217.153.27.13]) by smtpin32.myhosting.com for leo.sutic inspireinfrastructure.com; Fri, 26 Mar 2004 07:59:09 -0500 Date: Fri, 26 Mar 2004 13:59:11 +0100 To: leo.sutic inspireinfrastructure.com Subject: From: fumagalli exoffice.com Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="876506221084734" X-RCPT-TO: inspireinfrastructure.com> Status: U X-UIDL: 377103200 Looking at the Received: header we see that mail.inspireinfrastructure.com (which I trust) received it from smtpin32.myhosting.com (which I trust). And that smtpin32.myhosting.com received it from "rex" who is at 217.153.27.13. Doing a nslookup leads us here: http://www.ripe.net/perl/whois?form_type=simple&full_query_string=&searc htext=217.153.27.13 address: Ster Projekt S.A. address: ul. Magazynowa 1 address: 02-652 Warszawa address: Poland What has happened is that some guy in Poland got hit by this worm. It scanned his Internet Explorer cache and found the fumagalli exoffice.com address in some cached webpage, and used it. /LS > From: Carlos Araya [mailto:[EMAIL PROTECTED]
RE: [Kernel2.2] Comments
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED] > > Leo Sutic <[EMAIL PROTECTED]> writes: > > > > > My whole argument is that your design will end up being very very > > complicated and very very hard to develop for, since it > > provides so few > > guarantees to block developers. Things like "what code is > > running", for > > example. > > So if you've got something for which blocks are not suited > (like perhaps SSL, or a DB pool), don't use blocks; use > modules or whatever it is that does give you the contract you > want. The rest of Cocoon isn't going away... I thought Blocks would be the new, well, building blocks of cocoon. As Stefano said here: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108014494301217&w=2 What does this mean for you? Well, it's rather simple: old code will work in an avalon sandbox. It basically means that it will see cocoon *exactly* as it used to be before. But this will also mean that will be isolated from other blocks and will not be able, for example, to load components from other blocks. So, the rest of Cocoon isn't going away, but it isn't going anywhere else either. /LS
RE: [Kernel2.2] Comments
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>
> On 31 Mar 2004, at 14:33, Leo Sutic wrote:
>
> > 1. Singletons
> The "Composer" is always singleton in each block instance. There are
> never two Composers in a single block instance.
OK.
> You might argue that you want a "framework" singleton (or a block
> that cannot be
> instantiated more than once)...
No, I don't.
> > 2. Reloading
> > 2a. Stale classes
> >
> > One problem is when you retain a reference to a class that
> > is about to become reloaded. For example:
> >
> > interface Templates {
> > public TransformerHandler getTransformerHandler ();
> > }
> >
> > interface MyBlock {
> > public Templates getTemplates ();
> > }
> >
> > and the impls: TemplatesImpl, MyBlockImpl.
> >
> > Suppose you get a handle to MyBlock. Then you get the Templates from
> > it. Then the MyBlockImpl block is reloaded. When you call
> > getTransformerHandler on the Templates you just retrieved, will you
> > execute the old code or the new code? Obviously, the old code.
> >
> > Will this old code work with the new classes that has been reloaded
> > in the rest of the system?
> >
> > Maybe.
>
> Not maybe, yes... The ClassLoading paradigm associates every single
> class with its own classloader implementation. Old classes
> will retain old classloaders and will work as if nothing has
happened...
I don't understand what you base that "yes" on. Will the classloading
work? Yes, it will. But will *the* *rest* of the system work? You have
no guarantee at all.
> It's how it works with servlet containers (for example).
Yes, but the servlets are isolated from each other in the appserver.
These blocks will be anything but.
So of course you can undeploy a webapp and deploy it again without
issues - it isn't wired to any other webapp, and you can cleanly eject
it from the container. Blocks are wired.
> > Suppose a you have a SSL block. Further suppose that a bug has been
> > discovered in it and you have to get it patched.
> >
> > With the side-by-side running, I have *no guarantee* that the new
> > block is active.
>
> I don't understand what you're talking about. Describe
exactly
> the structure of the blocks, because I'm pretty much sure that if you
> follow a correct blocks design, you'll be able to reload your SSL
> engine and everything will be absolutely guaranteed to work no
> problems.
My point is this: Since you will run an old block side by side with
the new one until all references to the old block are gone, you
depend on correct block design and correct block implementation for
those references to be released.
That is, unless the blocks are properly designed and properly
implemented the old block will not be released, and will be used
by clients that hold on to this old reference.
So, if you have a bad client that incorrectly holds on to an old
copy of your SSL engine, then that client will pose a security risk.
Of course, you say, bad clients are security risks! Which is true,
but there are some aggravating circumstances here:
The security risk only occurs when reloading.
This means that the risk only manifests itself in a scenario that
is unlikely to have been thoroughly tested by the developer. How much
time do you think people will put into the "is my block reload-safe"
testing?
I think you proved my point with your reply. How complex/easy is
this "correct blocks design"? Of course it will work if all code
is perfect. But how easy is it to produce code that is correct?
> > 2b. Multiple blocks stepping on each other's toes
> >
> > You risk not only a crash, but that ***wrong stuff*** is being done
> > ***without a crash***. The resource may be stateful:
> >
> > interface AccountCursor {
> > public void moveToAccount (String account);
> > public void withdraw (int amountOfEuro);
> > public void put (int amountOfEuro);
> > }
> >
> > What would happen if two block instances accessed this resource in
> > parallell? No errors, but a messed up account DB.
>
> I don't see how this can be different from having TWO instances of the
> same Object... If you have to serialize access to a resource, simply
> declare it static in your class (as you would in a normal java
> application) and synchronize onto it...
Please - no reliance on classloader setup. The classloader tree can
be very complex in some cases, and having code that relies on just
one setup is just plain bad.
> When triggering blocks reload because of a change in
RE: [Kernel2.2] Comments
OK, I've gotten my head round the kernel in a sort-of kind-of
way.
My basic problem with it is the management of block instances.
(I absolutely love it in every other respect.)
1. Singletons
I have repeatedly (both in my own development and based on
questions from users) seen the need for a singleton design
pattern. I.e. when a block instance corresponds to some
physical resource that can't be virtualized. For example,
a database connection (if you're only allowed one), can
be shared among several clients, but you must still have
a singleton that manages that single connection.
For Cocoon, one could argue that such blocks should be
outside of Cocoon, but this is not always possible.
2. Reloading
When I first read about this framework the plan was to
simply drop the block when it was being reloaded, no matter
if it was currently executing a method call, or whatever.
Then after some discussion the idea was to keep the new block
and the old block side by side and gradually phase out the
old block as it was released by clients.
However, I think this will lead to unpredictable behavior.
This type of lazy reloading will cause problems, even more
problems than the usual ones you get when reloading classes.
2a. Stale classes
One problem is when you retain a reference to a class that
is about to become reloaded. For example:
interface Templates {
public TransformerHandler getTransformerHandler ();
}
interface MyBlock {
public Templates getTemplates ();
}
and the impls: TemplatesImpl, MyBlockImpl.
Suppose you get a handle to MyBlock. Then you get the Templates
from it. Then the MyBlockImpl block is reloaded. When you call
getTransformerHandler on the Templates you just retrieved, will
you execute the old code or the new code? Obviously, the old
code.
Will this old code work with the new classes that has been reloaded
in the rest of the system?
Maybe.
Suppose a you have a SSL block. Further suppose that a bug has
been discovered in it and you have to get it patched.
With the side-by-side running, I have *no guarantee* that the new
block is active.
2b. Multiple blocks stepping on each other's toes
Suppose a block accesses some kind of resource that only accepts
one client, meaning that the block must serialize access to
that resource. This can be done via synchronized wrapper
methods, mutexes or whatever.
But if you suddenly have two instances of the block... Well, you've
pretty much had it then.
You risk not only a crash, but that ***wrong stuff*** is being done
***without a crash***. The resource may be stateful:
interface AccountCursor {
public void moveToAccount (String account);
public void withdraw (int amountOfEuro);
public void put (int amountOfEuro);
}
What would happen if two block instances accessed this resource
in parallell? No errors, but a messed up account DB.
3. Over-reliance on Administrator Omniscience
Linked to the "maybe" in 2a.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108032323410266&w=2
Thing, that (by the way) will _NEVER_ happen automagically, but only
when the administrator decides that it's time to reload a block
instance?
So, why should we bother with these problems? The administrator
knows when a block can be reloaded, right?
Wrong.
What sane admin will hit the reload button, unless he knows
with some certainty what will happen, or that the system will
crash instead of trashing important databases if something goes
wrong?
Frankly, I'll be too scared to use this reloading functionality.
And then what's the point?
I can also answer the question immediately before the quote above:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108032323410266&w=2
What's the difference between that, and loosing the connection
for a second with a component?
When a connection is lost it is *lost*. It has well defined behavior. It
has easily understood effects on the code. It has *visible* effects on
the code (Exceptions being thrown everywhere).
With this lazy reloading scheme, or any reloading scheme that doesn't
involve locking, you won't get any exceptions, but you'll get a whole
lot of nasty errors that will not leave any other trace except a trashed
server after a few hours of running bad code.
/LS
RE: [Kernel2.2] Comments
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>
> > Some quick observations:
> >
> > 1. @author http://www.vnunet.com/";>VNU Business
> > Publications
> > Is this OK with Apache and VNU?
>
> Defintely OK with VNU (if someone visits our site because of a click
on
> the JavaDOC, and then come back, we got one more customer... If you
> guys don't want to see it in there, you can remove it no
> problems... It is in my default Java class template.
I have absolutely no problems with this. Just wondered if it had been
left in accidentally.
> > 2. Wire.java
> > /**
> > * Check wether the wire between this [EMAIL PROTECTED]
> Wirings} instance
> > and the
> > * original component is still active.
> > *
> > * When this method returns true all methods
> called on
> > this
> > * instance will be forwarded to the original component
> instance
> > associated
> > * with this wire.
> >
> > You cannot guarantee that. The instance may be
> redeployed between
> > the call
> > to wired() and the next call.
> >
> > No point in having a method whose return value means nothing.
>
> This method will return true until the block instance will not be
> destroyed or replaced by the Deployer, and when this method returns
> false, whoever got this wire should release it and acquire a new one
> (which will be got from the new block instance).
>
> Rember? The idea is never to completely remove blocks until
> forced to, so the Wire instance will still work even if wired()
returns
> false. The wire will only be deactivated by either a call to release()
or
> dispose() or by a forceful destruction by the deployer.
I'd still like this to be transparent...
Having a coding convention that requires you to do wired() checks
before every call is bad in my opinion.
What you can do is have an:
Wire.ensureWired()
which will do:
if (!wired()) {
// renew proxy target
}
Then the client can call the method before it starts processing. I.e.
the client notifies the framework that "if you want to drop this
instance,
now is a good time".
> Yes, each component instance has only one contextualized wire, because
> that instance is its own wire as it is returned to the caller. The
> JavaDOC goes in quite a lot of details on why this is done, and
provide
> some examples.
OK, will check.
> > 5. Configuration.java
> >
> > public class Configuration extends ArrayList
> >
> > I'd use composition instead...
>
> ??? extends AbstractList ???
No, I meant:
public class Configuration {
private final List nodes = new ArrayList();
...
}
> > 6. Parameters.java
> >
> > Get rid of this one. Why can't components accept a hierarchy of
> > configuration nodes as configuration data?
>
> No... Parameters are typed and the framework checks the type of each
> parameter. One of the parameters CAN be a configuration on the other
> hand if in its descriptor the block requires:
Missed that. Thanks!
> > 9. Identifier.java
> >
> > *
> > protocol://location/path/major.minor(.revision)?
> >
> > Does this mean that all Blocks are automatically mapped into a
URL
> > space?
>
> All blocks have a unique identifier. And this list agreed that each
> block identifier will assume the requirements specified in the
> Identifier interface.
Yes, I'm with you so far. But what does the URL really signify? What if
I put the URL into my web browser? Will I download the block? Or?
/LS
[Kernel2.2] Comments
Nice work! Some quick observations: 1. @author http://www.vnunet.com/";>VNU Business Publications Is this OK with Apache and VNU? 2. Wire.java /** * Check wether the wire between this [EMAIL PROTECTED] Wirings} instance and the * original component is still active. * * When this method returns true all methods called on this * instance will be forwarded to the original component instance associated * with this wire. You cannot guarantee that. The instance may be redeployed between the call to wired() and the next call. No point in having a method whose return value means nothing. 3. Component.java: /** * Contextualize this [EMAIL PROTECTED] Component} component instance with the * [EMAIL PROTECTED] Wire} through which its caller is accessing it. * * @param wire the [EMAIL PROTECTED] Wire} instance associated with this instance. */ public void contextualize(Wire wire); Does this mean that each component instance only has one wire? I.e. only one client? You may end up with a lot of components if you have component A depends on B, C, D, which depends on E, F, G, H... Wouldn't it be better to keep this as a ThreadLocal variable that can be accessed by the component? Then you can have multiple clients, but only one client per calling thread (which seems like a reasonable tradeoff). 4. Wirings.java Talks about ((Wiring)myObject).release(); Should be ((Wire)myObject).release(); #include 5. Configuration.java public class Configuration extends ArrayList I'd use composition instead... 6. Parameters.java Get rid of this one. Why can't components accept a hierarchy of configuration nodes as configuration data? 7. Configurable.java Should accept Configuration instead of Parameters. Being able to send in a tree-structure of config info instead of a flat list is useful. 8. Block.java Love it. 9. Identifier.java * protocol://location/path/major.minor(.revision)? Does this mean that all Blocks are automatically mapped into a URL space? Still trying to get my head around the rest. /LS
RE: On blocks reload (Re: [RT] On building on stone)
Pier, I'd actually rather see you just axed the block with no further ado. Having a stale reference to a component may just make the bugs more subtle and harder to find. /LS > From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
RE: [RT] On building on stone
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > > Why? If a request fails because I reloaded the XSLT Transformer block, > well, I'm ready to loose that request... Cocoon is a servlet, at the > end of the day, and I'd rather loose XSLT translation for 1/2 > a second while I reload the XALAN block, than wait 10 minutes while I > reload the JVM, as I can't reload XSLT because every single Pipeline in > my sitemap is locking on it, and (of course) I will never ever be able to > reload it until the traffic on my website goes down to ZERO... In all read/write lock implementations I've ever seen, having a pending writer means that readers queue up. That is, you'll have to wait until all *currently executing pipelines* have finished. Then you'll get your write lock and can swap the block. All pipelines that tried to lock the component after your request to acquire a write lock will have queued up, and will start executing as soon as you release your write lock. But the point here wasn't really to argue specific cases, was it? > Dude, don't get upset, I'm not thinking about the holy grail here, I > _DO_NOT_WANT_ to write another Avalon, I want Cocoon to have a > container tailored EXACTLY for its own requirements, being a servlet > and all... > > Let's not forget that we work on HTTP connections, and that at any > given point in time, those can be disconnected, time out, or your > network admin can unplug the cable... > > What's the difference between that, and loosing the connection for a > second with a component? Thing, that (by the way) will _NEVER_ happen > automagically, but only when the administrator decides that it's time > to reload a block instance? Because I think that you are trading a little complexity in the container for a lot of complexity in the blocks. Then again, that's *my* VHO. Basically the question is this: Is the code expected to handle a swap of a block gracefully? If a block swap really is like unplugging a network cable, or toasting the switch/router, then code should just re-throw the exception and exit abruptly. However, if the code is somehow expected to recover, then I think that there should be some mechanism whereby the swapping is made invisibly to the code (i.e. when the block isn't used). Otherwise the amount of error-handling code will become impractical. /LS
RE: I got an error
> Subject: I got an error
>
> En error rise up when compling this:
> String user = ;
>
> user
>
>
> The error is:
> org.apache.cocoon.components.language.LanguageException:
> Error compiling
> login_xsp:
> ERROR 1 (org/apache/cocoon/www/Nautilus/xsp/login_xsp.java):
> ...
> msg = "Utente "+user+" autenticato -
> pu\u00F2 procedere alla pagina di configurazione" ;
>
>
> session.setAttribute(String.valueOf("user"),
>
> // start error (lines 140-140) "String literal is not
> properly closed by a double-quote"
> "
>
> // end error
> user
> ");
>
> It seems to me syntax is ok! Where I'm wrong?
Seems like the string literal "user" has been split up
over several lines. So, you have the opening quotes
on one line, and the closing on another. In Java, that's
a no-no.
Try:
String user = ;
user
I.e. put the set-attribute tags all on one line.
/LS
RE: [RT] On building on stone
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > > On 26 Mar 2004, at 11:57, Leo Sutic wrote: > > > > Think about TCP/IP. You have guaranteed delivery of packets > (which you > > don't have with UDP). Completely guaranteed? No. A > chopped-off network > > cable is not something that the protocol can handle. But still very > > useful. > > The TCP/IP is a good example... > > To use the same parallel, when I open a TCP connection I am guaranteed > that I'm going to get a Socket object (to use Java) I can use. But the > platform doesn't guarantee me that its InputStream or OutputStream are > going to be valid forever, they might throw IOExceptions, and the > socket itself can be in a connected or disconnected status (you're > never guaranteed). > > You go usually until you don't hit an IOException on the streams (or > isConnected() returns true), but then you'll have (somehow) to handle > that state change which you don't control... > > Wirings between blocks behave in the same way, you go until one of the > methods you call doesn't return an exception, or until the wiring is > available (err, you can check on that), Actually, you can't. There's no guarantee that the block isn't going to be swapped out between the checking call and the next method call. So there's absolutely no point in making the checking call. There's even no guarantee that the block won't be swapped out ***while it is executing a method***. Now that's starting to become dangerous. > If component locking needs to be performed, it needs to be a framework > feature unaccessible to components, otherwise it will be abused of. Well, for stateless interfaces (think MailServer), the framework should lock the component during the method call, so the block isn't swapped out while it is executing a call. For stateful interfaces (think ContentHandler), the framework can lock the component between lookup and release. /LS
RE: [RT] On building on stone
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > > On 25 Mar 2004, at 17:44, Leo Sutic wrote: > > > Could also be solved by introducing the notion of component > > transactions. Add a read and write lock to each component wire. > > Block A could in effect disable hot-swapping of a component while it is > > used (i.e. get a read-lock on the wire), while the hot-swap machinery > > tries to get a write-lock on the wire. Thus, the component will > > never be swapped when used, and thus the wire-check is unneccessary. > > That (IMVHO) a bad approach. Components should not "lock", because > (anyway) that lock cannot be guaranteed... > > So, what's the point in "guaranteeing" the availability of a component? The point is to avoid unnecessary failures by guaranteeing that the framework will handle events that are expected to occur in itself. There's a difference between a switch being unplugged (an exceptional circumstance), and a block being swapped (which is quite normal). In the exceptional circumstance you can simply release all acquired resources and let the exception propagate upwards to some error handler, because it is inherent in the definition of an exception that there's really nothing you can do about it, but a block swap should be handled gracefully - perhaps by trying again. > Much _much_ better to make you completely aware that someone can > disconnect that wiring at any time, and you'll write your code to > handle it... Yes, because every coder just loves to write error-handling code? Either a block swap is something you should write error-handling code for or not. If it is, then you risk the same problem as Java has with ThreadDeathError - there's really no sensible way to protect against it. If it isn't, then, well, boom. Letting the framework handle the type of errors that *should* be handled is good, because it moves handling for *common* *events* *that* *naturally* *occur* *within* *the* *system's* *specification* to a central point. Trying to make the framework handle errors that are completely outside the spec (server losing power), is bad. Think about TCP/IP. You have guaranteed delivery of packets (which you don't have with UDP). Completely guaranteed? No. A chopped-off network cable is not something that the protocol can handle. But still very useful. /LS
RE: [RT] On building on stone
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > As for your specific solution, well, I think it's better to start with > what Pier has, then, once the code is in our CVS, we'll discuss how to > improve it/change it/throw it away. I agree. It was just a reflexive comment when I read what the main difference was (hotswappability). > How's that as a deal? Sure! Bring it on. /LS
RE: [RT] On building on stone
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > But... > > > Is this related to the statefulness of the component? > > ... as you correctly spot, the thing is way more tricky than > it looks at > first. > > The way we solved this was to enable a sort of loose-coupling wiring > between components. This requires block A to check for the > wire validity everytime a service is invoqued and, if not, look it up again > (obviously the framework will provide helping code for this). Could also be solved by introducing the notion of component transactions. Add a read and write lock to each component wire. Block A could in effect disable hot-swapping of a component while it is used (i.e. get a read-lock on the wire), while the hot-swap machinery tries to get a write-lock on the wire. Thus, the component will never be swapped when used, and thus the wire-check is unneccessary. /LS
RE: [RT] On building on stone
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > Because avalon components are directly wired while the new components > will be loosely wired. This is the only way we can achieve > hot-swapping polimorphism and Avalon4 simply cannot do that. So, even if you instead of having: Client Component have: Client Proxy Component You can't do the hotswap? Is this related to the statefulness of the component? /LS
RE: [RT] On building on stone
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > > But this will also mean that will be isolated from other blocks and will > not be able, for example, to load components from other blocks. Is that "not be able" as in "not under any circumstances", or "not under all circumstances"? That is, why isn't it able? /LS
RE: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > > But if someone provides a really useful 1.4 thing > like the mentioned "NIO-based implementation of the persistent store" > I'm for 1.4 of course. I'm more of a user than a developer of Cocoon, but I'd say that if someone can provide a reasonable argument that 1.4 would bring some useful things, I'd be for 1.4. I.e. no need to implement the NIO-based store, just some statement to the effect that it would bring performance benefits. (In this case, even with non-blocking NIO reads and writes, you'll still have to wait for the whole store.read() to finish, since the rest of the system isn't built around a non-blocking architecture. I therefore think that a NIO-based persistent store will not bring any significant performance boost without some serious re-architecting.) /LS
[Avalon][PMC] Release!
The following Avalon packages have been released: avalon-fortress-container-1.1 avalon-fortress-tools-1.1 excalibur-component-1.2 excalibur-event-1.1 excalibur-logger-1.1 excalibur-sourceresolve-1.1 excalibur-store-1.0 excalibur-xmlutil-1.0 /LS
[Avalon][PMC:VOTE/Release] Check 'em out!
AVALON PMC MEMBERS == The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and vote for release: +1 from me. I'd like to have this vote done by the end of today, since that means I can release them without having to worry about the license change. COCOON DEVELOPERS = The jars are in: http://cvs.apache.org/~leosutic/release/ Check 'em out and let me know if there are any immediate issues. /LS
RE: [RT] Alternatives to Poolable
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > Are they intrinsically big, or are they big because of all the stuff > every instance must hold that could be delegated to the "component > fields" I suggested? "Component fields". > I think most components fall in that second category. Me too. Basically, poolable components are components with a high cost of initialization. But at the same time, all components in the pool have the same configuration etc. and thus the same initialization parameters. This makes all components in the pool clones - when a component is put back into the pool it must be reset. Thus, all poolable components can be created anew for each use, if we could just take a snapshot of the component just after initialization. The big exception to this is when each component isn't equal - for example, a DB connection pool has each component corresponding to a *different* connection. > Furthermore, pipeline components are stateful because of the > asynchronous nature of SAX, but that state doesn't survive past the > processing of a pipeline: the state is initialized on startDocument() > and trashed on endDocument(). Hence the possibility to change these > components into factories. I'd go for the change-to-factories approach. Less magic, and it is a well-established pattern. /LS
RE: [RT] Alternatives to Poolable
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > Found a very interesting read at > http://www-106.ibm.com/developerworks/library/j-jtp01274.html? > ca=drs-j0504 > > This articles explains the memory allocation and collection > strategies of modern JVM and show that object recycling and > pooling can cause more harm than good. Yes, but he links to a presentation from JavaONE, that summarizes pooling with: http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessio ns/pdfs/1522.pdf + Loses for light-weight objects + A wash for mid-weight objects (Hashtables) + A win for big objects. Basically - if your object is significantly bigger than a Hashtable, you should pool it. What it boils down to is this: Is the time it takes to bring the object out of the pool (with the associated synchronization costs) longer than it takes to re-create the object? For Cocoon, I'm not sure that's the case. I think most objects in Cocoon are "big" by the definition given above. /LS
RE: System.exit() brings down Jetty/Cocoon
Litrik, I have had instances where the JVM has shut down due to a stack overflow. No exceptions, errors or anything - the JVM just stopped. However, if you still suspect a System.exit, I suggest you grab a Java decompiler and run it on all the 3rd party jars. Then grep for System.exit. That should settle your suspicions. (I also suspect you can grep for that method name in the .class files - but I'm not sure.) /LS > From: Litrik De Roy [mailto:[EMAIL PROTECTED] > > A call to System.exit(0) (for example in an XSP page) brings down > Jetty/Cocoon without any warning or error message. > > Is Jetty/Cocoon supposed to behave this way? > > How can this be prevented? > > PS: Yes I know that calling System.exit() is stupid, but our > Cocoon-based webapp is crashing intermittingly without any > trace and I'm > suspecting that somewhere in one of the 25 third-party jars a > System.exit() gets called (for whatever reason). Hence my > testing, and > this question. > > -- > > Litrik De Roy > www.litrik.com > > > > >
RE: [FYI] Apache Cocoon Directory Traversal Vulnerability
Nice one... I put a summary of it all in Bugzilla. /LS > From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
RE: ParentAware Components Revisited
The issue is this: A component in a child container has access to all components in the parent component manager - if the role isn't found in it's own CM, the lookup proceeds to the parent. However, when looking up a component via a selector, this is not the case. Since the selector was found, lookup stops there, irrespective of whether the hint passed to the selector really results in a component. The ParentAware interface enables this - if a selector for my.Generator/Selector doesn't have a component for hint "xyz" then it can look up my.Generator/Selector in the parent CM and try there. /LS
RE: Fortress Migration Strategy
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > > Could this not be realized via interceptors? > > > What do you mean by this? > > Ususally A would stream directly to B, with the changer > A streams to the changer and this streams to B. An interceptor is the general form of a changer. Basically, a thing that intercepts method calls to an object and does things. It is usually realized via a dynamic proxy that wraps the object you want to intercept method calls to. It is a clean and established concept. So getting it into Avalon should be no problem. I'm trying to map as much of the functionality of Cocoon to general, established concepts that are suitable for inclusion into Avalon. For example, we may not implement a changer directly, but we can give you interceptors and an easy way to build your changer in terms of those. /LS
RE: Fortress Migration Strategy
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > So in this sax streaming we have a class called > EnvironmentChanger that takes care that the current collection > used is the correct one. > So if the sub request sends an event to the main request, > a pointer is set pointing to the collection of the main > request. When this event is finished it is reset. OK... So, if I understand this right, then the entry-exit from these environment "bubbles" are method call and return, respectively? I.e. Pipeline stage A (a generator) has its own Environment, and when it calls startElement on stage B (in another request) then you switch Environment? And you switch back when the thread returns to A? Could this not be realized via interceptors? /LS
RE: Fortress Migration Strategy
Stephen, Berin,
I think Cocoon uses a stack-based scheme that can be implemented by the
container,
although it can't be exposed to those that only see the
Component/ServiceManager
interface.
This is pretty much how it works:
1. Define a method called beginProcessing in the container. This method
creates a Collection of component instances and pushes it onto a
Thread-Local stack. Note the thread-local thingy.
2. Every call to lookup will look at the top of the stack, and if it
finds a Collection there, add the instance it returns to that
Collection.
3. Every release will remove the component from any Collection in the
stack. This is O(n) in the number of invocations of beginProcessing.
4. Finally, define a method endProcessing that pops the top Collection
from the stack, and releases all components in it.
5. Code like this:
beginProcessing (); // Checkpoint
try {
doStuff (request);
} finally {
endProcessing (); // Rollback to previous checkpoint, i.e. four
lines back
}
What does this mean? Well, it means that when endProcessing is called,
any components
lookup'ed in the thread doing the doStuff() are released.
Think of it this way - we can consider everything to be single-threaded,
since we
only deal with thread local variables. When we enter doStuff we know
that no components
have been looked up. Then doStuff does stuff. Now, we have a record of
all components
that have been looked up but not released in the Collection where we put
them in step
(2) above. So endProcessing releases them.
I think this (a) how it works in Cocoon now, and a per-request
lifecycle/lifestyle.
/LS
> -Original Message-
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: den 16 oktober 2003 04:57
> To: [EMAIL PROTECTED]
> Subject: Re: Fortress Migration Strategy
>
>
>
>
> Carsten Ziegeler wrote:
>
> >Berin Loritsch wrote:
> >
> >
> >>Carsten Ziegeler wrote:
> >>
> >>
> >>
> >>>Berin Loritsch wrote:
> >>>
> >>>Yes, I think this is basically our extension together with the
> >>>
> >>>
> >>ParentAware
> >>
> >>
> >>>support.
> >>>
> >>>* ParentAware
> >>> A selector (or any other component) can declare that it is
> >>>
> >>>
> >>ParentAware,
> >>
> >>
> >>>which
> >>>means if you have a hierarchy of component managers and a
> component
> >>>is looked up in a child CM it get's a reference to a
> component looked
> >>>up in
> >>>
> >>>
> >>the parent
> >>
> >>
> >>>CM.
> >>>This is useful for nested selector e.g.
> >>>
> >>>
> >>Please elaborate a bit more. First, what problem does ParentAware
> >>solve, and why can't it be done with normal component resolution
> >>semantics?
> >>
> >>
> >
> >When you have a hierarchy of component managers (I still call them
> >component managers :) ), and you lookup a selector on the
> child CM and
> >then try to lookup a component using a hint that is not
> defined in this
> >selector but in a selector with the same role defined at the
> parent CM,
> >then the selector of the child CM can forward the lookup to
> the parent
> >one. Actually this is used in Cocoon for all sitemap components resp.
> >for the selectors for these components. So a selector for a generator
> >in a sub sitemap gets via ParentAware a handler (locator) to get
> >the selector defined in the parent sitemap.
> >
>
> All of the above is implementation specficic description. As
> far as the
> client side of the equation is concerned - imagine you were
> container-agnostic - is the client providing sufficient
> information for
> a solution? Yes - or no, can you provide a summary of the client
> (consumer component) infromation that is available and how this
> information is supplied to the contaier under the current
> implementation?
>
> >
> >
> >
> >>
> >>
> I believe I can solve these in the following manner:
>
> Request Scoped Components: Create a new lifestyle handler for
> Fortress.
>
>
> >>>Yes, should work, but we currently have this in two flavors: The
> >>>RequestLifeCycleComponent and the GlobalRequestLifeCycleComponent.
> >>>The GlobalRequestLifeCycleComponent is one instance per global
> >>>request comming into Cocoon. Even if this request creates sub
> >>>requests (using the cocoon protocol), it's still one instance.
> >>>The RequestLifeCycleComponent is oen instance per request. So, each
> >>>internal request gets its own set of RequestLifeCycleComponents.
> >>>Example:
> >>>a) main request looks up a component of role A
> >>>b) main request invokes sub request (cocoon protocol)
> >>>c) sub request looks up a component of role A
> >>>d) main request looks up a component of role A again
> >>>
> >>>I) The component is a GlobalRequestLifecycleComponent
> >>>a) main request gets instance ONE
> >>>c) sub request gets instance ONE
> >>>d) main request gets instance ONE
> >>>
> >>>II) The component is a Reque
RE: on better release and version management
> From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > * If you want to bypass that feature add the "-e" parameter > to tell Maven not to expect a network connection. It won't try > to download anything. Correction: -o not -e /LS
RE: [RT] Less is More, Finite State Machines and Balkanization
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED] > > Hunsberger, Peter wrote: > > > As I discussed with you when the flow sitemap integration > > discussions > > > where in full swing I do have a long term agenda (XSLT > > managed flow) > > > and I would like to see a way of including it in Cocoon without > > > breaking existing functionality... > > > > This is the wrong approach. > > > > Peter, you don't want XSLT managed flow. What you want is a > > solution to the problem that you have decided that XSLT > > managed flow is a > > solution for. (Did you follow me there?) > > > > I don't know why you presume to know what we want? It's not > XSLT based flow specifically OK, my mistake. I assumed you wanted a solution to your problem, and since you said you wanted XSLT based flow (your long term agenda) I assume that was what you wanted. My point was that the proposals in general shouldn't be "I want *this* solution" but rather "I want a solution that can solve *this*". I was trying to present your request in a different form - that the important thing wasn't the adoption of a specific solution, but the solution of a specific problem. /LS
RE: [RT] Less is More, Finite State Machines and Balkanization
Given the exposure Avalon's problems get here, I figure I'd open my mouth on this subject and spew out what I learned from the infighting we had there - because, make no mistakes, fighting is the correct word for what went on. (And thank God it's over and done with.) I think everyone here confuses two things: Action and intent. You can't codify good or bad behaviour based on actions without building an entire legal system. What matters is the intent behind the actions. For example, should core services in Cocoon be abstracted? Yes, absolutely. I think it is a good architectural pattern that will help you manage the code and really think about how Cocoon is held together. Should people be allowed to plug in their own versions of core services? Yes, absolutely. This is how a program evolves safely: Try out the new idea in a separate branch. So much for the actions, but what about the balkanization? Well, this is were intent comes in. I don't think there's any danger if the new branches are started with the intent that the *concepts* developed there should be merged back into the core, if the branch proves better. I also think that the intent must be not to lock yourself into a specific implementation, but to see the branch as something whose best aspects should be picked out and placed into the core. This is the risk: Developer A has a need to fill. That need can be fulfilled by writing a new version of some core Cocoon service. So A does that. Problem solved. Now A wants this implementation to be official in the sense that it should be included with the Cocoon default distro. And then all hell breaks loose. 50% wonder where this new chunk of code came from, 10% thinks it is useless, 99% don't want to maintain it, 99.9% admit to having no clue how the adoption of this new version will affect future development, and the last 0.1% percent is just kidding himself. By now A has significant investment in the code - it is running at his clients. He can't just drop it. So he fights even harder to get it into Cocoon. Things really start to turn to shit now, community- and technology-wise. The solution is to adopt this as a mantra: "You get what you need, not what you want." I'll describe below how this maps to the current situation. -oOo- So what about this rule-based flow processor? I think you're attacking the wrong problem. Before we ask ourselves whether it should be allowed in Cocoon, we have to ask ourselves what problem it solves that can't be solved with the current flow. Otherwise we get it completely backwards. Whoever wrote the rule based flow did so to solve a problem. But if we start talking about whether to adopt the rule-flow before we start talking about the problem that prompted its creation, then we're locking ourselves into one solution - the rule-flow. Do you see *why* this is backwards? A solution has been presented: The rule based flow processor. But (1) what is the problem it solves? And (2) why do we need the rule based flow processor to solve it? Once (1) has been made clear, perhaps we find that it can be solved with the current flow processor. Then we can do so and save ourselves a lot of code maintenance. So you'll get what you need (a solution to the basic problem), but not what you want (a rule based flow processor). Hunsberger, Peter wrote: > As I discussed with you when the flow sitemap integration discussions > where in full swing I do have a long term agenda (XSLT managed flow) > and I would like to see a way of including it in Cocoon without > breaking existing functionality... This is the wrong approach. Peter, you don't want XSLT managed flow. What you want is a solution to the problem that you have decided that XSLT managed flow is a solution for. (Did you follow me there?) You have a problem. You think that XSLT managed flow is a solution. You therefore try to get XSLT managed flow into Cocoon. Instead: You have a problem. Explain it. Say that XSLT managed flow is *one* possible solution. Maybe we can find a one-line change in Cocoon that will solve your problem without adding a whole flow implementation. Isn't that better? You get what you need (a solution) but not what you want (XSLT managed flow). And we avoid adding yet another implementation of core services. -oOo- OK, so why do we risk balkanization? Obviously and embarrassingly, it is much easier to code up a storm than to talk to people and do the give-and-take thing in order to reach consensus. This has nothing to do with coders being asocial. This is just the way the world is. And *that* is the risk with abstractions. It means that the cost for not talking to your peers drop. And that was what happened in Avalon. Thus we ended up with small islands of developers who simply put did not trust each other. So abstract and plug away, but never stop talking to each other. Be ready to drop your specific solution for
