Woody Renamed?

[Leon Widdershoven]

Hi,

I was thinking to add a bit to the WhatIsFlow (from Bertrand Delacretaz) page 
in the Wiki, to mention how this integrates with Woody, when I remembered I
found a page some time ago that Woody had been renamed to something different.

Is that true, and what is the new name?

Regards,
Leon Widdershoven

[New Repository] Major design issue concerning state

[Rolf Kulemann]

Hello,

I see I'm lucky "moving that quick", because otherwise I never would
have found out the following.

I did a small sample with the WebDAVRepository. I'm creating docs, read
and write properties and version the docs via the WebDAV impl. of the
"new repository". Lets have a look at the requirement to create a newly
and LOCKED file in the repository. Using i.e. slides commandline client
for WebDAV u simple execute a) "lock newfilename.xml" and b) "put
src.xml newfilename.xml". BUT this only works within the same session.

That means if I lock into the webdav server a second time with the same
user, b) is not possible, because the lock is not only associated with
the user, but also bound to special session, here the first session.

To avoid this, the repsoitory impls. MUST act on the same WebdavResource
during a user session, but this is not possible by design!

Why?: Normally the Sources i.e. c) WebDAVSource are wrapping a special
d) WebdavResource. c) acts in all requests on the same d) which maintain
the state.

I have thought about alternatives, but all lead to concept where we
"need to pass around sth." reflecting the state. And that sth. is a
Source imho.

That is why I think the old SourceRepository concept is better, because
it is state aware since it acts on if wanted "stateful sources".

What is the disadvantage not being able to lock a non existent file in
order to create it?

Answer: Race issues. Lets create a new resource with put in order to
lock it afterwards. There is potential room for race conditions!

I really wonder, how this should be solved with the "new approach". Even
having ONE RepositorySource (to rule them all) would not solve it,
because it needs to wrap backend specific state which is in case of
WebDAV the WebdavResource. Thus we need single Source impls. for each
backend taking care of state. 

At the mom I recommend to extend the "old repository concept" with
versioning i.e. add methods
- checkout()
- checkin()
- uncheckout()
- setVersioned()

to the VersionalbeSourceInterface.


WDYT???
-- 
Regards,

Rolf Kulemann

[GUMP@lsd]: cocoon-2.1/cocoon failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For help 
understanding the request please visit 
http://gump.apache.org/nagged.html, 
and/or contact [EMAIL PROTECTED]

Project cocoon has an issue affecting its community integration. This issue affects 51 
projects. The current state is 'Failed', for reason 'Build Failed'

Full details are available at: 
http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon/index.html, however some snippets 
follow:

-  -  -  -  - -- --  G U M P

Gump provided these annotations:

 - Info - Jar [cocoon.jar] identifier set to jar basename: [cocoon]
 - Info - Jar [cocoon-tests.jar] identifier set to jar basename: [cocoon-tests]
 - Info - Jar [cocoon-deprecated.jar] identifier set to jar basename: 
[cocoon-deprecated]
 - Error - Project dist-avalon-logkit defines no jars as output
 - Info - Dependency on avalon-framework exists, no need to add for property 
avalonapi.jar.
 - Info - Enable "debug" output, due to a sequence of 10 previous errors.
 - Info - Failed with reason build failed


-  -  -  -  - -- --  G U M P
Gump performed this work:

http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.html
Work Name: build_cocoon-2.1_cocoon (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 22 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -debug -Dgump.merge=/data3/gump/gump-install/work/merge.xml 
-Dbuild.sysclasspath=only 
-Davalonapi.jar=/data3/gump/avalon/framework/api/target/avalon-framework-api-20040409.jar
 -Dlogkit.jar=*Unset* -Dversion=20040409 gump-core 
[Working Directory: /data3/gump/cocoon-2.1]
-
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/DocumentHandlerAdapter.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/DocumentHandlerWrapper.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/EmbeddedXMLPipe.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/IncludeXMLConsumer.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/LoggingContentHandler.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/LoggingEntityResolver.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/NamespacesTable.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/ParamSaxBuffer.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/SaxBuffer.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLBaseSupport.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLConsumer.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLFragment.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLMulticaster.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLPipe.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLProducer.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/XMLUtils.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DOMBuilder.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DOMFactory.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DOMStreamer.java
[javac] /data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DOMUtil.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/dom/DocumentWrapper.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/xlink/ExtendedXLinkPipe.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/xlink/XLinkHandler.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/xml/xlink/XLinkPipe.java
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/CompilingClassLoader.java:41:
 package org.tempuri.javacImpl.eclipse does not exist
[javac] import org.tempuri.javacImpl.eclipse.JavaCompilerImpl;
[javac]  ^
[javac] 
/data3/gump/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/CompilingClassLoader.java:79:
 cannot resolve symbol
[javac] symbol  : class JavaCompilerImpl 
[javac] location: class 
org.apache.cocoon.components.flow.javascript.fom.CompilingClassLoader
[javac] this.compiler = new JavaCompilerImpl();
[javac] ^
[javac] 2 errors

BUILD FAILED
/data3/gump/cocoon-2.1/tools/targets/compile-build.xml

Re: is databasereader's bug?

[roy huang]

Hi,all:
After some hacking way work,I believe it is not the code's error,it is database 
connection's problem.
In DatabaseReader.java,get blob stream in serialize(Response) like that:
   byte[] buffer = new byte[8096];
  int length = -1;

  while ((length = is.read(buffer)) > -1) {
   out.write(buffer, 0, length);
  }
  is.close();
  out.flush();

1.I make the buffer big enough to cache the whole file like 
byte[] buffer = new byte[8096000];
  the first time it read the whole file into buffer,works fine.but the second time it 
just can't,and the same wrong.
2.I print the exception in generate()
  try {
   Response response = ObjectModelHelper.getResponse(objectModel);
   this.serialize(response);
  } catch (IOException ioe) {
   System.out.println(ioe.toString());
...
and the message is:
java.io.IOException: [DataDirect][Oracle JDBC Driver]Object has been closed.
and the recycle() run.
the same jdbc driver in otherplace doing the same thing is fine,so I guest it may be 
database management,but I'm not sure is tomcat or cocoon.

WDYT?

Roy Huang

Re: [Kernel22] How to develop a component?

[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?

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.

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue  -- http://jicarilla.org/
---
"We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules."
-- Alan Bennett

Hang when getting a datasource connection - new version?

[Steve Krulewitz]

Hey folks --

I just ran into a problem on my development machine using Cocoon 2.1.4 
and Postgresql 7.4.  Requests are hanging when I call getConnection() on 
the datasource.  Drilling into the objects in the Eclipse debugger 
reveals that no connections are "ready" in the pool.  I believe this 
problem has come up a few times before:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106059323215738&w=2

The fix is to upgrade the excalibur-datasource-1.1.1.jar to something 
more recent, but I'm not sure where to get a newer binary.  The 
avalon-excalibur/datasource repository seems to have been totally redone 
since that jar was created, and I'm not sure how to compile what is in 
there.

Can someone point me to a binary version of this jar that has this bug 
fixed?

thanks,
-steve

RE: [Kernel22] How to develop a component?

[Ralph Goers]

Obviously, if I declared it as NonSwappable hot swapping would not be
allowed - at least for the class (that doesn't mean the rest of the block
couldn't be swapped, but that complicates matters).  

I guess I can envision 3 "types":
NonSwappable - can't ever be hotswapped.
Swappable - should be swapped using ALT3
Nothing declared - should be swapped using ALT2.

Ralph


-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 08, 2004 12:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [Kernel22] How to develop a component?

Ralph Goers wrote:

> is managing stuff that is supposed to be permanently available.  In this
> case your singleton is no longer a singleton.  Frankly, I'd suggest that
> classes meant to be singletons should implement a Singleton (or
NonSwappable
> or whatever) interface to prevent them from ever being reloaded.  By the
way
> - I think this is a problem for ALL the alternatives, not just this one.
> 
> ALT3 - From a client perspective, this looks just like ALT2. The client
does
> a lookup that obtains a read lock while release does the unlock.
> 
> Since the Singleton thing makes no sense to me anyway, I'd say use ALT2.

Ralph, what about when you want to hotswap your singleton to a new version?

-- 
Stefano.

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> 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: Documentation TOC started

[H . vanderLinden]

Hi,

> Awesome, Helma!

You made my day. :-)

> One thing I was thinking about:  Should we try to move the existing 
> "real" docs to the Wiki, to let us revise them easier?  I 
> think we would 
> need something to convert the docs format to Wiki and back easily. 

>From what I've seen, the formatting possibilities of the Wiki are less than
those of the "real" docs. So I think that some formatting will be lost in
the conversion and that might make it more difficult to understand/update.

> Chaperon should allow us to go from Wiki -> Docs, but it's a 
> matter of having the time to actually do it.

Right, so let's take "babysteps" in this and start with linking first. If
we're going to update pages, I'd rather do it by hand one by one. In that
case if time runs out there is SOMETHING, rather than a lot of work that can
be thrown out because it never reached the point of getting updated.

Bye, Helma

Re: Documentation TOC started

[Tony Collen]

[EMAIL PROTECTED] wrote:

Guys (and girls),

I want to structure all the documentation about Cocoon in the Wiki and the
xdocs. I've started small by setting up a Wiki page
http://wiki.cocoondev.org/Wiki.jsp?page=Cocoon215TOC which should become a
Table of Contents into documentation geared to Cocoon 2.1.5 and future
versions.
At first I want to fill this page with links to existing Wiki and xdoc
pages, after that missing pages should be added and outdated pages updated
or rewritten.
The first draft of this TOC is far from complete, so I'd like you all to
take a quick look at the wiki page and add missing items and sections.
Awesome, Helma!

I was rolling around the idea of how to reorganize and rewrite the docs 
the other day... I appreciate you taking the time to do this.

One thing I was thinking about:  Should we try to move the existing 
"real" docs to the Wiki, to let us revise them easier?  I think we would 
need something to convert the docs format to Wiki and back easily. 
Chaperon should allow us to go from Wiki -> Docs, but it's a matter of 
having the time to actually do it.

Thanks.

Bye, Helma
Thoughts?

Tony

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Ralph Goers wrote:

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?
Not only for the reasons you mentioned, but because presumably the singleton
is managing stuff that is supposed to be permanently available.  In this
case your singleton is no longer a singleton.  Frankly, I'd suggest that
classes meant to be singletons should implement a Singleton (or NonSwappable
or whatever) interface to prevent them from ever being reloaded.  By the way
- I think this is a problem for ALL the alternatives, not just this one.
ALT3 - From a client perspective, this looks just like ALT2. The client does
a lookup that obtains a read lock while release does the unlock.
Since the Singleton thing makes no sense to me anyway, I'd say use ALT2.
Ralph, what about when you want to hotswap your singleton to a new version?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] RepositorySource

[Stephan Michels]

Am Do, den 08.04.2004 schrieb Guido Casper um 20:18:
> Stephan Michels wrote:
> > What the status of the WebDAVSource? It seems that it doesn't implement
> > any versioning. Or am I wrong?
> 
> No. I (vaguely) remember some discussion considering your 
> VersionableSource vs. Sylvain's VersionedSource from:
> http://www.cocoondev.org/projects/cvssource.html
> 
> However ...
> 
> > 
> > Do you have plan to do something in this direction?
> 
> I like the fact that WebDAV makes versions available via seperate URIs. 
> So there is no need (and no value IMO) to have things like 
> get/setVersion() since there is no way to anticipate the versioning 
> scheme (i.e. what's the name of the previous version?). All you need is 
> a way to get at an ordered list of versions which might as well be 
> complete version URIs.

Do you have an example to get older versions via URI?

> I wonder if it's a good idea to expand this concept to the Repository 
> interface so any implementation can make up its own or find a common URI 
> scheme that includes versioning/branching/etc. information. It is quite 
> easy for an application to manage things like "versioning state" on its 
> own and the Repository stays more generic.

Okay, what do you use as client? The WebDAV client of Slide? Is it good
enough?

> getVersions() (and maybe getBranches()) objectively has to be extended 
> to manage branches.
> 
> WDYT about that?

Yes, I think you're right. It only feels a little odd to bypass the
Source IF.

Stephan Michels.

Documentation TOC started

[H . vanderLinden]

Guys (and girls),

I want to structure all the documentation about Cocoon in the Wiki and the
xdocs. I've started small by setting up a Wiki page
http://wiki.cocoondev.org/Wiki.jsp?page=Cocoon215TOC which should become a
Table of Contents into documentation geared to Cocoon 2.1.5 and future
versions.
At first I want to fill this page with links to existing Wiki and xdoc
pages, after that missing pages should be added and outdated pages updated
or rewritten.

The first draft of this TOC is far from complete, so I'd like you all to
take a quick look at the wiki page and add missing items and sections.

Thanks.

Bye, Helma

Re: [Kernel22] How to develop a component?

[Leo Simons]

Leo Sutic wrote:
No, it doesn't. (Tell it to the person you quoted, though.)
isn't this a group discussion? :-D. Point taken though.

ALT1: Wires are severed immediately, the component is reloaded.
can only do that on a coarse component level, otherwise its unmanageable.

ALT2: Wires are left intact and the new component is loaded in parallell
with the existing component.
>
Disadvantages: A bit of a problem if the component was supposed to be
a singleton
use a barrier :-D

ALT3: Slap a read-write lock on every wire.

Disadvantages: Deadlocks
use a barrier :-D

on an OS level, I think a lot of these things were thought about for a 
long time, then solved, many years ago, even for large scale distributed 
OSes. Not really my field though; too much pointer arithmic. From 
memory, doing it reliably basically always goes something like

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
   2) kill A (if it doesn't respond)
   3) start B
   4) update reference
6) resume A and all processes referencing A
again, from memory, the real tough part is the barrier that's in place 
around the reference. With java, barriers are way easier (because of 
synchronization being available), but very expensive too.

If you want a hotswapping kernel, you probably want to look into 
hotswapping kernels. Mach (now darwin) is a textbook example I think.

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue  -- http://jicarilla.org/
---
"We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules."
-- Alan Bennett

Re: [RT] RepositorySource

[Guido Casper]

Stephan Michels wrote:
Am Do, den 08.04.2004 schrieb Guido Casper um 17:08:

Rolf Kulemann wrote:

Looking at the repository block, one will see that there is already a
RepositorySource, but that source and the RepositorySourceFactory are
not meant to be used with the new Repository interface from Guido.
What I have in mind is:

A new RepositorySourceFactory should simply look up the appropriate
respositroy via the RepositoryManager and pass that to RepsitorySource.
The source than acts on the Repository interface to provide a sources
functionality.
Does this make sense?
It does.
However please consider the Repository interface unstable (if not at 
"proposal stage", but definately not finished) and I currently wouldn't 
move too quick building further components on top of it.

If you need a Source for accessing WebDAV, why not use the WebDAVSource?


What the status of the WebDAVSource? It seems that it doesn't implement
any versioning. Or am I wrong?
No. I (vaguely) remember some discussion considering your 
VersionableSource vs. Sylvain's VersionedSource from:
http://www.cocoondev.org/projects/cvssource.html

However ...

Do you have plan to do something in this direction?
I like the fact that WebDAV makes versions available via seperate URIs. 
So there is no need (and no value IMO) to have things like 
get/setVersion() since there is no way to anticipate the versioning 
scheme (i.e. what's the name of the previous version?). All you need is 
a way to get at an ordered list of versions which might as well be 
complete version URIs.

I wonder if it's a good idea to expand this concept to the Repository 
interface so any implementation can make up its own or find a common URI 
scheme that includes versioning/branching/etc. information. It is quite 
easy for an application to manage things like "versioning state" on its 
own and the Repository stays more generic.

getVersions() (and maybe getBranches()) objectively has to be extended 
to manage branches.

WDYT about that?

I currently think about to implement a system ontop of it.
Cool.

Guido

Stephan Michels.


--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> -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: RepsitoryPropertyHelper.getProperty(depth)?

[Guido Casper]

Rolf Kulemann wrote:
On Thu, 2004-04-08 at 18:26, Rolf Kulemann wrote:

Hello,

using WebDAV it is possible to make a methodPropfind(dept) which is
useful i.e. with depth=1 to show the content of a collection.
Would it make sense to extend the PropertyHelper with an appropriate
function?
I dunno all "other" repositories having such a feature, but I know
jcr-170 has similiar methods like getNodes(depth), which is returning
nodes and sub nodes without properties, but getProperty(depth) can also
be implemented on top of getNodes(depth).


BTW: How should it be possible to receive lets say "all child nodes" of
a collection/node using the repository interface? Or is it a concern of
a RepositorySource? 
No, some mechanism to retrieve collection members (getChildren() or 
getMembers()) would be a welcome addition to the Repository interface IMO.

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

RE: [Kernel22] How to develop a component?

[Ralph Goers]

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?
Not only for the reasons you mentioned, but because presumably the singleton
is managing stuff that is supposed to be permanently available.  In this
case your singleton is no longer a singleton.  Frankly, I'd suggest that
classes meant to be singletons should implement a Singleton (or NonSwappable
or whatever) interface to prevent them from ever being reloaded.  By the way
- I think this is a problem for ALL the alternatives, not just this one.

ALT3 - From a client perspective, this looks just like ALT2. The client does
a lookup that obtains a read lock while release does the unlock.

Since the Singleton thing makes no sense to me anyway, I'd say use ALT2.

Ralph

-Original Message-
From: Leo Sutic [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 08, 2004 10:29 AM
To: [EMAIL PROTECTED]
Subject: RE: [Kernel22] How to develop a component?


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

DO NOT REPLY [Bug 28276] - FileGenerator blocks xml-files, does not close them properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28276

FileGenerator blocks xml-files, does not close them properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-08 17:44 ---
I've tested this somewhat further and there doesn't seem to be a real big problem.

I've wrapped the inputstream to log the close calls and they are properly called
(by the parser, xerces). This is also the case if the XML file contains an error
and thus a parse exception is thrown. I've checked the xerces source and this is
done properly in a try/finally block.

The only case in which the inputstream could be left open is if an error occurs
between the moment the inputstream is opened and the parser is called, but this
is an unlikely situation, and I'm quite sure this is not the case here otherwise
you would have seen this error.

The problem is probably caused by something else, i.e. your editor, windows, or
whatever. In Linux there's this utility called fuser that can show who's using a
file -- don't know if there's a Windows equivalent.

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> 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: [RT] RepositorySource

[Rolf Kulemann]

On Thu, 2004-04-08 at 18:46, Stephan Michels wrote:
> Am Do, den 08.04.2004 schrieb Guido Casper um 17:08:
> > Rolf Kulemann wrote:
> > > Looking at the repository block, one will see that there is already a
> > > RepositorySource, but that source and the RepositorySourceFactory are
> > > not meant to be used with the new Repository interface from Guido.
> > > 
> > > What I have in mind is:
> > > 
> > > A new RepositorySourceFactory should simply look up the appropriate
> > > respositroy via the RepositoryManager and pass that to RepsitorySource.
> > > The source than acts on the Repository interface to provide a sources
> > > functionality.
> > > 
> > > Does this make sense?
> > 
> > It does.
> > However please consider the Repository interface unstable (if not at 
> > "proposal stage", but definately not finished) and I currently wouldn't 
> > move too quick building further components on top of it.
> > 
> > If you need a Source for accessing WebDAV, why not use the WebDAVSource?
> 
> What the status of the WebDAVSource? It seems that it doesn't implement
> any versioning. Or am I wrong?
> 
> Do you have plan to do something in this direction?

I do not plan to use the WebDAVSource at all. At the mom I use WebDAV
versioning via the Repository and its VersioningHelper.
See the WebDAV block and the WebDAVRepsitory.getVersioningHelper.

But the repository stuff is lacking other things than versioning i.e. I
can not retrieve a collection of nodes i.e. in a iterator.

-- 
Regards,

Rolf Kulemann

Re: disabling widgets

[Tim Larson]

On Thu, Apr 08, 2004 at 07:55:44AM -0400, Vadim Gritsenko wrote:
> Tim Larson wrote:
> >We need to be able to specify the hidden state and the
> >selection of {both|output|input|neither} both statically in
> 
> +1
> 
> >the widget definitions and dynamically via flowscript, Java,
> >binding, and event handling, but not via the view, of course.
> 
> I don't see a necessity to provide so much flexibility.

Ok, maybe not all of it yet, but I do have a use case right
now for being able to dynamically switch between the normal
"both" mode and "output"-only mode.  In the Form Model GUI
I want to default to showing the widget definitions with an
easy-on-the-eyes read-only summary, and for each widget
definition have a button/checkbox/tab/whatever to switch
just the selected widget definition(s) to collections of
editable input widgets like the sample has now.

We could solve this several ways:
* Make the both|output|etc. setting dynamically settable as
  suggested above.
* Introduce "alias" widgets to hold configuration, while
  referencing other widgets for the data, and then wrap
  alternate "both" and "output" alias widgets in a "choice"
  widget to control what is sent to the view layer.
* (Hacky) Have the view layer contain a hidden input for
  these output widgets so that readFromRequest does not
  reset these output-styled field widgets to null.
* (Non-portable, but sometimes a good option) Only use
  client-side tools (js/xul/etc.) to switch between modes.

WDYT
--Tim Larson

Re: [RT] RepositorySource

[Stephan Michels]

Am Do, den 08.04.2004 schrieb Guido Casper um 17:08:
> Rolf Kulemann wrote:
> > Looking at the repository block, one will see that there is already a
> > RepositorySource, but that source and the RepositorySourceFactory are
> > not meant to be used with the new Repository interface from Guido.
> > 
> > What I have in mind is:
> > 
> > A new RepositorySourceFactory should simply look up the appropriate
> > respositroy via the RepositoryManager and pass that to RepsitorySource.
> > The source than acts on the Repository interface to provide a sources
> > functionality.
> > 
> > Does this make sense?
> 
> It does.
> However please consider the Repository interface unstable (if not at 
> "proposal stage", but definately not finished) and I currently wouldn't 
> move too quick building further components on top of it.
> 
> If you need a Source for accessing WebDAV, why not use the WebDAVSource?

What the status of the WebDAVSource? It seems that it doesn't implement
any versioning. Or am I wrong?

Do you have plan to do something in this direction?

I currently think about to implement a system ontop of it.

Stephan Michels.

Re: RepsitoryPropertyHelper.getProperty(depth)?

[Rolf Kulemann]

On Thu, 2004-04-08 at 18:26, Rolf Kulemann wrote:
> Hello,
> 
> using WebDAV it is possible to make a methodPropfind(dept) which is
> useful i.e. with depth=1 to show the content of a collection.
> 
> Would it make sense to extend the PropertyHelper with an appropriate
> function?
> 
> I dunno all "other" repositories having such a feature, but I know
> jcr-170 has similiar methods like getNodes(depth), which is returning
> nodes and sub nodes without properties, but getProperty(depth) can also
> be implemented on top of getNodes(depth).
> 

BTW: How should it be possible to receive lets say "all child nodes" of
a collection/node using the repository interface? Or is it a concern of
a RepositorySource? 

-- 
Regards,

Rolf Kulemann

RepsitoryPropertyHelper.getProperty(depth)?

[Rolf Kulemann]

Hello,

using WebDAV it is possible to make a methodPropfind(dept) which is
useful i.e. with depth=1 to show the content of a collection.

Would it make sense to extend the PropertyHelper with an appropriate
function?

I dunno all "other" repositories having such a feature, but I know
jcr-170 has similiar methods like getNodes(depth), which is returning
nodes and sub nodes without properties, but getProperty(depth) can also
be implemented on top of getNodes(depth).

I'm quite new to WebDAV and jcr so I may have mixed things.


WDYT?

-- 
Regards,

Rolf Kulemann

Re: [RT] RepositorySource

[Rolf Kulemann]

On Thu, 2004-04-08 at 17:08, Guido Casper wrote:
> Rolf Kulemann wrote:
> > Looking at the repository block, one will see that there is already a
> > RepositorySource, but that source and the RepositorySourceFactory are
> > not meant to be used with the new Repository interface from Guido.
> > 
> > What I have in mind is:
> > 
> > A new RepositorySourceFactory should simply look up the appropriate
> > respositroy via the RepositoryManager and pass that to RepsitorySource.
> > The source than acts on the Repository interface to provide a sources
> > functionality.
> > 
> > Does this make sense?
> 
> It does.
> However please consider the Repository interface unstable (if not at 
> "proposal stage", but definately not finished) and I currently wouldn't 
> move too quick building further components on top of it.

I agree that the rep. interface is "unstable" BUT adding another layer,
more concrete a source impl., will not cause much overhead, since it is
"a single" point of change. 

> 
> If you need a Source for accessing WebDAV, why not use the WebDAVSource?

My App does not know WebDAV and should not. Of course using the webdav
source is an option, but I thought as soon as we have alpha code seeds
for the Respository more people will look at it and maybe enhance and/or
contribute (to) it.

I think I can cope with using the WebDAVSource, but it is not really
satisfactory for me. I'm looking forward to a (new) repository s
looong.

I just did a skeleton for the source and factory. It is not much code,
so that is why I can follow ur concerns, but can not agree with being
"that careful".

Is there really no space for hacking concerning the repsitory???

Using the WebDAV source means for me binding my sitemap to WebDAV. That
could be changed easy in the future I think, so if there is no space for
good old hacking, I will go that way.


Another question:

When do sources go into scratchpad? If they are unstable or "proposed"?
If so, wouldn't that mean the repository should go to scratchpad?

I also could add my source to the scratchpad.
WDYT?

-- 
Regards,

Rolf Kulemann

Re: [Kernel22] How to develop a component?

[Leo Simons]

Leo Sutic wrote:
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>>
write a failing testcase that doens't require me to understand every 
little detail of cocoon internals and I could try.
Easy.


made that into an actual testcase :-D:

public abstract class ReloadingProxyTestCase extends TestCase
{
  ServiceManager manager;
  ProxyInvalidator invalidator;
  Client client;
  public void setUp() throws Exception
  {
super.setUp();
manager = getManager();
invalidator = getInvalidator();
client = getClient();
  }
  protected abstract ServiceManager getManager();
  protected abstract ProxyInvalidator getInvalidator();
  protected abstract Client getClient();
  public void testCacheInvalidationDoesntWork()
  {
client.login();
invalidator.invalidate();
try
{
  client.attemptOperation();
}
catch( InvalidatedReferenceException ire )
{
  fail( "client doesn't catch InvalidatedReferenceException!" );
}
  }
  public 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.
  }
  public class AvalonStatefulComponent
  extends AbstractLogEnabled,
  implements Serviceable, StatefulComponent
  {
public void login () {}
public void doOperation () {}
public void logout () {}
  }
  public interface Client
  {
public void attemptLogin();
public void attemptOperation();
  }
  public class OldStyleClient implements Serviceable, Client
  {
private StatefulComponent comp;
public void service( ServiceManager sm )
{
  comp = (StatefulComponent)
sm.lookup(StatefulComponent.ROLE);
}
public void attemptLogin()
{
  comp.login();
}
public void attemptOperation()
{
  comp.doOperation();
}
  }
}
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. I'll try to withhold most 
of my opinion as to how smart a design like this is in the interest of 
keeping the discussion on-topic ;)

If you provide a component that has this kind of behaviour to an 
avalon-framework-compatible component through that component its 
servicemanager, it will not catch the InvalidatedReferenceException and 
it will lead to unexpected results. Acked.

> Of course there are ways to code around this (or ignore it) in
> the vast majority of cases.
Yep. Nothing to do with avalon-framework, though. I would say you'd have 
to mark components up with

  /** @@SupportsInvalidationOfReferences() */

and have the container print a big fat warning if the tag is missing but 
the ServiceManager (or anything which can lead to a reference that can 
be invalidatied) being provided to the component contains components 
that may invalidate.

Agreed, its not very clean.

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."

your test case shows that there is no easy or elegant way you can pass a 
new style cocoon block into an old-style avalon component. Which will of 
course be true for the majority of code in this world, because the 
majority of software doesn't check for the not-yet-existant 
InvalidatedReferenceException. You have major headache to deal with 
there anyway, regardless of whether you have an avalon component or a 
javabean or an EJB.

But the test case doesn't show that there is no easy or elegant way to 
pass an old style avalon component into a new style cocoon block. After 
all, the block is not going to be disfunctional if the reference to the 
avalon component *doesn't invalidate*.

You could write a testcase for that. The testcase would be saying "all 
code inside cocoon must be prepared for references to anything to 
invalidate at any point in time". Ugh.

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.

I can't see how it is relevant whether a reference is obtained through 
the avalon ServiceManager or through any other means.

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue  -- http://jicarilla.org/
---
"We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules."

Re: [RT] RepositorySource

[Gianugo Rabellino]

Guido Casper wrote:

Rolf Kulemann wrote:

Looking at the repository block, one will see that there is already a
RepositorySource, but that source and the RepositorySourceFactory are
not meant to be used with the new Repository interface from Guido.
What I have in mind is:

A new RepositorySourceFactory should simply look up the appropriate
respositroy via the RepositoryManager and pass that to RepsitorySource.
The source than acts on the Repository interface to provide a sources
functionality.
Does this make sense?


It does.
However please consider the Repository interface unstable (if not at 
"proposal stage", but definately not finished) and I currently wouldn't 
move too quick building further components on top of it.
+1. Let's stabilize the whole Repository concept once and for all before 
starting to add layers on top of it.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)

Re: [RT] RepositorySource

[Guido Casper]

Rolf Kulemann wrote:
Looking at the repository block, one will see that there is already a
RepositorySource, but that source and the RepositorySourceFactory are
not meant to be used with the new Repository interface from Guido.
What I have in mind is:

A new RepositorySourceFactory should simply look up the appropriate
respositroy via the RepositoryManager and pass that to RepsitorySource.
The source than acts on the Repository interface to provide a sources
functionality.
Does this make sense?
It does.
However please consider the Repository interface unstable (if not at 
"proposal stage", but definately not finished) and I currently wouldn't 
move too quick building further components on top of it.

If you need a Source for accessing WebDAV, why not use the WebDAVSource?

Guido

Guido?

On Thu, 2004-04-08 at 15:59, Rolf Kulemann wrote:

Hello,

I currently test and play around with the Repository block.
I guess a RepositorySource would be useful at least for my personal
needs.
I'm going do some coding on it and wonder what involved Cocooner's think
about it.
Since it is possible to configure different "backends" being used
through the repository interface it would make sense to me to access
such a source like:
{repository:backend/path}

where backend is a name configured for a particular repository impl.
i.e.
- mywebdav as a name for webdav backend
- myslide 
Any ideas on this?

RE: [Kernel22] How to develop a component?

[Ralph Goers]

Sorry, but this cannot work.  Calling comp.ensureWired() accomplishes
nothing because the component could be dropped between completion of that
call and the next.

This whole idea will create the ugliest client code you have ever seen,
because each and every operation could fail, in which case you will have to
start over again from the beginning, or fail the whole thing (and probably
make somebody else retry the whole thing).  

I'm with Sylvain on this one. Don't get rid of the block until it is
released.

Ralph

-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 08, 2004 7:38 AM
To: [EMAIL PROTECTED]
Subject: RE: [Kernel22] How to develop a component?


Believe me, I'm really just curious. Would the new code be the same
or just similar? Of course the lookup is different as a different
method is used. From what I understood the code would look like
this:

StatefulComponent comp =
(StatefulComponent)wire.lookup(StatefulComponent.class, SOMEHINT);
try {
comp.login ();
// (1)
comp.doOperation ();
comp.logout ();
} finally {
wire.release (comp);
}

> 
> 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).
So, would I do a comp.ensureWired() before each call to the component?

> 
> ***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.
> 
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. 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!

Carsten

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> > 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?

[Carsten Ziegeler]

Leo Sutic wrote: 
> 
> > 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.
> 
Okay, I see - so as long as I don't reload a block, it's pretty
much the same.

Thanks, Leo!

Carsten

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> 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?

[Carsten Ziegeler]

Leo Sutic wrote:
> 
> > -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.

Believe me, I'm really just curious. Would the new code be the same
or just similar? Of course the lookup is different as a different
method is used. From what I understood the code would look like
this:

StatefulComponent comp =
(StatefulComponent)wire.lookup(StatefulComponent.class, SOMEHINT);
try {
comp.login ();
// (1)
comp.doOperation ();
comp.logout ();
} finally {
wire.release (comp);
}

> 
> 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).
So, would I do a comp.ensureWired() before each call to the component?

> 
> ***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.
> 
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. 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!

Carsten

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> -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?

[Sylvain Wallez]

Leo Sutic wrote:

 

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.
 

A way to solve this problem is by deferring the actual swapping until 
the component is released.
See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108033164725441&w=2 
where I discussed this.

Of course, there should be a means to force component swap (either 
manually or automatically) in case a release has been forgotten.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

RE: [Kernel22] How to develop a component?

[Carsten Ziegeler]

> 
> > 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?

Carsten

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> 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: [RT] RepositorySource

[Rolf Kulemann]

Looking at the repository block, one will see that there is already a
RepositorySource, but that source and the RepositorySourceFactory are
not meant to be used with the new Repository interface from Guido.

What I have in mind is:

A new RepositorySourceFactory should simply look up the appropriate
respositroy via the RepositoryManager and pass that to RepsitorySource.
The source than acts on the Repository interface to provide a sources
functionality.

Does this make sense?

Guido?


On Thu, 2004-04-08 at 15:59, Rolf Kulemann wrote:
> Hello,
> 
> I currently test and play around with the Repository block.
> I guess a RepositorySource would be useful at least for my personal
> needs.
> 
> I'm going do some coding on it and wonder what involved Cocooner's think
> about it.
> 
> Since it is possible to configure different "backends" being used
> through the repository interface it would make sense to me to access
> such a source like:
> 
> {repository:backend/path}
> 
> where backend is a name configured for a particular repository impl.
> i.e.
> - mywebdav as a name for webdav backend
> - myslide 
> 
> Any ideas on this?
-- 
Regards,

Rolf Kulemann

RE: [Kernel22] How to develop a component?

[Carsten Ziegeler]

Leo Sutic wrote:
> 
> 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.
> 
How does the working code look like? 

Carsten

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> 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: [RT] RepositorySource

[Rolf Kulemann]

On Thu, 2004-04-08 at 15:59, Rolf Kulemann wrote:
> Hello,
> 
> I currently test and play around with the Repository block.
> I guess a RepositorySource would be useful at least for my personal
> needs.
> 
> I'm going do some coding on it and wonder what involved Cocooner's think
> about it.
> 
> Since it is possible to configure different "backends" being used
> through the repository interface it would make sense to me to access
> such a source like:
> 
> {repository:backend/path}
> 
> where backend is a name configured for a particular repository impl.
> i.e.
> - mywebdav as a name for webdav backend
> - myslide 
> 
> Any ideas on this?

Maybe we also need to encode user name and credentials like
{repository:user:[EMAIL PROTECTED]/path}

???

-- 
Regards,

Rolf Kulemann

Re: [Kernel22] How to develop a component?

[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.

I just totally fail to see what restrictions you think are intrinsic to 
avalon-framework-compatible components for preventing container feature 
X or feature Y from working.

I understand the decision to move away from /depending/ on o.a.avalon.* 
based on stuff like community dynamics, but I totally fail to understand 
is the technical part of the rationale that, comes after that decision, 
that says backwards (and forward, in fact) /compatibility/ is not 
possible or not possible cleanly.

You're taking a rather firm stance without having code in place that 
proves your point. I can imagine people "freaking out" at big 
architectural change for a reason that is not understood and may not 
even exist.

Is this clear enough?
nope :-D

if not, I'm glad to keep answering questions.
- What problem are you solving that can't be solved if a component 
requires (for example) that the container honours the Servicable contract?

- Why not?

- Have you actually tried it?

- Where did it fail?

Apologies for jumping onto this topic like this, but I've just spent 
half a year exploring solutions to these kinds of things and so far I 
just haven't encountered any fundamental issue which you seem to be 
fearing exists. When you say "not elegantly possible" people believe it 
and that may be a bad thing if you're wrong ;)

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue  -- http://jicarilla.org/
---
"We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules."
-- Alan Bennett

[RT] RepositorySource

[Rolf Kulemann]

Hello,

I currently test and play around with the Repository block.
I guess a RepositorySource would be useful at least for my personal
needs.

I'm going do some coding on it and wonder what involved Cocooner's think
about it.

Since it is possible to configure different "backends" being used
through the repository interface it would make sense to me to access
such a source like:

{repository:backend/path}

where backend is a name configured for a particular repository impl.
i.e.
- mywebdav as a name for webdav backend
- myslide 

Any ideas on this?

-- 
Regards,

Rolf Kulemann

RE: [Kernel22] How to develop a component?

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
> I want to create a migration path away from avalon.
> 
> I propose to have a sandbox so that people know that somehow 
> they should be thinking about migration. It's sort of a 
> framework deprecation signal.
> 
> The idea is that we'll start with a sandbox, then people 
> realize that blocks give them better functionality, so they 
> make an effort to pay the "migration cost" because of the 
> additional functionality.
> 
> This will take a while, potentially years, and after that 
> period, we can remove the sandbox, unlocking ourselves from avalon.
> 
> On the other hand, Carsten, what you are proposing locks us 
> forever connected to a particular years-old version of avalon 
> that might be soon deprecated by its own project.
> 
No, no, perhaps my explanations are not good - I don't know.

All I'm still trying to say is, that I would like support for
the avalon lifecycle interfaces. So, precisly, I want to have
support for:
LogEnabled, Contextualizable, Configurable, Parameterizable,
Serviceable, Intializable, Startable, Disposable, ThreadSafe
and Poolable. Nothing more.

I'm not against defining new interfaces - as long as we still
support the old ones. And I'm not against in loosing *some*
functionality if I'm using those interfaces from above.
Most of them are simple to support. The only one might be 
Serviceable.

> Would the need to modify/update avalon framework emerge, we 
> would be required to change it, this will create a fork.
> 
There is no need to modify/update the avalon framework. We can
do our own thing but just support the old interfaces listed
above.

So, I just want some kind of "legacy support".

Carsten

RE: [Kernel22] How to develop a component?

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
> Bertrand Delacretaz wrote:
> 
> > Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :
> > 
> >> ...Exactly my point :) But the current idea of blocks is to only 
> >> retain this possibility inside a sandbox which means it 
> can't be used "inside"
> >> blocks. So if I develop my app as a block, I can't use these 
> >> components inside my app!...
> > 
> > 
> > I thought the idea was to provide an ECM-like sandbox 
> *inside* a block 
> > (reading Stefano's last message on this thread), in which 
> case you can 
> > use your Avalon components inside a Cocoon block, but they 
> cannot be 
> > made available to other blocks.
> > 
> > But I might be wrong..
> 
> Bertrand is right and Carsten is freaking out for no reason.
Oh, if you think that I'm "freaking out" than you never really saw
me freaking out - believe me!

> 
> Carsten, please, breath and read what I write.
> 
> You don't have hotdeployment today so you won't be missing it 
> for sure in your avalon sandbox, would you?
Yepp.

> 
> 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.

Ok, so here is the different understanding. My understanding
was that the avalon sandbox is *one big block* and not a
sandbox I can run blocks in. Sorry that I misunderstood the
previous explanations.

So, if this is true, we *could* go this way. Although I and 
some others here still don't see any technical problems. But
time will tell of course.

> 
> 
> --
> Stefano, wishing people didn't think that innovation always 
> means breaking stuff.
> 

Carsten - trying to keep the discussion technical.

RE: [Kernel22] How to develop a component?

[Leo Sutic]

> 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?

[Stefano Mazzocchi]

Nicola Ken Barozzi wrote:

Leo Simons wrote:
...
avalon-framework very rarely doesn't get built by gump. It's the ECM 
dependency that's causing the ripples, and the big set of dependencies 
ECM has itself.

Since it seems ECM is being put into the freezer anyway, just be 
pragmatic and make the gump build of cocoon depend on an installed 
package or some jars in cvs. It's not like ECM has changed a lot over 
the last 2 years.


Good suggestion as an interim solution. +1
I have no problems in making the avalon sandbox of the cocoon kernel 
depend on frozen versions of Avalon Framework and Avalon ECM that didn't 
change in the last two years.

As long as we agree *never to change it*.

If Leo's are right, it is also possible to make avalon components be 
exposed "outside" the avalon sandbox without loss of functionality.

I don't see how, but I love to be proven wrong.

But I sand firmly on my position:

 +1 on having an avalon sandbox
 -1 on having the core of the cocoon kernel depend on avalon directly
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 28279] - [PATCH] Logging all requests

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28279

[PATCH] Logging all requests





--- Additional Comments From [EMAIL PROTECTED]  2004-04-08 13:22 ---
Created an attachment (id=11183)
Allows all requests to be logged via an Avalon Component

DO NOT REPLY [Bug 28279] New: - [PATCH] Logging all requests

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28279

[PATCH] Logging all requests

   Summary: [PATCH] Logging all requests
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,

I've created a patch that will allow Coocon to log all requests, before they are
serviced.

With the patch, I think you'll need to do a "patch -p1" from with the coocon-2.1
cvs dir.

To use the new component, add a line similar to the following in your
cocoon.xconf:



Also, there are comments in the RequestLogger interface that explain how
to use it (a bit).


(This was originally posted to the cocoon dev mailing list:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108135682300075&w=2)

Surj

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Steven Noels wrote:

On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:

The issue is not so technical as it's of indipendence from something 
that, in the good and the bad, has not helped Cocoon be built by Gump 
for ages now.


As much as I like "Gumpinal Correctness" for the sanity of us Cocoon 
committers, I'm not sure whether Gump has the goal of driving 
architectural decisions for the projects it is aggregating information 
from. It is a helper tool and should not decide for us, no?
Gump doesn't give us solutions, it points us to the problems.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Carsten Ziegeler wrote:

Nicola Ken Barozzi wrote:

The issue is not so technical as it's of indipendence from 
something that, in the good and the bad, has not helped 
Cocoon be built by Gump for ages now.

As I said, we would only have a reference to avalon framework
version x.y.z - a fixed version so there shouldn't be any problem
with gump because of that.
What if we need to change it?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Bertrand Delacretaz wrote:

Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :

...Exactly my point :) But the current idea of blocks is to only retain
this possibility inside a sandbox which means it can't be used "inside"
blocks. So if I develop my app as a block, I can't use these components
inside my app!...


I thought the idea was to provide an ECM-like sandbox *inside* a block 
(reading Stefano's last message on this thread), in which case you can 
use your Avalon components inside a Cocoon block, but they cannot be 
made available to other blocks.

But I might be wrong..
Bertrand is right and Carsten is freaking out for no reason.

Carsten, please, breath and read what I write.

You don't have hotdeployment today so you won't be missing it for sure 
in your avalon sandbox, would you?

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!]

So, in short:

 1) if you have avalon components exposted thru cocoon blocks, these 
blocks need to run in the avalon sandbox and they cannot be runtime 
polymorphic because of the nature of avalon. This means that in order to 
upload/change a block you need to restart the container. If we pass 
around these components outside the sandbox, we force all blocks that 
depend on this to be hardwired, loosing, in fact, the soft-wireness.

 2) for cocoon components exposted thru cocoon blocks, this is not the 
case.

Socially, I expect the values of 2) to drive the migration effort away 
from 1).

This means:

if you avalon components exposed to your cocoon block, these components 
will be loaded in an avalon sandbox *and* all the cocoon blocks (even 
those outside the sandbox) that depend on this will not be hotswappable.

Even more explicitly:

you are NOT loosing any functionality!! since hotswappability is not 
something you had before.

Is this clear enough? if not, I'm glad to keep answering questions.

--
Stefano, wishing people didn't think that innovation always means 
breaking stuff.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Kernel22] How to develop a component?

[Steven Noels]

On 08 Apr 2004, at 14:50, Stefano Mazzocchi wrote:

At the same time, to put it rather explicitly: I don't want anything 
in org.apache.avalon.* to be a core dependency of org.apache.cocoon.* 
anymore because I don't trust avalon anymore: avalon is quicksand and 
you can't expect it to be there tomorrow in the same shape you want it 
to be.
I think many people agree on the fact that we shouldn't depend on the 
Avalon products/containers anymore for Cocoon core operations. Some 
would like compatibility to run existing components as-is, which seems 
not trivial and shouldn't slow down the innovation train. OTOH, we 
cannot simply throw the good ideas behind Avalon's lifecycle management 
and container services away just because their method signatures carry 
the org.apache.avalon name, no?


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

I want to create a migration path away from avalon.

I propose to have a sandbox so that people know that somehow they should 
be thinking about migration. It's sort of a framework deprecation signal.

The idea is that we'll start with a sandbox, then people realize that 
blocks give them better functionality, so they make an effort to pay the 
"migration cost" because of the additional functionality.

This will take a while, potentially years, and after that period, we can 
remove the sandbox, unlocking ourselves from avalon.

On the other hand, Carsten, what you are proposing locks us forever 
connected to a particular years-old version of avalon that might be soon 
deprecated by its own project.

Would the need to modify/update avalon framework emerge, we would be 
required to change it, this will create a fork.

I remain against having the core of the cocoon kernel depend on anything 
in the org.apache.avalon.* namespace: it might save us problems in the 
present, but open a can of worms in the future.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Reinhard Pötz wrote:

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.
Are there reasons that prevent me from writting a 'block wrapper' which 
can be exposed?
good question... I don't know :-)

Look: at the very end, I have no problems in having all sorts of 
machinery to have avalon components run AS IS in cocoon 2.2. I believe 
it to be a monumental PITA to do correctly, given the avalon 4.x way of 
doing stuff (keep in mind that avalon is older than cocoon and was 
designed on a java 1.1 JVM, in some senses is archaic), but I would love 
to be proven wrong.

At the same time, to put it rather explicitly: I don't want anything in 
org.apache.avalon.* to be a core dependency of org.apache.cocoon.* 
anymore because I don't trust avalon anymore: avalon is quicksand and 
you can't expect it to be there tomorrow in the same shape you want it 
to be.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: disabling widgets

[Vadim Gritsenko]

Tim Larson wrote:

We need to be able to specify the hidden state and the
selection of {both|output|input|neither} both statically in
 

+1


the widget definitions and dynamically via flowscript, Java,
binding, and event handling, but not via the view, of course.
 

I don't see a necessity to provide so much flexibility.

Vadim

Re: [Kernel22] How to develop a component?

[Vadim Gritsenko]

Sylvain Wallez wrote:

Steven Noels wrote:

On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:

Steven Noels wrote:

On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:

The issue is not so technical as it's of indipendence from 
something that, in the good and the bad, has not helped Cocoon be 
built by Gump for ages now.


As much as I like "Gumpinal Correctness" for the sanity of us 
Cocoon committers, I'm not sure whether Gump has the goal of 
driving architectural decisions for the projects it is aggregating 
information from. It is a helper tool and should not decide for us, 
no?


Gump is deciding for us? Did I read "Gump wrote?" :-P

The fact is that a tool tells me that a project we depend upon does 
not get built regularly: this *does* impact on architectural decisions.


The reason of Excalibur not building might perhaps be because of its 
developers not caring enough about providing a strong contract to its 
users. We have an established codeset and user base which have 
habitually been adopting and using the Avalon *APIs* (I'm not 
referring to a particular container here) because of (a) they found 
out about them inside Cocoon, and were encouraged to use them for 
their own Cocoon components, and (b) maybe they even started to 
actually like them, and thus might expect us to provide identical 
services and interfaces in our own container - backed by a healthier 
community.


A big +1 here, also seconding Carsten. The Avalon *API* has led many 
people to COP, as this *API* provides simple means for a component to 
interact with its container. Sure, IOC type 2/3 make it more 
transparent, but IMO don't scale for large sets of components.

So although Cocoon will have a new container, it should not consider 
Avalon APIs as just a bunch of legacy interfaces that have to run in a 
sandbox. It's a slap in the face of many people that have invested 
time to build their application-logic components on top of an enabling 
infrastructure that was seamlessly integrated with Cocoon but could be 
used in other kind of apps, therefore allowing actual 
cross-application reuse of these components. Without this support, 
people are left alone without architectural guidance, and this will be 
a step back leading to unisolated spaghetti code.

So we can trash the ECM, we can change the configuration file format, 
but we *must* support (and not only as a legacy isolated sandbox) the 
Avalon framework APIs (a bunch of 1-method interfaces).

Cross-block classloading problems isn't an issue IMO, as it seems to 
me fairly easy to use dynamic proxies to translate calls to an 
interface to calls to the same interface in a different classloader.

My 1 euro. Yeah, a lot more than Steven ;-)


Add some USD to this. I'd like Cocoon to support Avalon Framework API 
also. I don't understand why Avalon components could not be wired to be 
exposed by block.

Vadim

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Bertrand Delacretaz]

Le 8 avr. 04, à 12:22, Sylvain Wallez a écrit :

Stefano Mazzocchi wrote:

[EMAIL PROTECTED] wrote:

antonio 2004/04/05 05:25:36

  Log:
  removing encoding="ISO-8859-1"


Why?


Yes, why? UTF-8 is the XML default, but very few general purpose 
editors (i.e. non-XML editors) handle it correctly. So I'm wondering 
the value of this change : can't every dict file use the encoding 
that's most suited for its target language.
I agree with Sylvain, IMHO this clearly falls into the "if it ain't 
broke don't fix it" category of changes.

Also, it's fairly hard to check that the change of encoding 
declaration, and the related binary changes to adapt the files to the 
new encoding, have not caused any subtle problems.

Antonio, did you test all the impacted components after making your 
encoding changes? Do they work as before?

We've had problems with encodings, CVS and editors not handling all 
this properly before
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19619), so we must 
be careful when making such changes. And not make them without a good 
reason IMHO.

...Also, how does CVS handle UTF-8 files? I mean what happens if a 
byte in a 2-bytes character is  a "\n"? When checked out on Window, 
does it become "\r\n"? This can lead to very weird questions...
Yes. Hopefully, setting the "-kb" binary flag on these files avoids the 
problem, but we might then encounter the whitespace/extra end-of-lines 
problems again.

-Bertrand

is databasereader's bug?

[roy huang]

Hi,all:
I use databasereader to save file to local from database for test,but when serving 
big file it always save only the beginning part of the file.I check the log,this 
message found:
WARN(2004-04-08) 19:09.26:694   [test] (/attachment/file) 
http8080-Processor2/DatabaseReader: Assuming client reset stream

I use the same database,jdbc driver,table to save file to local using servlet in 
websphere,it's all right.I check the code,

  byte[] buffer = new byte[8192];
  int length = -1;

  while ((length = is.read(buffer)) > -1) {
   out.write(buffer, 0, length);
   System.out.println("writing!"); //insert by me for testing
  }
  is.close();
  out.flush();

For small file(several kbs) is fine,but if the file size is like 5MB,it always only 
save 700-1700kb,so the file is incomplete.I can see "writing" in console stop being 
print.I compare the code to my servlet code ,different is my servlet get the 
connection ,query and close,but databasereader.java close connection in recycle().

environment:
cocoon: current cvs
Tomcat 4.1.30
oracle 9i

my servlet using websphere 5.1 as server

Any suggestion?

Roy Huang

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Sylvain Wallez]

Stefano Mazzocchi wrote:

[EMAIL PROTECTED] wrote:

antonio 2004/04/05 05:25:36

  Log:
  removing encoding="ISO-8859-1"


Why?


Yes, why? UTF-8 is the XML default, but very few general purpose editors 
(i.e. non-XML editors) handle it correctly. So I'm wondering the value 
of this change : can't every dict file use the encoding that's most 
suited for its target language.

Also, how does CVS handle UTF-8 files? I mean what happens if a byte in 
a 2-bytes character is  a "\n"? When checked out on Window, does it 
become "\r\n"? This can lead to very weird questions...

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [Kernel22] How to develop a component?

[Sylvain Wallez]

Steven Noels wrote:

On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:

Steven Noels wrote:

On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:

The issue is not so technical as it's of indipendence from 
something that, in the good and the bad, has not helped Cocoon be 
built by Gump for ages now.
As much as I like "Gumpinal Correctness" for the sanity of us Cocoon 
committers, I'm not sure whether Gump has the goal of driving 
architectural decisions for the projects it is aggregating 
information from. It is a helper tool and should not decide for us, no?


Gump is deciding for us? Did I read "Gump wrote?" :-P

The fact is that a tool tells me that a project we depend upon does 
not get built regularly: this *does* impact on architectural decisions.


The reason of Excalibur not building might perhaps be because of its 
developers not caring enough about providing a strong contract to its 
users. We have an established codeset and user base which have 
habitually been adopting and using the Avalon *APIs* (I'm not 
referring to a particular container here) because of (a) they found 
out about them inside Cocoon, and were encouraged to use them for 
their own Cocoon components, and (b) maybe they even started to 
actually like them, and thus might expect us to provide identical 
services and interfaces in our own container - backed by a healthier 
community.


A big +1 here, also seconding Carsten. The Avalon *API* has led many 
people to COP, as this *API* provides simple means for a component to 
interact with its container. Sure, IOC type 2/3 make it more 
transparent, but IMO don't scale for large sets of components.

So although Cocoon will have a new container, it should not consider 
Avalon APIs as just a bunch of legacy interfaces that have to run in a 
sandbox. It's a slap in the face of many people that have invested time 
to build their application-logic components on top of an enabling 
infrastructure that was seamlessly integrated with Cocoon but could be 
used in other kind of apps, therefore allowing actual cross-application 
reuse of these components. Without this support, people are left alone 
without architectural guidance, and this will be a step back leading to 
unisolated spaghetti code.

So we can trash the ECM, we can change the configuration file format, 
but we *must* support (and not only as a legacy isolated sandbox) the 
Avalon framework APIs (a bunch of 1-method interfaces).

Cross-block classloading problems isn't an issue IMO, as it seems to me 
fairly easy to use dynamic proxies to translate calls to an interface to 
calls to the same interface in a different classloader.

My 1 euro. Yeah, a lot more than Steven ;-)

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Problem with OJB

[Mike Ahlers]

Hi Brian,

I've found the 'source' of the problem. In short it is about 
instantiating a collection of inverse foreign-keys, i.e. references to 
objects. When I change my repository.xml and omit the collection 
descriptors it works! (yay).  Otherwise this is what is happening: get 
Article -> get Article-Type -> create collection of inverse foreign keys 
-> (does intermediate query, fetching all articles with same 
article-type), at end of iterating this collection it goes bewm.

Hopefully this is of any help in order to tackle the / by zero error. 
Let me know if you need more information.

Regards,
Mike Ahlers
Brian McCallister wrote:

Which version of OJB are you using? Line numbers don't match up to 
the  one I have, which is, admittedly, cvs head -- though rc6 and cvs 
head  are pretty similar right now.

Okay, some try-the-common-things-first:

Try changing the PK and FK values to Integer types instead of int.  
Using the primitives can really boggle OJB as it is not safe to 
presume  0 is equivalent to not-set (null).

Test.

Remove the "default-fetch" as it only applies to JDO rinse, repeat.

Will look at more carefully asap =)

-Brian

On Apr 7, 2004, at 9:56 AM, Mike Ahlers wrote:

Hi Brian,

I can try...  let me describe what I got so far. After digging 
deeper  into this and producing some relevant debug statements I find 
the  following written on my console:

console output:
--- start snippet ---
NVTPDataAccessObject2: getArticle: called with id: 56
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: 
executeQuery  : Query from class nl.hippo.nvpt.Articles where [id = 56]
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] 
DEBUG:  SQL:SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0
.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT 
PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE  
A0.ID = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:  
executeQuery: [EMAIL PROTECTED]: SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0. 
ID FROM ARTICLES A0 WHERE A0.ID = 56
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:  
RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query:  
Query from class nl.hippo.nvpt.Articles where [id = 56], class  
descriptor: nl.hippo.nvpt.Articles]] initialized
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] 
DEBUG:  SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: 
executeQuery  : Query from class nl.hippo.nvpt.Articles where [type = 3]


 ^^

[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] 
DEBUG:  SQL:SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0
.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT 
PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE  
A0.TYPE = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:  
executeQuery: [EMAIL PROTECTED]: SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0. 
ID FROM ARTICLES A0 WHERE A0.TYPE = 3
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:  
RsIterator[org.apache.ojb.
broker.accesslayer.RsQueryObject[query: Query from class  
nl.hippo.nvpt.Articles where [type = 3], class descriptor:  
nl.hippo.nvpt.Articles]] initialized
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
...
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() ->  
false
java.lang.ArithmeticException: / by zero
   at  
org.apache.ojb.broker.accesslayer.BasePrefetcher.(BasePrefetcher. 
java:115)
   at  
org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.(Rel 
ationshipPrefetcherImpl.java:78)
   at  
org.apache.ojb.broker.accesslayer.CollectionPrefetcher.(Collectio 
nPrefetcher.java:97)
   at  
org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createR 
elationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
   at  
org.apache.ojb.broker.core.QueryReferenceBroker.performRetriev

DO NOT REPLY [Bug 28276] - FileGenerator blocks xml-files, does not close them properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28276

FileGenerator blocks xml-files, does not close them properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|FileGenerator blocks xml-   |FileGenerator blocks xml-
   |files   |files, does not close them
   ||properly



--- Additional Comments From [EMAIL PROTECTED]  2004-04-08 09:43 ---
Bruno has investigated, see
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108141498420250&w=2

Seems like all uses of SourceUtil.getInputSource() need to be checked for proper
closing (using finally clauses).

DO NOT REPLY [Bug 28276] New: - FileGenerator blocks xml-files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28276

FileGenerator blocks xml-files

   Summary: FileGenerator blocks xml-files
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I constantly edit the file tasks.xml. To check if I wrote everything right, I
constantly check the File via Cocoon (sitemap below). Sometimes this file is
blocked, thus my editor isn't able to write it anymore. It seems, that the
Filegenerator isn't closing it's InputStream correctly.

> The file tasks.xml which is used this way:
> 
>   
>   
>   
>   
>name="use-request-parameters" value="true"/>
>   
>   
>   
>   
>   

Re: [woody] upload widget, unexpected behaviour

[Bertrand Delacretaz]

Le 8 avr. 04, à 11:19, Joerg Heinicke a écrit :
...Enabling uploads? I have updated the FAQ on the wiki only few 
minutes before your post: http://wiki.cocoondev.org/Wiki.jsp?page=FAQs 
(at the end).
Thanks Joerg for the clarification - I wrote this FAQ last week but 
didn't make the connection with "enabling uploads".

-Bertrand

Re: [woody] upload widget, unexpected behaviour

[Jeremy Quinn]

On 8 Apr 2004, at 10:19, Joerg Heinicke wrote:

On 08.04.2004 11:15, Jeremy Quinn wrote:

Hi All
I am making a woody form that allows the user to upload an image 
along with a bunch of meta-data fields.
The meta-data fields are described normally in the model, binding and 
template.
The upload widget is declared in the model and template, but not the 
binding as it does not belong in the Bean being made from the 
meta-data.
There is an @enctype="multipart/form-data" declared on the 
wt:form-template element in the template, for the upload widget.
The continuation was originally setup as a hidden field, with an 
appropriate request-matcher in the sitemap.
When submitting the form, the continuation pipeline was not being 
called so I switched to putting the continuation id in the @action of 
the form (and changed the sitemap accordingly).
Now when I submit the form, the continuation is triggered but no form 
values are copied into the model and back to the form.
When I remove the @enctype="multipart/form-data" form values do get 
copied into the model, but of course the file upload would not work 
like this.
In the upload sample that comes with woody, there is no binding at 
all, and values are read 'by hand'.
What am I missing?
Enabling uploads? I have updated the FAQ on the wiki only few minutes 
before your post: http://wiki.cocoondev.org/Wiki.jsp?page=FAQs (at the 
end).

Truly sorry 

I just read the previous message " Re: Request Problem with 
enctype="multipart/form-data" ".

Feeling very stupid :(

Enable Uploads was off when I thought it was on.

regards Jeremy


smime.p7s
Description: S/MIME cryptographic signature

Re: [woody] upload widget, unexpected behaviour

[Joerg Heinicke]

On 08.04.2004 11:15, Jeremy Quinn wrote:

Hi All

I am making a woody form that allows the user to upload an image along 
with a bunch of meta-data fields.

The meta-data fields are described normally in the model, binding and 
template.

The upload widget is declared in the model and template, but not the 
binding as it does not belong in the Bean being made from the meta-data.

There is an @enctype="multipart/form-data" declared on the 
wt:form-template element in the template, for the upload widget.

The continuation was originally setup as a hidden field, with an 
appropriate request-matcher in the sitemap.

When submitting the form, the continuation pipeline was not being called 
so I switched to putting the continuation id in the @action of the form 
(and changed the sitemap accordingly).

Now when I submit the form, the continuation is triggered but no form 
values are copied into the model and back to the form.

When I remove the @enctype="multipart/form-data" form values do get 
copied into the model, but of course the file upload would not work like 
this.

In the upload sample that comes with woody, there is no binding at all, 
and values are read 'by hand'.

What am I missing?
Enabling uploads? I have updated the FAQ on the wiki only few minutes 
before your post: http://wiki.cocoondev.org/Wiki.jsp?page=FAQs (at the end).

Joerg

[woody] upload widget, unexpected behaviour

[Jeremy Quinn]

Hi All

I am making a woody form that allows the user to upload an image along 
with a bunch of meta-data fields.

The meta-data fields are described normally in the model, binding and 
template.

The upload widget is declared in the model and template, but not the 
binding as it does not belong in the Bean being made from the 
meta-data.

There is an @enctype="multipart/form-data" declared on the 
wt:form-template element in the template, for the upload widget.

The continuation was originally setup as a hidden field, with an 
appropriate request-matcher in the sitemap.

When submitting the form, the continuation pipeline was not being 
called so I switched to putting the continuation id in the @action of 
the form (and changed the sitemap accordingly).

Now when I submit the form, the continuation is triggered but no form 
values are copied into the model and back to the form.

When I remove the @enctype="multipart/form-data" form values do get 
copied into the model, but of course the file upload would not work 
like this.

In the upload sample that comes with woody, there is no binding at all, 
and values are read 'by hand'.

What am I missing?

thanks for any suggestions

regards Jeremy




smime.p7s
Description: S/MIME cryptographic signature

Re: Request Problem with enctype="multipart/form-data"

[Joerg Heinicke]

On 08.04.2004 08:01, Bhagya Nair G. V. wrote:

Hello ,

  Got your details from

http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016255.ht
ml. I have a problem of reading data from request after setting
enctype="multipart/Form-data ".Since you have worked on similar cases ..
hopefully you might be able to help me out.
Problem:

 I have a JSP file which has got two hidden parameters and a file upload
button(I am reading XLS file using ,Jakarta.POI).
 On the click of the upload button I am able to read the XLS file but my
request is coming as null. If I am removing the enctype then I am able
to read the hidden parameters available in the JSP but not the XLS file.
Actually I want to read both.
There were also threads on the users list about this recently. Also in 
the thread you posted Vadim explained why it does not work without 
enabling uploads. Are you sure you have enabled them? In which way?

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108083493525960&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107961307020137&w=4
Joerg

DO NOT REPLY [Bug 28260] - ArrayIndexOutOfBoundsException in cforms Transformer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28260

ArrayIndexOutOfBoundsException in cforms Transformer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 28260] - ArrayIndexOutOfBoundsException in cforms Transformer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28260

ArrayIndexOutOfBoundsException in cforms Transformer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-08 08:25 ---
IMPORTANT note: the work-around is a fraud: it kept the action="" and did not
introduce the required form-action parameter from the sitemap.

Final resolution was in actually fixing the transformer to add/overwrite the
form-action and form-method to possibly existing @action and @method of
ft:form-template.

cvs checkin solving the issue
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/transformation/EffectWidgetReplacingPipe.java#rev1.8

REMARK: this will not clear us from the mentioned ArrayIndexOutOfBoundsException
. If neither the sitemap-parameter or the ft:template is going to provide the
value for the action attribute then it will still occur.  In that case however
the exception is considered to be a sensible warning to the application tester.

-marc=

Re: fi:styling type="date

[Bruno Dumon]

On Thu, 2004-04-08 at 02:49, Joerg Heinicke wrote:
> On 06.04.2004 17:32, [EMAIL PROTECTED] wrote:
> > joerg   2004/04/06 08:32:03
> > 
> >   Modified:src/blocks/forms/samples/forms form1_template.xml
> > form1_template_action.xml
> >   Log:
> >   Tim, forget my stupid comment about different styling in and outside of 
> > repeaters - find the difference ;-)
> > 
> >   I only wonder why I have done the mistake multiple times
> 
> This led me to the question why the form model does not give the styling 
> hint to the pipeline. Of course, it is styling, but for the date it is 
> somewhat datatype centric. In the stylesheet there is also a comment 
> about getting the convertor's format out of the form model - this issue 
> would be solved too.
> 
> WDYT?

Something like that's needed indeed. I wouldn't insert the styling hint
though, but let the datatype and convertor produce some XML, like:


  


-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Problem with OJB

[Mike Ahlers]

I am using rc6. I can see using Integer is better, unfortunately that 
didn't solve the problem (neither did removing the "default-fetch").

- Mike

Brian McCallister wrote:

Which version of OJB are you using? Line numbers don't match up to 
the  one I have, which is, admittedly, cvs head -- though rc6 and cvs 
head  are pretty similar right now.

Okay, some try-the-common-things-first:

Try changing the PK and FK values to Integer types instead of int.  
Using the primitives can really boggle OJB as it is not safe to 
presume  0 is equivalent to not-set (null).

Test.

Remove the "default-fetch" as it only applies to JDO rinse, repeat.

Will look at more carefully asap =)

-Brian

On Apr 7, 2004, at 9:56 AM, Mike Ahlers wrote:

Hi Brian,

I can try...  let me describe what I got so far. After digging 
deeper  into this and producing some relevant debug statements I find 
the  following written on my console:

console output:
--- start snippet ---
NVTPDataAccessObject2: getArticle: called with id: 56
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: 
executeQuery  : Query from class nl.hippo.nvpt.Articles where [id = 56]
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] 
DEBUG:  SQL:SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0
.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT 
PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE  
A0.ID = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:  
executeQuery: [EMAIL PROTECTED]: SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0. 
ID FROM ARTICLES A0 WHERE A0.ID = 56
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:  
RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query:  
Query from class nl.hippo.nvpt.Articles where [id = 56], class  
descriptor: nl.hippo.nvpt.Articles]] initialized
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] 
DEBUG:  SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: 
executeQuery  : Query from class nl.hippo.nvpt.Articles where [type = 3]


 ^^

[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] 
DEBUG:  SQL:SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0
.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT 
PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE  
A0.TYPE = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:  
executeQuery: [EMAIL PROTECTED]: SELECT  
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0. 
ID FROM ARTICLES A0 WHERE A0.TYPE = 3
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:  
RsIterator[org.apache.ojb.
broker.accesslayer.RsQueryObject[query: Query from class  
nl.hippo.nvpt.Articles where [type = 3], class descriptor:  
nl.hippo.nvpt.Articles]] initialized
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
...
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() ->  
false
java.lang.ArithmeticException: / by zero
   at  
org.apache.ojb.broker.accesslayer.BasePrefetcher.(BasePrefetcher. 
java:115)
   at  
org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.(Rel 
ationshipPrefetcherImpl.java:78)
   at  
org.apache.ojb.broker.accesslayer.CollectionPrefetcher.(Collectio 
nPrefetcher.java:97)
   at  
org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createR 
elationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
   at  
org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Q 
ueryReferenceBroker.java:315)
   at  
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu 
eryReferenceBroker.java:185)
   at  
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu 
eryReferenceBroker.java:242)
   at  
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu 
eryReferenceBroker.java:262)
   at  
org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(Quer 
yRe

Re: new blocks.properties way more painful to use

[David Crossley]

Joerg Heinicke wrote:

> 
> Thanks for the constructive idea. I have it working now the following 
> way: internal.exclude set through include set through exclude property. 
> In blocks.properties there are #include=false lines (except for the 
> deprecated ones), blocks are included by default. This solution would 
> bring back Stefano's uncommenting/commenting, but has one down side: the 
> deprecated blocks excluded via include=false in blocks.properties can 
> not be included by exclude=false (as it is possible now, backwards 
> compatibility), but must be included by include=true.
> 
> WDYT? Commit?

Good on you, Joerg. Thanks for this important work. You would
have needed your logic hat firmly fixed to your head to write
both the code and the above paragraph.

The "down side" is not so bad. People should need to do
specific and deliberate actions to include deprecated stuff.

+1 to commit.

--David