cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Kernel2.2] Comments
Date Wed, 31 Mar 2004 17:35:38 GMT


> From: Pier Fumagalli [mailto:pier@betaversion.org] 
> 
> 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 the block classes

> themselves (when you create a new classloader) yes, you will have the 
> same problem: two instances of the same object, but this doesn't
differ 
> from when you reload a web-application in your servlet container.

As I said above - webapps are isolated from each other much more than
blocks. That means that the redeployment scenario is easier. 
 
> > 3. Over-reliance on Administrator Omniscience
>
> And administrator reloads a block when it wants to deploy a 
> new version of it (HTMLGenerator version 1.0.1 is updated by 
> HTMLGenerator version 1.0.2), and don't tell me that you want me 
> to shut down the ENTIRE VM to perform that change...

If the other option is to not know what code I'm running on my 
server, then yes.

So you've put the 1.0.2 version there. You've hit the "reload block"
button.

Does this mean that you're running version 1.0.2? No.

You are running 1.0.2 ***if*** all the blocks are correctly designed
and implemented, so that none is holding on to a reference to 1.0.1. 

How can you find out? You can't.

Does it matter in this case? Probably not.

Can this be a risk? Yes.
 
> I'm confident that if designed correctly, blocks won't have a problem 
> in rewiring themselves on newly deployed replacing instances,

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.

/LS


Mime
View raw message