Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: cvs commit:
 cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl
 SlideSourceFactory.java
Date: Wed, 3 Dec 2003 17:23:01 +0100
Message-ID: <84F0A43A4248CE45B5C0E20F4C40779C6009EC@naomi.webworks.nl>
Thread-Topic: cvs commit:
 cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl
 SlideSourceFactory.java
Thread-Index: AcO5sPm0qckwDos7RYm0DNlZ0cOfMgAAFd6Q
From: "Unico Hommes" <Unico@hippo.nl>
To: <dev@cocoon.apache.org>

=20

> -----Original Message-----
> From: Joerg Heinicke [mailto:joerg.heinicke@gmx.de]=20
> Sent: woensdag 3 december 2003 16:21
> To: dev@cocoon.apache.org
> Subject: Re: cvs commit:=20
> cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/
> source/impl SlideSourceFactory.java
>=20
> On 03.12.2003 14:48, Unico Hommes wrote:
>=20
> >>>>I am thinking JDO. What's the reason for this?
> >>>
> >>
> >>I'm not that familiar with Java or the Avalon lifecycles,=20
> but here is=20
> >>my analysis from
> >>http://wiki.cocoondev.org/Wiki.jsp?page=3DFirstFridayDecember2003:
> >>
> >>Make it possible to include also the OJB block by default without=20
> >>breaking Cocoon. This is a really important issue as it breaks our=20
> >>suggested build system workflow using=20
> local.blocks.properties! You can=20
> >>not include blocks when they are excluded in blocks.properties.
> >>
> >>AFAIU the reason for the problem is factory =3D new OjbStorePMF(); =
in=20
> >>the
> >>initialize() method in JdoPMFImpl.java. Isn't it possible=20
> to do lazy=20
> >>initializing when accessing factory the first time? I guess=20
> this has=20
> >>to be done in getPersistenceManager().
> >=20
> > Yes, you are right. I got it working now. I had to change=20
> the factory=20
> > instance variable's type to Object but it works. I hope=20
> this will also=20
> > work for other JVM's than the one I tested it on. Should I=20
> commit it?
>=20
> Why is the change to Object needed?=20
> Is this class=20
> instantiated on start up even if it's not Initializable?
>=20

Yes, that's ECM creating an instance and going through the static
lifecycle stages.

> Everything that's better than now should be committed. What=20
> are the potential issues with other JVMs?=20

I was concerned about the method <code>PersistentManager
getPersistenceManager();</code>. If JVM's are allowed to resolve all of
class's symbolic references during the linking process, this might
result in an exception. I looked at the JVM specification with a
collegue and found the following
(http://java.sun.com/docs/books/vmspec/html/Concepts.doc.html#19042):

"Resolution is the process of checking symbolic references from
Terminator to other classes and interfaces, by loading the other classes
and interfaces that are mentioned and checking that the references are
correct.

The resolution step is optional at the time of initial linkage. An
implementation may resolve a symbolic reference from a class or
interface that is being linked very early, even to the point of
resolving all symbolic references from the classes and interfaces that
are further referenced, recursively. (This resolution may result in
errors from further loading and linking steps.) This implementation
choice represents one extreme and is similar to the kind of static
linkage that has been done for many years in simple implementations of
the C language.

An implementation may instead choose to resolve a symbolic reference
only when it is actively used; consistent use of this strategy for all
symbolic references would represent the "laziest" form of resolution. In
this case, if Terminator had several symbolic references to another
class, the references might be resolved one at a time-perhaps not at
all, if these references were never used during execution of the
program.

The only requirement on when resolution is performed is that any errors
detected during resolution must be thrown at a point in the program
where some action is taken by the program that might, directly or
indirectly, require linkage to the class or interface involved in the
error. In the "static" example implementation choice described earlier,
loading and linking errors could occur before the program is executed if
they involved a class or interface mentioned in the class Terminator or
any of the further, recursively referenced classes and interfaces. In a
system that implemented the "laziest" resolution, these errors would be
thrown only when a symbolic reference is actively used."


So I think this says that a JVM is allowed to raise an error upon
<code>new JdoPMFImpl();</code> :-(

Of course we could just comment out the JdoPMF component xconf
declaration and require users to uncomment it when they want to use JDO
:-)

WDYT?

Unico