date:20031027

Re: wiki diff emails are duplicated

2003-10-27 Thread David Crossley

Antonio Gallardo wrote:
> David Crossley dijo:
> > Recently the Wiki has started sending duplicate emails,
> > e.g. it sends one message at 10:00 am then the same one again
> > at 11:00 am
> 
> I noted this started on Friday. :-D

I just noticed another problem with the Wiki. It seems that not
all diffs are being sent. Today i modified the CocoonFeatures page,
making four separate edits (versions 38, 39, 40, 42) over 15 minutes.
Antonio made another edit (41) in the middle and another (43) later.

However the only notification that we received was for 43 and
nothing for edits 38-42. 

--David

DO NOT REPLY [PATCH QUEUE] Summary October 28 2003

2003-10-27 Thread nicolaken

---
 This mail is generated automatically using
 Jakarta Ant. Contents are automatically
 downloaded from Apache's Bugzilla.
---
 Please do not reply to this mail.
---

***
COCOON PATCH QUEUE UPDATE
 
patches in queue:  13 
***


---
16537:[PATCH] fixed redirect under JRun 3.1
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16537

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
17771:[PATCH] new logging category never set when using log logics
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17771

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
19138:[Contrib]/[Patch] Made SQLTransformer paginatable.
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19138

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
19638:[PATCH] Same cell definitions blows document (problem with
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19638

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
19641:[PATCH] HSSFSerializer Support for FreezePane
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19641

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
20508:[PATCH] Namespace cleanup in HTMLSerializer
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20508

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
20631:[PATCH] Support for transactions in SQLTransformer
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20631

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
23538:[PATCH] JXTemplateGenerator calls setDocumentLocator() exces
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23538

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
23901:[PATCH] [woody], adding  and moving load() and
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23901

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
23921:[PATCH] New ReadDOMTransformer/WriteDOMTransformer available
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23921

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
23299:[PATCH] UTFDataFormatException: String cannot be longer than
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23299

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  ASSI
---
21536:[PATCH] 2 new generators: MultiPartPosted XML and MS Excel c
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21536

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  REOP
---
23796:[PATCH] docs pages containing  are sometimes too wid
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23796

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  REOP

*that's it!

patch HOWTO

Send patches to http://nagoya.apache.org/bugzilla/
specifying [PATCH] in the summary.
Bugzilla sends a mail automatically to this list.
Reviewers will mark it FIXED there when applied.
Patches not sent to Bugzilla will not be reviewed.
---
This file is scheduled to be generated every Tuesday and
Friday 1:00 CET for the cocoon-dev mailing list, on
Sundays 1:00 CET fo

Re: Antwort: Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl PartSource.java PartSourceFactory.java

2003-10-27 Thread Geoff Howard

[EMAIL PROTECTED] wrote:

Hi Geoff,

I think the reason is, that the PartSourceFactory isn't ThreadSafe. So
every time you access a PartSourceFactory a new Component is created and
the contextualize Method is called.
 

Ah, I hadn't noticed this.  Still, does that explain why it's called 
twice for every request?

Calling "this.objectModel = ContextHelper.getObjectModel(context)" inside
the "contextualize"-Method can't work, because contextualize is called only
once. You need to call "ContextHelper.getObjectModel(context)" inside the
actual Thead, instead you don't get the right objectModel.
My proposal is change getSource to:

public Source getSource(String uri, Map parameters) throws IOException,
MalformedURLException
{
   return new PartSource(uri, ContextHelper.getObjectModel(this.context));
}
 

Ah, it's thread local.  I get it.  Ok, will do.

Geoff

Oh, by the way - when I was testing this I traced things through a few
times with the debugger and found that contextualize() is being called
twice for each request.  Is that expected?  Is there any conceivable
mis-coding or mis-configuration of the component that could cause this?
Geoff

[EMAIL PROTECTED] wrote:

 

ghoward 2003/10/25 15:31:39

Modified:src/java/org/apache/cocoon/components/source/impl
  PartSource.java PartSourceFactory.java
Log:
use contextualize instead of static
CocoonComponentManager.getCurrentEnvironment()



Revision  ChangesPath
1.2   +2 -7
   

cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSource.java

 

Index: PartSource.java
===
RCS file:
   

/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSource.java,v

 

retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PartSource.java 23 Oct 2003 01:45:34 -  1.1
+++ PartSource.java 25 Oct 2003 22:31:39 -  1.2
@@ -58,8 +58,6 @@
 import org.apache.cocoon.servlet.multipart.Part;
 import org.apache.cocoon.environment.ObjectModelHelper;
 import org.apache.cocoon.environment.Request;
-import org.apache.cocoon.components.CocoonComponentManager;
-
 import java.net.MalformedURLException;
 import java.util.Map;
 import java.io.IOException;
@@ -91,7 +89,7 @@
  * @throws SourceException
  * @throws MalformedURLException
  */
- public PartSource(String uri) throws MalformedURLException,
   

SourceException
 

+ public PartSource(String uri, Map objectModel) throws
   

MalformedURLException, SourceException
 

  {
  // set the uri for use in getURI()
  this.uri = uri;
@@ -110,9 +108,6 @@
  // get the request parameter name: the bit after
   

://
 

  String location = uri.substring(position + 2);
-
- // get the object model from the component
   

managers curr env.
 

- Map objectModel =
   

CocoonComponentManager.getCurrentEnvironment().getObjectModel();
 

  // get the cocoon request from the object model.
  Request request =
   

ObjectModelHelper.getRequest(objectModel);
 

1.2   +16 -3
   

cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSourceFactory.java

 

Index: PartSourceFactory.java
===
RCS file:
   

/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSourceFactory.java,v

 

retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PartSourceFactory.java23 Oct 2003 01:45:34 -
   

1.1
 

+++ PartSourceFactory.java25 Oct 2003 22:31:39 -
   

1.2
 

@@ -50,6 +50,9 @@
 */
 package org.apache.cocoon.components.source.impl;
+import org.apache.avalon.framework.context.ContextException;
+import org.apache.avalon.framework.context.Contextualizable;
+import org.apache.cocoon.components.ContextHelper;
 import org.apache.excalibur.source.Source;
 import org.apache.excalibur.source.SourceFactory;
@@ -62,16 +65,18 @@
  *
  * @author mailto:[EMAIL PROTECTED]">Paul Crabtree
  */
-public class PartSourceFactory implements SourceFactory
+public class PartSourceFactory implements SourceFactory,
   

Contextualizable
 

 {
- /*
+ Map objectModel;
+
+/*
   * Returns a new [EMAIL PROTECTED] PartSource} based on the uri.
   *
   * @see
   

org.apache.excalibur.source.SourceFactory#getSource(java.lang.String,
java.util.Map)
 

   */
 public Source getSource(String uri, Map parameters) throws
   

IOException, MalformedURLException
 

 {
-return new PartSource(uri);
+return new PartSource(uri, this.objectModel);
 }
  /**
@@ -82,5 +87,13 @@
 public void release(Source source)
 {
 // Nothing to do here
+}
+
+ /**
+ * Get the objectModel from the Context
+

Re: Wafer update

2003-10-27 Thread David Crossley

Tony Collen wrote:
> Jeff Ramsdale wrote:

> > 
> > So, I'm wondering if someone who knows the innards of Cocoon better than I
> > do could help the gentlepeople who created this chart update it with
> > Cocoon's current feature-set.
> > 
> > http://www.waferproject.org/feature-matrix2.html
> 
> Wow, there's a lot that should be checked, i.e.:


It would be a lot easier on us if we just kept our own
Wiki page up-to-date, then just point such people to it:
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures

--David

RE: [Portal] future and design questions

2003-10-27 Thread sarah . ho


Return Receipt


Your document:
RE: [Portal] future and design questions


was received by:
Sarah Ho/CoRe


at:
10/28/2003 09:21:50 AM

Re: Questions about Meta Info

2003-10-27 Thread Geoff Howard

Berin Loritsch wrote:

What this means is that the @x-avalon-info should be considered 
differently for service interfaces (element name) and for classes 
("type" attribute).


No, it means that your interpretation of the configuration to get
at the short name would be different.


Is there an easy way to find out what real class a given shortcut/role 
is associated with (resolving to)?  In
digging into things in Cocoon now I and I'm sure others grep through the 
roles file and cocoon.xconf to find
where to look for a given implementation.  I'm thinking it would be good 
to provide some way to trace back
from a hint name or service type back to the concrete class.

Also,  the roles file defines default implementation which can be 
overridden in xconf.  Is this the same in fortress? 
If I want to replace the default implementation of transient-store with 
my own souped up version (you'll need to
momentarily suspend your disbelief that I'm capable of coming up with 
one ;) ) how do I do that? 

Geoff

Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching Matcher.java CookieMatcher.java)

2003-10-27 Thread Geoff Howard

Berin Loritsch wrote:

Geoff Howard wrote:

I'm hoping someone with more confidence in the changes needed can 
check out the simple changes below.  Such a paradigm shift to give up 
the marker interfaces (and I'm mourning the loss of content assist.  
Don't suppose an eclipse plugin for meta info yet?)


Content assist?

Eclipse plugin:  not at this time.


What I meant by content assist is that with marker interfaces, normal 
java ide support got you content assist (auto completion, plus in 
eclipse javadoc on hover)
for the Avalon stuff because interfaces are pure java.  The meta-info 
takes that away - just a minor annoyance really.

Open questions:
- What do sitemap components get for @x-avalon-info?  A new made up 
string like cookie-matcher?  The @name/type from the default sitemap 
in 2.1?


The @x-avalon-info name="cookie-matcher" line lets you define your 
components
like this:


  configuration

It takes away the need for a separate ROLES file.
Right, but we don't have our sitemap components in a roles file.  We 
have them in  and it's not clear to me
how this concept changes in 2.2. 

- Will this mean we no longer have to declare sitemap components in 
the sitemap?


More it means that there is no reason to have a ROLES file, which also
means taht you can incorporate any component into Cocoon using a friendly
configuration name without resorting to specifying user roles files or
even internal roles files.
- What about other lifecycle interfaces like: Contextualizable, 
Parameterizable, Disposable?


They haven't changed.  They actually have a reason to exist.  They 
provide
information or invoke an event on the component--unlike the marker 
interfaces
that did nothing but mess with the class hierarchy.


gotcha.

Geoff

Re: Wafer update

2003-10-27 Thread Tony Collen

Antonio Gallardo wrote:

Tony Collen dijo:

Not sure about EJB or O/R stuff, since I don't mess with it much. It's a
little hazy by which methods these featuresets are evaluated.


Hey?! Where you left the OJB support, it is O/R support?!!!
 :-
That means: JDO, ODMG support.
Heheheh, more acronyms I'm not familliar with :)

Tony

Re: Wafer update

2003-10-27 Thread Antonio Gallardo

Tony Collen dijo:
> Not sure about EJB or O/R stuff, since I don't mess with it much. It's a
>  little hazy by which methods these featuresets are evaluated.

Hey?! Where you left the OJB support, it is O/R support?!!!
 :-

That means: JDO, ODMG support.

Best Regards,

Antonio Gallardo.

Re: sitemap logging?

2003-10-27 Thread Vadim Gritsenko

Unico Hommes wrote:

It seems that all loggers assigned to sitemap components are getting
their category prepended with 'sitemap'.
Defining 
the transformer will get a logger in the category
sitemap.sitemap.transformer.xslt
Is this intentensional?
 

I tend to think that this is correct behavior (because it is more 
"secure" -- parent logger is given to you and you don't have ability to 
use different one) and declarations in the sitemap should be changed to 
cut "sitemap." prefix.

Other opinions?

Vadim

Feature Matrix

2003-10-27 Thread Tony Collen

Hello Anthony,

I've recently been pointed to your feature matrix [1], and I would like 
to update you with some features of Cocoon which should be updated in 
your matrix:

I18N -- Through the I18NTransformer, docs located at [2]

Security -- Cocoon has an extensive authentication framework which does 
not rely on the container.

Documentation: D,E,F,G,J,T (Self explanatory)

Error Handling -- Cocoon can handle internal errors very easily, see [3]

IDE Integration -- S&N produces an Eclipse plugin called "sunBow" which 
is very useful for Cocoon Development.  See [4]

Web Services -- Cocoon has a WebServiceProxy Generator component, [5] as 
well as a generic HttpProxy component.

Direct Database Access -- Cocoon can connect to JDBC data sources, as 
well as XML databases such as Xindice.

Workflow -- Cocoon has a Flow layer which utilizes the Rhino Javascript 
engine, and continuations.  See [6].

XML-RPC -- This really falls under web services -- You can easily 
connect using a Java XML-RPC library from the Flow layer.

Job Scheduling - Cocoon has a "Cron" block which allows execution of 
code at specific time intervals.

Thanks for listening -- we eagerly await the update of the product 
matrix. :)

Regards,

Tony Collen



[1] http://www.waferproject.org/feature-matrix2.html
[2] http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transformer.html
[3] http://wiki.cocoondev.org/Wiki.jsp?page=ErrorHandling
[4] http://radio.weblogs.com/0108489/
[5] http://wiki.cocoondev.org/Wiki.jsp?page=WebServiceProxyGenerator
[6] http://cocoon.apache.org/2.1/userdocs/flow/index.html

Re: Wafer update

2003-10-27 Thread Tony Collen

Jeff Ramsdale wrote:

Hi all,

Ran across this page and searched the archive for references. Found one from
a year or so ago from Sylvain, so I thought it might be time to point it out
again. The Wafer Project compares the feature sets of major Java-based web
application frameworks. Companies love this sort of chart because it can
save a lot of tedious research in making technology decisions. We all know,
though, that it's nearly impossible to know how accurate and/or up-to-date
data like this is on the Internet.
So, I'm wondering if someone who knows the innards of Cocoon better than I
do could help the gentlepeople who created this chart update it with
Cocoon's current feature-set.
http://www.waferproject.org/feature-matrix2.html
Wow, there's a lot that should be checked, i.e.:

I18N (Effortless)
Security (Auth-FW)
Documentation: D,E,F,G,J,T
Error Handling (i.e. )
IDE Integration (SunBow)
Web Services (WSProxy, HttpProxy)
Direct Database Access (ESQL, etc)
Workflow (The Flowscript)
XML-RPC (This really falls under web services)
Job Scheduling - Scheduler in cron block.
Not sure about EJB or O/R stuff, since I don't mess with it much. It's a 
little hazy by which methods these featuresets are evaluated.

If anyone has tips on out-of-date information for other frameworks in the
chart I'd be interested as well.
Jeff

Wafer update

2003-10-27 Thread Jeff Ramsdale

Hi all,

Ran across this page and searched the archive for references. Found one from
a year or so ago from Sylvain, so I thought it might be time to point it out
again. The Wafer Project compares the feature sets of major Java-based web
application frameworks. Companies love this sort of chart because it can
save a lot of tedious research in making technology decisions. We all know,
though, that it's nearly impossible to know how accurate and/or up-to-date
data like this is on the Internet.

So, I'm wondering if someone who knows the innards of Cocoon better than I
do could help the gentlepeople who created this chart update it with
Cocoon's current feature-set.

http://www.waferproject.org/feature-matrix2.html

If anyone has tips on out-of-date information for other frameworks in the
chart I'd be interested as well.

Jeff

Re: Continuations and multiple sessions

2003-10-27 Thread Antonio Gallardo

Jeff Ramsdale dijo:
> Hi all,
>
> Up till now I've only casually been following progress on flow and forms
> development in Cocoon but recently I've had opportunity to dig deeper
> (new job--woo hoo!).

Congrats!!! :-D


> I'm curious about how flow/continuations are handled in a situation
> where the user has begun interacting with a flow-managed page and then
> they open a new window (via CTRL-N, say) and the two windows get out of
> sync with each other. Is it possible to invalidate one and not the
> other? How can the server identify each?

Well, this is under discussion right now. But under other perspective:
The user send the link to a friend (in other machine).

AFAIK, this is very hard to manage and there has been some comments about
how to solve this tpe of solutions, but still there is not a clear "green
light" to follow.

Best Regards,

Antonio Gallardo

Continuations and multiple sessions

2003-10-27 Thread Jeff Ramsdale

Hi all,

Up till now I've only casually been following progress on flow and forms
development in Cocoon but recently I've had opportunity to dig deeper (new
job--woo hoo!). So my question here may already have been answered and I
missed it. Please forgive me if that's the case.

I'm curious about how flow/continuations are handled in a situation where
the user has begun interacting with a flow-managed page and then they open a
new window (via CTRL-N, say) and the two windows get out of sync with each
other. Is it possible to invalidate one and not the other? How can the
server identify each?

Thanks,

Jeff

Re: [proposal] Doco

2003-10-27 Thread Stefano Mazzocchi

On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote:

nah, dude, look: doco has a very precise editing access point. You can
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
servlet upload, sql injection, cross-site-scripting, and you next
favorite attack will NOT work because the system prevents it by design
[not saying it cannot happen, but if it does it's a bug, not a faulty
design]
FWIW, I agree. Perhaps the submit goes to a well-formedness check (or 
even
better?, schema/dtd validation). If it fails, it doesn't even enter the
approval process.
Absolutely. This wasn't mentioned, but planned. I will do relaxng 
validation before allowing any xml data into the system. This should be 
enough for documentation.

Perhaps a notification email is sent describing that an
invalid submittal was sent.
Nah, it would just fail and log the failure. No need to spam further 
since it might well be a bug in the editing software ;-) [I have 
experienced a few of them as well]

The user is returned an error page saying the
post was rejected, in case it was just a mistake.
On another note, can images/PDFs/other-binaries be uploaded?
Damn, forgot about this!

My suggestion would be to process the binary file and determine if it's 
an image or not.

If not, reject it right away. [there should be *NO* need to upload any 
other binary file ]

--
Stefano.

Re: X2EE

2003-10-27 Thread Tony Collen

Reinhard Poetz wrote:
The author of this doc (http://www.x2ee.org/whitepaper.doc) is Steven P.
Punte.
Yet another case of me firing off an email before totally looking at everything :)

Interesting nonetheless. I think a North-America chapter of Orixo would be worthwhile.

Regards,

Tony

Reinhard

RE: X2EE

2003-10-27 Thread Reinhard Poetz

The author of this doc (http://www.x2ee.org/whitepaper.doc) is Steven P.
Punte.

Reinhard

> -Original Message-
> From: Tony Collen [mailto:[EMAIL PROTECTED] 
> Sent: Monday, October 27, 2003 9:13 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: X2EE
> 
> 
> I just found this interesting link:
> 
> http://www.x2ee.org/index.html
> 
> Check out the forrest skin!  Cocoon is also mentioned.
> 
> Anyone know who's behind this all?
> 
> Tony
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

Re: X2EE

2003-10-27 Thread Joerg Heinicke

On 27.10.2003 21:12, Tony Collen wrote:

I just found this interesting link:

http://www.x2ee.org/index.html

Check out the forrest skin!  Cocoon is also mentioned.

Anyone know who's behind this all?
http://www.x2ee.org/contact.html

Steven Punte, Candlelight Software

I know from the lists. He was at leasts temporarily active 
(http://marc.theaimsgroup.com/?w=2&r=1&s=Steven+Punte&q=a).

IMO Cocoon is not only mentioned, the complete framework seems to be 
build on Cocoon.

Joerg

X2EE

2003-10-27 Thread Tony Collen

I just found this interesting link:

http://www.x2ee.org/index.html

Check out the forrest skin!  Cocoon is also mentioned.

Anyone know who's behind this all?

Tony

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java logicsheet-util.xsl util.xsl

2003-10-27 Thread Christian Haul

Vadim Gritsenko wrote:
Sorry, mozilla crash marked it as unread :)))
Though it must be something like that 8-D

	Chris.

--
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: [RT] Sitemap inheritance

2003-10-27 Thread Stefano Mazzocchi

On Sunday, Oct 26, 2003, at 23:51 Europe/Rome, Gianugo Rabellino wrote:

Geoff Howard wrote:
Gianugo Rabellino wrote:

In short: blocks should ease a Cocoon developer's life, and block 
assembling should belong to the "programmer" domain. Normal users 
should see only benefits from it. Or am I wrong?
I believe that the benefits from real blocks will be so monumental to 
the way people work with Cocoon that every application should be 
packaged as a block/group of blocks.  Much of the pain of developing 
with Cocoon (more than the first little tinkering) goes away.  We 
need to make sure blocks are not scary to people,  but I don't think 
this is going to be difficult.  I'd propose waiting until we have a 
first working draft before further investigating alternatives which 
replace blocks.
Just to make things clear: I'm not advocating an alternative to 
replace blocks, I'm a strong fan of it. I just think that blocks 
should ease development of Cocoon apps, while not becoming the only 
way of working with Cocoon. In the upcoming future I see lots of 
blocks being interconnected by traditional sitemap editing as we're 
used to it now.

Sitemap (better: pipeline) inheritance goes in this direction: it's 
perfectly OK and cool to have it within blocks, but I don't see why it 
should not be possible even outside them. So I'm not stating anything 
that goes against blocks: I'm just looking for a way to ease the final 
user experience with Cocoon. Keeping in mind that the majority of 
users won't make blocks, but rather just use them.
I'm sorry, but this seems to me like stating that even if the java 
libraries are well object oriented, we have to make sure that people 
can write C-like code with them and make it easier for them to do so.

As java go *exactly* the other way (make life easier for people that 
follow OO patterns), and it's one of the reason why I like java and the 
community around it (I dislike when they get to religious about it, but 
that's another story)

why shouldn't we do the same?

I know it's impossible for a system to "teach" people how to program, 
but for sure I can make their life a little harder if they are going in 
the direction that this community is not following: this will force 
them to look around for better and easier ways and we'll make sure to 
make their life easier if they follow our practices.

I suggest we make it easier for people to write blocks, not give them 
shortcuts to go around them and consider them obstacles.

--
Stefano.

Re: InspectableSource

2003-10-27 Thread Guido Casper

Unico Hommes <[EMAIL PROTECTED]> wrote:
> I am looking into extending SourcePropsWritingTransformer to also be
> able to remove SourceProperties. One thing I need to decide is how to
> access SourceProperties now that we have SourceDescriptor interface.
> From SourceDescriptionGenerator I can see that the distinction between
> SourceInspector and InspectableSource was mainly that of computed vs.
> modifiable. With the new SourceDescriptor interface this distinction
> does not exist anymore and so we have in fact two interfaces with the
> same functiality. We need to decide what to do with that.
>
> I see three possibilities:
>
> 1) keep InspectableSource interface. SourceProperty related sitemap
> components talk with both interfaces to do their job, favoring
> InspectableSource if the Source implements it else falling back on
> SourceDescriptor.
>
> Pro: - SourceProperty related coding can be done directly onto the
> Source.
> Con: - Confusing what properties are managed where
>  - Clients have two interfaces to choose from
>
> 2) deprecate InspectableSource in favor of SourceDescriptor and
> migrate SourceProperty related sitemap components to use the
> SourceDescriptor interface instead, taking care for backwards
> compatibility with Sources that haven't moved away from
> SourceInspector yet.
>
> Pro: - Client need to use only one interface
> Con: - Need to refactor some things
>  - SourceProperties are not directly available on Source.
>
> 3) make SoureProperty related sitemap components talk directly to
> InspectableSources only. Create a Source delegate - callit
> RepositorySource - that adds inspectability to arbitrary sources by
> talking to SourceDescriptors.
>
> Pro: - One interface
>  - SourceProperties directly visible on Source
>
> Ok, I think I just answered my own question ;-D, but I'd be interested
> in others' opinions.
>
> What do others think?

+1 for 3)

Guido

Re: Questions about Meta Info

2003-10-27 Thread Sylvain Wallez

Berin Loritsch wrote:

Sylvain Wallez wrote:

Berin Loritsch wrote:

- What do sitemap components get for @x-avalon-info?  A new made up 
string like cookie-matcher?  The @name/type from the default 
sitemap in 2.1?


The @x-avalon-info name="cookie-matcher" line lets you define your 
components
like this:


  configuration



I must say that I'm not really convinced by this notation, as it 
makes finding the various implementations or a service in an xconf 
file somehow difficult, and even make the xconf file hardly 
understandable unless you know the shortname for each and every 
service implementation.


How is it so different than what you see now in ECM based 
configurations, really?  There is no real difference.

In the ECM, the hints were visible only _within_ a selector defining 
the scope of these hints, e.g.:

 ...
 ...



How many other component types are named "jdbc" or "j2ee"?  It really 
isn't that hard.

If Fortress configurations are flat configurations with hints (or 
x-avalon-info), knowing what kind of component an element declares 
can be tricky. Furthermore, there's a non negligible probability of 
name clashes on large systems.


By default, but we can adapt it to handle the configuration file 
however you want.  If it makes it easier for you to deal with 
 and a bunch of internal components, that can easily be 
accomodated.


AFAIU, this is required to keep the current format of .

Also if you adopt a few naming conventions there will be no real issue.

For instance, the default naming convention for Fortress based 
components takes the Class Name (minus the package) and trnasform it 
into an "XML" name.  Essentially an all lowercase name with hyphens to 
separate words.
For example:
CookieMatcher -> cookie-matcher
FileGenerator -> file-generator

It's not that difficult.


Agree, but maybe it's just too much automagic...

Is there potential for name clashes?  Absolutely.  In practice 
however, the potential is a lot lower than you think.


And what happens in that case? An exception should be raised, otherwise 
I guess the user will have no more hairs on his head when she finally 
finds that the system doesn't behave as expected because the used class 
isn't the one she expected...

This style of managing component meta-info has been around for a 
while, and it is new to you. Give it a chance.


Yeah, I'm ok to give it a chance, but I'm wondering about the "too much 
magic kills the confidence" syndrome : too much of today's xconf 
structure is disappearing at once. And I think I'll miss the "class" 
attribute...

Something that would be more readable IMO, is to have the hint as an 
additional attribute, e.g.
...
...

and accordingly:
...


We can adapt the CocoonContainer type to handle this mapping--but is 
it really more readable?  It is more verbose than say:



Which is what is the more normal convention.


Mmmh... Yep, that's better than just "jdbc" or "j2ee". And you're right 
that most often an implementation class name ends with the name of the 
service interface it implements.

We'll see... But I'm still afraid that, although containing less class 
names, the "flat bag" organization of the new xconf file will frighten 
users to touch it even more than the current one that is full of class 
names.

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

sitemap logging?

2003-10-27 Thread Unico Hommes


It seems that all loggers assigned to sitemap components are getting
their category prepended with 'sitemap'.

Defining 
the transformer will get a logger in the category
sitemap.sitemap.transformer.xslt

Is this intentensional?

I am running a CVS version from this morning.

Anybody have a clue?

-- Unico

Re: InspectableSource

2003-10-27 Thread Guido Casper

Unico Hommes <[EMAIL PROTECTED]> wrote:
> In order to add the possibility to remove properties from sources to
> SourcePropsWritingTransformer I'd like to slightly change the syntax.
>
> Currently you can write:
>
> http://apache.org/cocoon/propwrite/1.0";>
>
>
repository:context://samples/repository/sitemap.xmap rce:source>
>
>  me
>
> 
>
> I'd like to instead replace the source:props with source:set and
> source:remove so that we can write:
>
> http://apache.org/cocoon/propwrite/1.0";>
>repository:context://sitemap.xmap
>
>  mystuff
>
>
>  
>
> 

+1

Guido

>
> This is similar to the PROPPATCH syntax.
>
> Anybody against this? Guido, is this OK with you?
>
> -- Unico
>
>>
>> -Original Message-
>> From: Unico Hommes
>> Sent: maandag 27 oktober 2003 14:52
>> To: [EMAIL PROTECTED]
>>
>>
>> I am looking into extending SourcePropsWritingTransformer to
>> also be able to remove SourceProperties. One thing I need to
>> decide is how to access SourceProperties now that we have
>> SourceDescriptor interface.
>> From SourceDescriptionGenerator I can see that the
>> distinction between SourceInspector and InspectableSource was
>> mainly that of computed vs.
>> modifiable. With the new SourceDescriptor interface this
>> distinction does not exist anymore and so we have in fact two
>> interfaces with the same functiality. We need to decide what
>> to do with that.
>>
>> I see three possibilities:
>>
>> 1) keep InspectableSource interface. SourceProperty related
>> sitemap components talk with both interfaces to do their job,
>> favoring InspectableSource if the Source implements it else
>> falling back on SourceDescriptor.
>>
>> Pro: - SourceProperty related coding can be done directly
>> onto the Source.
>> Con: - Confusing what properties are managed where
>>  - Clients have two interfaces to choose from
>>
>> 2) deprecate InspectableSource in favor of SourceDescriptor
>> and migrate SourceProperty related sitemap components to use
>> the SourceDescriptor interface instead, taking care for
>> backwards compatibility with Sources that haven't moved away
>> from SourceInspector yet.
>>
>> Pro: - Client need to use only one interface
>> Con: - Need to refactor some things
>>  - SourceProperties are not directly available on Source.
>>
>> 3) make SoureProperty related sitemap components talk
>> directly to InspectableSources only. Create a Source delegate
>> - callit RepositorySource - that adds inspectability to
>> arbitrary sources by talking to SourceDescriptors.
>>
>> Pro: - One interface
>>  - SourceProperties directly visible on Source
>>
>> Ok, I think I just answered my own question ;-D, but I'd be
>> interested in others' opinions.
>>
>> What do others think?
>>
>> -- Unico

RE: InspectableSource

2003-10-27 Thread Unico Hommes


In order to add the possibility to remove properties from sources to
SourcePropsWritingTransformer I'd like to slightly change the syntax.

Currently you can write:

http://apache.org/cocoon/propwrite/1.0";>
 
repository:context://samples/repository/sitemap.xmap
   
 me
   


I'd like to instead replace the source:props with source:set and
source:remove so that we can write:

http://apache.org/cocoon/propwrite/1.0";>
   repository:context://sitemap.xmap
   
 mystuff
   
   
 
   


This is similar to the PROPPATCH syntax.

Anybody against this? Guido, is this OK with you?

-- Unico

> 
> -Original Message-
> From: Unico Hommes 
> Sent: maandag 27 oktober 2003 14:52
> To: [EMAIL PROTECTED]
> 
> 
> I am looking into extending SourcePropsWritingTransformer to 
> also be able to remove SourceProperties. One thing I need to 
> decide is how to access SourceProperties now that we have 
> SourceDescriptor interface.
> From SourceDescriptionGenerator I can see that the 
> distinction between SourceInspector and InspectableSource was 
> mainly that of computed vs.
> modifiable. With the new SourceDescriptor interface this 
> distinction does not exist anymore and so we have in fact two 
> interfaces with the same functiality. We need to decide what 
> to do with that.
> 
> I see three possibilities:
> 
> 1) keep InspectableSource interface. SourceProperty related 
> sitemap components talk with both interfaces to do their job, 
> favoring InspectableSource if the Source implements it else 
> falling back on SourceDescriptor.
> 
> Pro: - SourceProperty related coding can be done directly 
> onto the Source.
> Con: - Confusing what properties are managed where
>  - Clients have two interfaces to choose from
> 
> 2) deprecate InspectableSource in favor of SourceDescriptor 
> and migrate SourceProperty related sitemap components to use 
> the SourceDescriptor interface instead, taking care for 
> backwards compatibility with Sources that haven't moved away 
> from SourceInspector yet.
> 
> Pro: - Client need to use only one interface
> Con: - Need to refactor some things
>  - SourceProperties are not directly available on Source.
> 
> 3) make SoureProperty related sitemap components talk 
> directly to InspectableSources only. Create a Source delegate 
> - callit RepositorySource - that adds inspectability to 
> arbitrary sources by talking to SourceDescriptors.
> 
> Pro: - One interface
>  - SourceProperties directly visible on Source
> 
> Ok, I think I just answered my own question ;-D, but I'd be 
> interested in others' opinions.
> 
> What do others think?
> 
> -- Unico
> 
>

Re: Questions about Meta Info

2003-10-27 Thread Berin Loritsch

Sylvain Wallez wrote:

Berin Loritsch wrote:

- What do sitemap components get for @x-avalon-info?  A new made up 
string like cookie-matcher?  The @name/type from the default sitemap 
in 2.1?
The @x-avalon-info name="cookie-matcher" line lets you define your 
components
like this:


  configuration

I must say that I'm not really convinced by this notation, as it makes 
finding the various implementations or a service in an xconf file 
somehow difficult, and even make the xconf file hardly understandable 
unless you know the shortname for each and every service implementation.
How is it so different than what you see now in ECM based configurations,
really?  There is no real difference.
In the ECM, the hints were visible only _within_ a selector defining the 
scope of these hints, e.g.:

 ...
 ...

How many other component types are named "jdbc" or "j2ee"?  It really
isn't that hard.
If Fortress configurations are flat configurations with hints (or 
x-avalon-info), knowing what kind of component an element declares can 
be tricky. Furthermore, there's a non negligible probability of name 
clashes on large systems.
By default, but we can adapt it to handle the configuration file however
you want.  If it makes it easier for you to deal with 
and a bunch of internal components, that can easily be accomodated.
Also if you adopt a few naming conventions there will be no real issue.
For instance, the default naming convention for FOrtress based components
takes the Class Name (minus the package) and trnasform it into an "XML"
name.  Essentially an all lowercase name with hyphens to separate words.
For example:
CookieMatcher -> cookie-matcher
FileGenerator -> file-generator
It's not that difficult.

Is there potential for name clashes?  Absolutely.  In practice however,
the potential is a lot lower than you think.  This style of managing
component meta-info has been around for a while, and it is new to you.
Give it a chance.
Something that would be more readable IMO, is to have the hint as an 
additional attribute, e.g.
...
...

and accordingly:
...
We can adapt the CocoonContainer type to handle this mapping--but is
it really more readable?  It is more verbose than say:


Which is what is the more normal convention.

What this means is that the @x-avalon-info should be considered 
differently for service interfaces (element name) and for classes 
("type" attribute).
No, it means that your interpretation of the configuration to get
at the short name would be different.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin

Re: [RT] Sitemap inheritance

2003-10-27 Thread Stefano Mazzocchi

On Sunday, Oct 26, 2003, at 21:22 Europe/Rome, Gianugo Rabellino wrote:

If this means "shielding" users from the need of having a block, I 
completely rest my case. But we need to have backward compatibility to 
what we have now: unpack war (or go to build/webapp) and work from 
there. Anything more complicated, no matter what the advantages are, 
would just be overkill to the average user.
Let me start saying that 'usability of the system during development' 
is a top priority and must work with blocks as well. The use of a 
blockpath is an idea, but there could be others on the table.

Anyway, the concern of "make it simple for developers" is (and has 
always been) a top priority for me. This is a different concern in 
whether we want inheritance to happen at the sitemap level or at the 
block level.

Sylvain and I say that it should be at the block level, you say it 
should be at the sitemap level.

Note: the above does *NOT* have anything to do with regular WAR-style 
deployment. Once blocks are deployed, you can repack everything in a 
war file and use that. so blocks or sitemap nothing changes.

there are two big advantages in block-level that are missed at sitemap 
level:

 1) transparent versioning
 2) solid isolation
Everybody knows that composition should be favored over inheritance.

Make it *easy* for people to abuse something, and they will. massively.

actions, resources, and now inheritance. I fear abuse.

Blocks are an obstacle, yes, but a little one and one that forces 
people to think.

I know you can't force people to think. but if you are a cocoon user 
you are used to be guided a little bit. perl users, for example, 
wouldn't like cocoon because it's too rigid.

I don't want to make it any more rigid, but I don't want to make it any 
more loose either, this is why inheritance should go along with a 
compositional design, not otherwise.

but I understand this is a subjective thing, so, we might want to hear 
other bells on this.

--
Stefano.

Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching Matcher.java CookieMatcher.java)

2003-10-27 Thread Sylvain Wallez

Berin Loritsch wrote:

Geoff Howard wrote:

[EMAIL PROTECTED] wrote:

ghoward 2003/10/25 14:59:50

 Modified:src/java/org/apache/cocoon/matching Matcher.java
   CookieMatcher.java
 Log:
 start fortressizing Matchers.  lots of open questions already,  so 
I'll pause here.


I'm hoping someone with more confidence in the changes needed can 
check out the simple changes below.  Such a paradigm shift to give up 
the marker interfaces (and I'm mourning the loss of content assist.  
Don't suppose an eclipse plugin for meta info yet?)


Content assist?

Eclipse plugin:  not at this time.

Open questions:
- What do sitemap components get for @x-avalon-info?  A new made up 
string like cookie-matcher?  The @name/type from the default sitemap 
in 2.1?


The @x-avalon-info name="cookie-matcher" line lets you define your 
components
like this:


  configuration



I must say that I'm not really convinced by this notation, as it makes 
finding the various implementations or a service in an xconf file 
somehow difficult, and even make the xconf file hardly understandable 
unless you know the shortname for each and every service implementation.

In the ECM, the hints were visible only _within_ a selector defining the 
scope of these hints, e.g.:

 ...
 ...


If Fortress configurations are flat configurations with hints (or 
x-avalon-info), knowing what kind of component an element declares can 
be tricky. Furthermore, there's a non negligible probability of name 
clashes on large systems.

Something that would be more readable IMO, is to have the hint as an 
additional attribute, e.g.
...
...

and accordingly:
...
What this means is that the @x-avalon-info should be considered 
differently for service interfaces (element name) and for classes 
("type" attribute).

It takes away the need for a separate ROLES file.

- Will this mean we no longer have to declare sitemap components in 
the sitemap?


More it means that there is no reason to have a ROLES file, which also 
means taht you can incorporate any component into Cocoon using a 
friendly configuration name without resorting to specifying user roles 
files or even internal roles files.

- What about other lifecycle interfaces like: Contextualizable, 
Parameterizable, Disposable?


They haven't changed.  They actually have a reason to exist.  They 
provide information or invoke an event on the component--unlike the 
marker interfaces that did nothing but mess with the class hierarchy.


Sylvain

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

RE: [proposal] Doco

2003-10-27 Thread Robert Koberg



> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 6:06 AM
> To: James Developers List
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; lenya-
> [EMAIL PROTECTED]
> 
> 
> On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:
> 
> >> He's not questioning whether it's encrypted.  His point is, doco sends
> >> an email to an address, and you respond.  It gives very little
> >> control,
> >> even if there is a compromise.
> >
> > AIUI, the proposed solution would allow "anyone" to edit content, and
> > contribute it as a "patch".  Content could include defacements,
> > changes to
> > .htaccess, and CGI scripts.
> 
> nah, dude, look: doco has a very precise editing access point. You can
> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts,
> servlet upload, sql injection, cross-site-scripting, and you next
> favorite attack will NOT work because the system prevents it by design
> [not saying it cannot happen, but if it does it's a bug, not a faulty
> design]

FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even
better?, schema/dtd validation). If it fails, it doesn't even enter the
approval process. Perhaps a notification email is sent describing that an
invalid submittal was sent. The user is returned an error page saying the
post was rejected, in case it was just a mistake.

On another note, can images/PDFs/other-binaries be uploaded?

-Rob

RE: [Portal] future and design questions

2003-10-27 Thread ĎURDINA Michal

Title: RE: [Portal] future and design questions






(resending because of some delivery problems)


Thank you for prompt answers!


Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment.

For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take?

Thank you,

Michal


> -Original Message-

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]

> Sent: Monday, October 27, 2003 11:57 AM

> To: [EMAIL PROTECTED]

> Subject: RE: [Portal] future and design questions

> 

> 

> > ĎURDINA Michal wrote:

> >

> > Hello!

> > Right now I am in process of evaluating available portal solutions.

> > Because I am big cocoon enthusiast I took a deeper look 

> into the cocoon

> > portal-fw and portal blocks.

> The portal block is a newer implementation that is in general 

> more flexibel

> than the old one but currently lacks for example 

> administration tools etc.

> 

> >

> > I would try to summarise the main features I found when 

> played with both

> > portal-framework and portal engine. Please correct me if I am wrong:

> >

> > - both solutions aim mostly to implement portlet container 

> capabilities

> > - both solutions are quite similar from the view of sitemap 

> configuration

> and coplet features

> > - coplets provide XML feeds and are realized by sitemap 

> pipelines (local)

> or by accessing any

> >   source in the internet (defined by uri)

> > - authentification is done by authentification-fw but this 

> is not required

> as this can be

> >   replaced by other solution i.e. by container managed security

> > 

> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106703524221219&w=2)

> Yes, but this is only true for the portal block; the 

> portal-fw block is tied

> to the

> authentication-fw. Although it is possible with some trick to use a

> different

> approach with the portal-fw as well.

> 

> > - user's settings are stored in files (by means of sourcewriter

> transformer) but they can

> >   be persisted by any data store by means of specialized 

> transformers

> > - final HTML look is created by xsl stylesheet applied 

> after syndicating

> all coplets in layout template

> > - other clients (PDA, WAP) can be handled by applying different xsl

> stylesheet and targeting required markup

> > - JSR-168 portlet container behaviour will be implemented 

> in portal-engine

> block to support

> >   3rd party portlet implementations

> 

> > I still have some questions where I am not sure about answers:

> > - what will be (or is) the main difference of current 

> portal-framework and

> new portal engine?

> >   What were the main issues that caused rewrite of existing 

> portal-fw to

> portal engine?

> Mainly flexibility, like choosing different authentication 

> mechanism etc and

> implementing

> the JSR-168 which will only happen for the portal block 

> (unless someone

> steps in and

> does it for the portal-fw as well, which would be very very tricky).

> 

> > - what exactly will be implemented from JSR-168 spec to 

> portal engine,

> what components will

> >   then be still used from cocoon?

> Good question, I'm wondering this myself these days :) Now, 

> currently the

> JSR-168 defines

> only portlets, but not the portlet container itself (only part of the

> behaviour of the

> container), so it might be that the portal engine of Cocoon 

> stays the same.

> But you

> will have the abilitiy to use a JSR-168 portlet instead of a pipeline.

> 

> > - what future do you see for cocoon as a portal framework 

> when JSR-168

> compliant containers

> >   will come out (i.e. Jakarta Pluto) and what part of 

> portal application

> lifecycle should

> >    then cocoon cover?

> I honestly don't know - this is something the users will 

> decide. Now, I hope

> that the

> cocoon portal engine will be JSR-168 compliant as well (soon), so when

> developing portlets it

> doesn't matter if you choose Cocoon or Pluto or Jetspeed or 

> whatever. At

> least that's

> the theory which I think will not always be the practice: 

> When you develop a

> portlet you

> need functionality and in some cases you find this 

> functionality in your

> portlet container

> (in Cocoon, in Jetspeed etc.) and you will use this. From 

> that point on

> you're

> tied to that container. But the JSR-168 helps here a lot.

> 

> Anyway, personally, I think Cocoon is a good base for portal 

> applications as

> it

> provides so many good concepts, like the avalon based 

> arch

RE: [Portal] future and design questions

2003-10-27 Thread ĎURDINA Michal

Title: RE: [Portal] future and design questions






Thank you for prompt answers!


Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment.

For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take?

Thank you,

Michal


> -Original Message-

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]

> Sent: Monday, October 27, 2003 11:57 AM

> To: [EMAIL PROTECTED]

> Subject: RE: [Portal] future and design questions

> 

> 

> > ĎURDINA Michal wrote:

> >

> > Hello!

> > Right now I am in process of evaluating available portal solutions.

> > Because I am big cocoon enthusiast I took a deeper look 

> into the cocoon

> > portal-fw and portal blocks.

> The portal block is a newer implementation that is in general 

> more flexibel

> than the old one but currently lacks for example 

> administration tools etc.

> 

> >

> > I would try to summarise the main features I found when 

> played with both

> > portal-framework and portal engine. Please correct me if I am wrong:

> >

> > - both solutions aim mostly to implement portlet container 

> capabilities

> > - both solutions are quite similar from the view of sitemap 

> configuration

> and coplet features

> > - coplets provide XML feeds and are realized by sitemap 

> pipelines (local)

> or by accessing any

> >   source in the internet (defined by uri)

> > - authentification is done by authentification-fw but this 

> is not required

> as this can be

> >   replaced by other solution i.e. by container managed security

> > 

> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106703524221219&w=2)

> Yes, but this is only true for the portal block; the 

> portal-fw block is tied

> to the

> authentication-fw. Although it is possible with some trick to use a

> different

> approach with the portal-fw as well.

> 

> > - user's settings are stored in files (by means of sourcewriter

> transformer) but they can

> >   be persisted by any data store by means of specialized 

> transformers

> > - final HTML look is created by xsl stylesheet applied 

> after syndicating

> all coplets in layout template

> > - other clients (PDA, WAP) can be handled by applying different xsl

> stylesheet and targeting required markup

> > - JSR-168 portlet container behaviour will be implemented 

> in portal-engine

> block to support

> >   3rd party portlet implementations

> 

> > I still have some questions where I am not sure about answers:

> > - what will be (or is) the main difference of current 

> portal-framework and

> new portal engine?

> >   What were the main issues that caused rewrite of existing 

> portal-fw to

> portal engine?

> Mainly flexibility, like choosing different authentication 

> mechanism etc and

> implementing

> the JSR-168 which will only happen for the portal block 

> (unless someone

> steps in and

> does it for the portal-fw as well, which would be very very tricky).

> 

> > - what exactly will be implemented from JSR-168 spec to 

> portal engine,

> what components will

> >   then be still used from cocoon?

> Good question, I'm wondering this myself these days :) Now, 

> currently the

> JSR-168 defines

> only portlets, but not the portlet container itself (only part of the

> behaviour of the

> container), so it might be that the portal engine of Cocoon 

> stays the same.

> But you

> will have the abilitiy to use a JSR-168 portlet instead of a pipeline.

> 

> > - what future do you see for cocoon as a portal framework 

> when JSR-168

> compliant containers

> >   will come out (i.e. Jakarta Pluto) and what part of 

> portal application

> lifecycle should

> >    then cocoon cover?

> I honestly don't know - this is something the users will 

> decide. Now, I hope

> that the

> cocoon portal engine will be JSR-168 compliant as well (soon), so when

> developing portlets it

> doesn't matter if you choose Cocoon or Pluto or Jetspeed or 

> whatever. At

> least that's

> the theory which I think will not always be the practice: 

> When you develop a

> portlet you

> need functionality and in some cases you find this 

> functionality in your

> portlet container

> (in Cocoon, in Jetspeed etc.) and you will use this. From 

> that point on

> you're

> tied to that container. But the JSR-168 helps here a lot.

> 

> Anyway, personally, I think Cocoon is a good base for portal 

> applications as

> it

> provides so many good concepts, like the avalon based 

> architecture, the

> sitemap,

> the processing pipe

Re: Questions about Meta Info

2003-10-27 Thread Berin Loritsch

Stephen McConnell wrote:


Berin:

What is you plan concerning migration to the @avalon tags?
http://avalon.apache.org/meta/tools/tags/
Take it one step at a time.

1) Get Cocoon 2.2 to a workable state with Fortress as is.
2) Finish upgrades to Fortress to allow meta tags integration.
3) With all the meta info already available for each component
   finish the upgrade process seamlessly.
At that time, there should be far less dependence on any one container
(though there still will be some).
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin

Re: [proposal] Doco

2003-10-27 Thread Stefano Mazzocchi

On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:

He's not questioning whether it's encrypted.  His point is, doco sends
an email to an address, and you respond.  It gives very little 
control,
even if there is a compromise.
AIUI, the proposed solution would allow "anyone" to edit content, and
contribute it as a "patch".  Content could include defacements, 
changes to
.htaccess, and CGI scripts.
nah, dude, look: doco has a very precise editing access point. You can 
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts, 
servlet upload, sql injection, cross-site-scripting, and you next 
favorite attack will NOT work because the system prevents it by design 
[not saying it cannot happen, but if it does it's a bug, not a faulty 
design]

So long as we can maintain oversight, this is
OK.  But if someone can spoof the oversight, then I would be concerned.
I would *NEVER* propose a system where the users can inject an 
.htaccess file, even thru approuval. One single oversight mistake and 
infrastructure@ shuts us down in half a second (if they ever allow the 
system to run, and I personally wouldn't).

The unique and only security concern here is defacement.

I am not trying to shoot this idea down.  I think it is a good thing 
to do,
and will really help.
I really appreciate your concerns and, please, keep in mind that I read 
and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip 
stack [also, IMAP over compressed SSH is orders of magnitude faster 
when you sit in italy and your imap server is in london! ;-)]

Anyway, here is a potential attack:

Doco sends email to james (localhost).
James multiplexes the email to the moderators (vanilla SMTP)
the attacker sniffs the continuation-ID
replies with the sniffed continuation-ID
James calls Doco and restarts the workflow
Doco sends back email logging the approuval
Potential sniffing places are:
1) right after the doco box (FYI, moof is located at Apple, nagoya at 
Sun)
2) right before the mail server of the moderator or by people who have 
enough priviledges on the moderator mail server.

The above attack is plausible and it would allow the attacker to get 
stuff in the repository, but *NOT* to prevent other moderators to see 
that this content has been approuved. [that would require substantial 
forging of the output stream... possible as well, but much harder to 
achieve]

The other moderators would see it as a mistake and get there fixing it 
before the next site update.

Keep in mind that there are *two* 12 hour stages, so, even if the 
attacker attacks right before the first staging (the forrestbot 
execution), the moderators have 12 hours to understand that something 
was wrong and login to fix things before the other stage (rsync from 
minotaur) takes place.

I think you proposed to use SMTP over SSL for mail relay, that would 
reduce the ability of somebody to prevent sniffing the continuation-ID 
and provide that attack.

I do agree it would help reducing the risk, but would all moderator's 
SMTP server support that? [keep in mind that a sniffer could understand 
the list of moderators just by watching email outgoing traffic, even if 
encrypted, by comparing with the list of users on the mail lists]

Another solution is to force moderators to digitally sign their email, 
but this would require a much more intrusive setup.

At the end, I don't think anybody would do such an attack since:

 1) it can't be proved that it was an attack (we can always say it was 
a mistake of the moderators), so you can't go around feeling proud of 
it or impressing friends of the cracker scene [ego is probably 99% of 
the reasons to deface a web site]

 2) the attacker cannot stop others from keeping oversight on what was 
approuved (doco will send email *after* the moderation to keep 
oversight of everthing that happened)

 3) if we use the lazy consensus moderation method (require 3 accept 
and no reject), the attack is just as easy, but the chance that the 
moderator that the attacker would *fake* is offline for 24 hours and 
cannot yell "WTF, I didn't do it" at the moderator list is much less

So, adding SSL relay wouldn't hurt, but wouldn't help much either since 
we can't force moderators to have a mail server that accepts that kind 
of relay (don't even know if mine does!)

at least, this is MHO.

--
Stefano.

Re: Questions about Meta Info

2003-10-27 Thread Stephen McConnell



Berin Loritsch wrote:

Geoff Howard wrote:

[EMAIL PROTECTED] wrote:

ghoward 2003/10/25 14:59:50

 Modified:src/java/org/apache/cocoon/matching Matcher.java
   CookieMatcher.java
 Log:
 start fortressizing Matchers.  lots of open questions already,
 so I'll pause here.
 

I'm hoping someone with more confidence in the changes needed can 
check out the simple changes below.  Such a paradigm shift to give up 
the marker interfaces (and I'm mourning the loss of content assist.  
Don't suppose an eclipse plugin for meta info yet?)


Content assist?

Eclipse plugin:  not at this time.

Open questions:
- What do sitemap components get for @x-avalon-info?  A new made up 
string like cookie-matcher?  The @name/type from the default sitemap 
in 2.1?


The @x-avalon-info name="cookie-matcher" line lets you define your 
components
like this:


  configuration

It takes away the need for a separate ROLES file. 


Berin:

What is you plan concerning migration to the @avalon tags?
http://avalon.apache.org/meta/tools/tags/
Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]

Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching Matcher.java CookieMatcher.java)

2003-10-27 Thread Berin Loritsch

Geoff Howard wrote:

[EMAIL PROTECTED] wrote:

ghoward 2003/10/25 14:59:50

 Modified:src/java/org/apache/cocoon/matching Matcher.java
   CookieMatcher.java
 Log:
 start fortressizing Matchers.  lots of open questions already,
 so I'll pause here.
 

I'm hoping someone with more confidence in the changes needed can check 
out the simple changes below.  Such a paradigm shift to give up the 
marker interfaces (and I'm mourning the loss of content assist.  Don't 
suppose an eclipse plugin for meta info yet?)
Content assist?

Eclipse plugin:  not at this time.

Open questions:
- What do sitemap components get for @x-avalon-info?  A new made up 
string like cookie-matcher?  The @name/type from the default sitemap in 
2.1?
The @x-avalon-info name="cookie-matcher" line lets you define your components
like this:

  configuration

It takes away the need for a separate ROLES file.

- Will this mean we no longer have to declare sitemap components in 
the sitemap?
More it means that there is no reason to have a ROLES file, which also
means taht you can incorporate any component into Cocoon using a friendly
configuration name without resorting to specifying user roles files or
even internal roles files.
- What about other lifecycle interfaces like: Contextualizable, 
Parameterizable, Disposable?
They haven't changed.  They actually have a reason to exist.  They provide
information or invoke an event on the component--unlike the marker interfaces
that did nothing but mess with the class hierarchy.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin

InspectableSource

2003-10-27 Thread Unico Hommes


I am looking into extending SourcePropsWritingTransformer to also be
able to remove SourceProperties. One thing I need to decide is how to
access SourceProperties now that we have SourceDescriptor interface.
>From SourceDescriptionGenerator I can see that the distinction between
SourceInspector and InspectableSource was mainly that of computed vs.
modifiable. With the new SourceDescriptor interface this distinction
does not exist anymore and so we have in fact two interfaces with the
same functiality. We need to decide what to do with that.

I see three possibilities:

1) keep InspectableSource interface. SourceProperty related sitemap
components talk with both interfaces to do their job, favoring
InspectableSource if the Source implements it else falling back on
SourceDescriptor.

Pro: - SourceProperty related coding can be done directly onto the
Source.
Con: - Confusing what properties are managed where
 - Clients have two interfaces to choose from

2) deprecate InspectableSource in favor of SourceDescriptor and migrate
SourceProperty related sitemap components to use the SourceDescriptor
interface instead, taking care for backwards compatibility with Sources
that haven't moved away from SourceInspector yet.

Pro: - Client need to use only one interface
Con: - Need to refactor some things
 - SourceProperties are not directly available on Source.

3) make SoureProperty related sitemap components talk directly to
InspectableSources only. Create a Source delegate - callit
RepositorySource - that adds inspectability to arbitrary sources by
talking to SourceDescriptors.

Pro: - One interface
 - SourceProperties directly visible on Source

Ok, I think I just answered my own question ;-D, but I'd be interested
in others' opinions.

What do others think?

-- Unico

[Fwd: Documenting the TreeBuilder stuff]

2003-10-27 Thread Berin Loritsch

I sent thisto the wrong place...

--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin
--- Begin Message ---
I started putting in some information that would at least document the
interfaces alot better based on what I saw on the list so far.  I put
Each type of ProcessingNodeBuilder or ProcessingNode interface is nicely
separated, and they do one thing and one thing well.  I really don't have
any issues with that at all.
The TreeBuilder interface is much less straightforward.  It mixes the
concerns of the meta information for the language type captured in the
config file with a bunch of processing things.  I think we should look
at separating the interface into more logical units.  That would help
make it more understandable.
For instance, we have a TreeBuilder which represents the language.  That is
nice and good.  However, IMO it has one responsibility: to create
ProcessingNodeBuilders for a particular file.  The root ProcessingNodeBuilder in
turn should have the responsibility of creating the ProcessingTree.
The ProcessingTree in turn is used directly to process requests.
So, in essence, we have a couple of roles here--which might even simplify
the implementation a bit:
* TreeBuilder: Create a ProcessingNodeBuilder tree.  (what goes on in the
   implementation should not be exposed in the interface)
* RootProcessingNodeBuilder: Create a Processor (which is implemented by
 the ProcessingNodes)
* Processor:  The actual runtime system we use (the assembled sitemap so
  to speak).
Currently, it looks like there are implementation details exposed in the
TreeBuilder, mixed with runtime details exposed for the processing node
builders.
I dunno, though.  Do we want the TreeBuilder to only expose an interface
to get a particular Processor based on a URI???  I'm undecided.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--- End Message ---

DO NOT REPLY [Bug 23855] - [PATCH] LDAPTransformer bug fix

2003-10-27 Thread 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23855

[PATCH] LDAPTransformer bug fix

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

RE: [Portal] future and design questions

2003-10-27 Thread Carsten Ziegeler

> ĎURDINA Michal wrote:
>
> Hello!
> Right now I am in process of evaluating available portal solutions.
> Because I am big cocoon enthusiast I took a deeper look into the cocoon
> portal-fw and portal blocks.
The portal block is a newer implementation that is in general more flexibel
than the old one but currently lacks for example administration tools etc.

>
> I would try to summarise the main features I found when played with both
> portal-framework and portal engine. Please correct me if I am wrong:
>
> - both solutions aim mostly to implement portlet container capabilities
> - both solutions are quite similar from the view of sitemap configuration
and coplet features
> - coplets provide XML feeds and are realized by sitemap pipelines (local)
or by accessing any
>   source in the internet (defined by uri)
> - authentification is done by authentification-fw but this is not required
as this can be
>   replaced by other solution i.e. by container managed security
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106703524221219&w=2)
Yes, but this is only true for the portal block; the portal-fw block is tied
to the
authentication-fw. Although it is possible with some trick to use a
different
approach with the portal-fw as well.

> - user's settings are stored in files (by means of sourcewriter
transformer) but they can
>   be persisted by any data store by means of specialized transformers
> - final HTML look is created by xsl stylesheet applied after syndicating
all coplets in layout template
> - other clients (PDA, WAP) can be handled by applying different xsl
stylesheet and targeting required markup
> - JSR-168 portlet container behaviour will be implemented in portal-engine
block to support
>   3rd party portlet implementations

> I still have some questions where I am not sure about answers:
> - what will be (or is) the main difference of current portal-framework and
new portal engine?
>   What were the main issues that caused rewrite of existing portal-fw to
portal engine?
Mainly flexibility, like choosing different authentication mechanism etc and
implementing
the JSR-168 which will only happen for the portal block (unless someone
steps in and
does it for the portal-fw as well, which would be very very tricky).

> - what exactly will be implemented from JSR-168 spec to portal engine,
what components will
>   then be still used from cocoon?
Good question, I'm wondering this myself these days :) Now, currently the
JSR-168 defines
only portlets, but not the portlet container itself (only part of the
behaviour of the
container), so it might be that the portal engine of Cocoon stays the same.
But you
will have the abilitiy to use a JSR-168 portlet instead of a pipeline.

> - what future do you see for cocoon as a portal framework when JSR-168
compliant containers
>   will come out (i.e. Jakarta Pluto) and what part of portal application
lifecycle should
>then cocoon cover?
I honestly don't know - this is something the users will decide. Now, I hope
that the
cocoon portal engine will be JSR-168 compliant as well (soon), so when
developing portlets it
doesn't matter if you choose Cocoon or Pluto or Jetspeed or whatever. At
least that's
the theory which I think will not always be the practice: When you develop a
portlet you
need functionality and in some cases you find this functionality in your
portlet container
(in Cocoon, in Jetspeed etc.) and you will use this. From that point on
you're
tied to that container. But the JSR-168 helps here a lot.

Anyway, personally, I think Cocoon is a good base for portal applications as
it
provides so many good concepts, like the avalon based architecture, the
sitemap,
the processing pipelines, flow, blocks (with 2.2), form handling frameworks
etc
that make developing complex applications alot easier. And you can use all
these nice little things in your portlets as well.

HTH
Carsten

[FYI] New Cocoon Article

2003-10-27 Thread Michael Melhem




FYI, managed to get a new Cocoon Article I wrote 
posted on developer.com. It can be found at  http://www.developer.com/java/ent/article.php/3098661 if 
anyone is interested.
 
Cheers,
Michael

Re: repository block (was Re: [RT] Source extensions)

2003-10-27 Thread Guido Casper

Unico Hommes <[EMAIL PROTECTED]> wrote:
> Guido Casper wrote:
>>
>>
>> The only change to your proposal to allow for both behaviours would
>> be to not prohibit ambiguities.
>>
>> Deal? :-)
>>
>
> Yes, that was my bad. It had been a long day.

No no, you were the one opening my (and hopefully other's) eyes how
powerful all this is :-)

>
>>>
>>> This would handle for example the situation we currently have with
>>> the GIF- and JPEGSourceInspectors that actually deal with the same
>>> type of properties but define separate namespaces for them
>>> respectively. I'd like to instead use the same property namespace
>>> for these: http://apache.org/cocoon/inspector/image/1.0 .
>>
>> Exactly. An example where dynamic behaviour would be beneficial.
>>
>
> So, can I make this change then? Making the two use the same
> namespace I mean.

+1 from me

>
>>> ...
>
> The thing is that, if you allow inspectors to handle arbitrary
> property types, you need to communicate certain information between
> inspectors.
>
> Consider a propfind for the image:width property on a source.
> Currently there are two inspectors that deal with this property.
> However it depends on the type of the source whether one, the other
> or neither will be able to determine the property value. What if you
> tried to get this property on a source of mime type text/xml? The
> manager will loop thru the set of inspectors that assert they handle
> properties like that. First comes GIFSourceInspector, then comes
> JPEGSourceInspector. Both return a value of null since the mime type
> is beyond their epistemic scope. Next in the list is an inspector
> that can in principal handle any type because it just stores them as
> name-value pairs say. If this inspector now chooses to query for the
> image:width property that would certainly be undesirable behavior.
>
> So how to solve that?

One can blame the one trying to read image:width on a XML resource :-)

I can see the problem of several inspectors not checking the namespace.
Maybe the implementor should make sure there is no more than 1 of them
(but then again you have to ensure the correct sequence of calling (the
same applies for setting props)). Maybe another mechanism for ensuring
more robustness is needed. Hmm ... keeping on thinking about that.

Hope I can work on it for my next project (don't know yet) and gather
some more experiences.

>
> My idea to guard against unexpected performance hits like this was to
> require each inspector to know in advance what property types they
> deal with. Making the requirement explicit by defining a method by
> which they expose their respective property types. This would impact
> as you say the flexibility in that the application must in advance
> know what properties a client is going to use. And so we came up with
> a wildcard syntax that would be tried if no exact match was available.
>
> But I don't really like this. It complicates things too much.
>
> So now I think, until we come up with something better, the best way
> for the moment is to just let the inspectors decide for themselves
> like they did before. If they decide to just try each and every
> property request they get, then they must accept the impact this will
> have on the overall performance of the system. The responsibility
> lies with them. I'll provide an abstract base class that can
> configure what properties the concrete inspector will deal with.

Thanks a lot for your work.

Guido

Cocoon survey

2003-10-27 Thread Wolfgang . Maass

Dear Cocoon community member,

just a short notice on the current status of the survey.

Currently about 20 developers (referring to their responses they appear to
be very active in the Cocoon community) have replied which is a good ratio.

Nevertheless for a clear picture of the Cocoon developer community it is
necessary to collect at least 40-50 responses.

Therefore I would like to encourage those of you who haven't replied yet to
do so till the 1st of November.

This encouragement is addressed to all of you including those who are young
in the community, contribute documentation or code even on a small scale.

Thanks a lot

Wolfgang Maass


- Weitergeleitet von Wolfgang Maass/MCM/UNISG/CH am 27.10.2003 09:50
-
|-+--->
| |   Wolfgang Maass  |
| |   |
| |   03.10.2003 18:57|
| |   |
|-+--->
  
>--|
  |
  |
  |An:  [EMAIL PROTECTED]  
  |
  |Kopie:  
  |
  |Thema:   Cocoon survey  
  |
  
>--|



Dear Cocoon community member,

As indicated on the dev mailing list, the PMC agreed to run a survey under
the direction of the =mcminstitute of the University of St. Gallen.

With this survey we will investigate the organisational structure of the
Cocoon developer community in detail. Results will be open to all members
and will be published by the Cocoon mailing lists.

All personal data will be treated strictly confidential. Only aggregated
data will be published.

This survey can be accessed until the 17th of October 2003 by the following
URL:

http://www.mcm.unisg.ch/org/mcm/survey_wma.nsf/web.login

Because we omitted to use logins, we would kindly ask you to work through
this questionaire just one time from the start to the end in one session.

Thank you very much for your support and see you in Ghent

Wolfgang Maass

=mcminstitute, University of St. Gallen

Re: Woody BinaryWidget

2003-10-27 Thread Upayavira

Gunter D'Hondt wrote:

Upayavira,

Don't worry I can wait (better that than making the same again). 
What datatype have you used? A composite datatype with the byte-array
and the filename as string?
 

At present it returns an InputStream to the part (either in memory or on 
disc). Sylvain suggested making it return the Part, we can discuss that 
when I return from time away (computer is being switched off straight 
after this mail!)

Regards, Upayavira

Regards,
Gunter D'Hondt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Upayavira
Sent: maandag 27 oktober 2003 9:47
To: [EMAIL PROTECTED]
Subject: Re: Woody BinaryWidget
Gunter D'Hondt wrote:

 

Hi,

I was thinking of making a page where people can upload a file but I 
was wondering how to do that with Woody. For the layout (inputfield 
with
"Browse"-button) a new widget can be made and the datatype should be a
byte-array and a filename?

Any thought on this?
Is there already a list/doc that describes all available widgets and
datatypes?
Gunter D'Hondt
www.sofico.info


   

I've got an Upload widget working and almost ready to commit, but won't 
be able to do so straight away as I'm about to go away for a week.

If you can wait, I can finish that and commit it.

Regards, Upayavira

RE: Woody BinaryWidget

2003-10-27 Thread Gunter D'Hondt

Upayavira,

Don't worry I can wait (better that than making the same again). 
What datatype have you used? A composite datatype with the byte-array
and the filename as string?

Regards,
Gunter D'Hondt


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Upayavira
Sent: maandag 27 oktober 2003 9:47
To: [EMAIL PROTECTED]
Subject: Re: Woody BinaryWidget


Gunter D'Hondt wrote:

>Hi,
>
>I was thinking of making a page where people can upload a file but I 
>was wondering how to do that with Woody. For the layout (inputfield 
>with
>"Browse"-button) a new widget can be made and the datatype should be a
>byte-array and a filename?
>
>Any thought on this?
>Is there already a list/doc that describes all available widgets and
>datatypes?
>
>Gunter D'Hondt
>www.sofico.info
>
>
>  
>
I've got an Upload widget working and almost ready to commit, but won't 
be able to do so straight away as I'm about to go away for a week.

If you can wait, I can finish that and commit it.

Regards, Upayavira

Re: Woody BinaryWidget

2003-10-27 Thread Upayavira

Gunter D'Hondt wrote:

Hi,

I was thinking of making a page where people can upload a file but I was
wondering how to do that with Woody. For the layout (inputfield with
"Browse"-button) a new widget can be made and the datatype should be a
byte-array and a filename?
Any thought on this? 
Is there already a list/doc that describes all available widgets and
datatypes?

Gunter D'Hondt 
www.sofico.info

 

I've got an Upload widget working and almost ready to commit, but won't 
be able to do so straight away as I'm about to go away for a week.

If you can wait, I can finish that and commit it.

Regards, Upayavira

[BUG] CachingPointProcessingPipeline is Configurable and Parameterizable

2003-10-27 Thread Carsten Ziegeler

The CachingPointProcessingPipeline is Configurable and Parameterizable
which is afaik not allowed. I think, this was checked in an earlier
version of ECM but seems to be not checkec anymore.

As the base class of the processing pipeline is Parameterizable and
all other pipeline implementations use this interface, it seems
that Parameterizable is the way to go.

What do you think?

Carsten

[Portal] future and design questions

2003-10-27 Thread ĎURDINA Michal

Title: [Portal] future and design questions






Hello!


Right now I am in process of evaluating available portal solutions. Because I am big cocoon enthusiast I took a deeper look into the cocoon portal-fw and portal blocks. 

I would try to summarise the main features I found when played with both portal-framework and portal engine. Please correct me if I am wrong:

- both solutions aim mostly to implement portlet container capabilities

- both solutions are quite similar from the view of sitemap configuration and coplet features

- coplets provide XML feeds and are realized by sitemap pipelines (local) or by accessing any source in the internet (defined by uri)

- authentification is done by authentification-fw but this is not required as this can be replaced by other solution i.e. by container managed security 

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

- user's settings are stored in files (by means of sourcewriter transformer) but they can be persisted by any data store by means of specialized transformers

- final HTML look is created by xsl stylesheet applied after syndicating all coplets in layout template

- other clients (PDA, WAP) can be handled by applying different xsl stylesheet and targeting required markup

- JSR-168 portlet container behaviour will be implemented in portal-engine block to support 3rd party portlet implementations

I still have some questions where I am not sure about answers:

- what will be (or is) the main difference of current portal-framework and new portal engine? What were the main issues that caused rewrite of existing portal-fw to portal engine?

- what exactly will be implemented from JSR-168 spec to portal engine, what components will then be still used from cocoon?

- what future do you see for cocoon as a portal framework when JSR-168 compliant containers will come out (i.e. Jakarta Pluto) and what part of portal application lifecycle should then cocoon cover?

Thanks for your answers and for good job done on cocoon!


Michal


-- MisoD --

Michal Durdina - [EMAIL PROTECTED] 

ASSET Soft a.s.,

Kosicka 56, Bratislava, 821 08

Slovakia, Europe

Woody BinaryWidget

2003-10-27 Thread Gunter D'Hondt

Hi,

I was thinking of making a page where people can upload a file but I was
wondering how to do that with Woody. For the layout (inputfield with
"Browse"-button) a new widget can be made and the datatype should be a
byte-array and a filename?

Any thought on this? 
Is there already a list/doc that describes all available widgets and
datatypes?

Gunter D'Hondt 
www.sofico.info

Antwort: Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl PartSource.java PartSourceFactory.java

2003-10-27 Thread volker . schmitt


Hi Geoff,

I think the reason is, that the PartSourceFactory isn't ThreadSafe. So
every time you access a PartSourceFactory a new Component is created and
the contextualize Method is called.
Calling "this.objectModel = ContextHelper.getObjectModel(context)" inside
the "contextualize"-Method can't work, because contextualize is called only
once. You need to call "ContextHelper.getObjectModel(context)" inside the
actual Thead, instead you don't get the right objectModel.

My proposal is change getSource to:

public Source getSource(String uri, Map parameters) throws IOException,
MalformedURLException
{
return new PartSource(uri, ContextHelper.getObjectModel(this.context));
}

Volker




Oh, by the way - when I was testing this I traced things through a few
times with the debugger and found that contextualize() is being called
twice for each request.  Is that expected?  Is there any conceivable
mis-coding or mis-configuration of the component that could cause this?

Geoff

[EMAIL PROTECTED] wrote:

>ghoward 2003/10/25 15:31:39
>
>  Modified:src/java/org/apache/cocoon/components/source/impl
>PartSource.java PartSourceFactory.java
>  Log:
>  use contextualize instead of static
>
>  CocoonComponentManager.getCurrentEnvironment()
>
>
>
>
>  Revision  ChangesPath
>  1.2   +2 -7
cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSource.java

>
>  Index: PartSource.java
>  ===
>  RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSource.java,v

>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- PartSource.java 23 Oct 2003 01:45:34 -  1.1
>  +++ PartSource.java 25 Oct 2003 22:31:39 -  1.2
>  @@ -58,8 +58,6 @@
>   import org.apache.cocoon.servlet.multipart.Part;
>   import org.apache.cocoon.environment.ObjectModelHelper;
>   import org.apache.cocoon.environment.Request;
>  -import org.apache.cocoon.components.CocoonComponentManager;
>  -
>   import java.net.MalformedURLException;
>   import java.util.Map;
>   import java.io.IOException;
>  @@ -91,7 +89,7 @@
>* @throws SourceException
>* @throws MalformedURLException
>*/
>  - public PartSource(String uri) throws MalformedURLException,
SourceException
>  + public PartSource(String uri, Map objectModel) throws
MalformedURLException, SourceException
>{
>// set the uri for use in getURI()
>this.uri = uri;
>  @@ -110,9 +108,6 @@
>
>// get the request parameter name: the bit after
://
>String location = uri.substring(position + 2);
>  -
>  - // get the object model from the component
managers curr env.
>  - Map objectModel =
CocoonComponentManager.getCurrentEnvironment().getObjectModel();
>
>// get the cocoon request from the object model.
>Request request =
ObjectModelHelper.getRequest(objectModel);
>
>
>
>  1.2   +16 -3
cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSourceFactory.java

>
>  Index: PartSourceFactory.java
>  ===
>  RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/PartSourceFactory.java,v

>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- PartSourceFactory.java23 Oct 2003 01:45:34 -
1.1
>  +++ PartSourceFactory.java25 Oct 2003 22:31:39 -
1.2
>  @@ -50,6 +50,9 @@
>   */
>   package org.apache.cocoon.components.source.impl;
>
>  +import org.apache.avalon.framework.context.ContextException;
>  +import org.apache.avalon.framework.context.Contextualizable;
>  +import org.apache.cocoon.components.ContextHelper;
>   import org.apache.excalibur.source.Source;
>   import org.apache.excalibur.source.SourceFactory;
>
>  @@ -62,16 +65,18 @@
>*
>* @author mailto:[EMAIL PROTECTED]">Paul Crabtree
>*/
>  -public class PartSourceFactory implements SourceFactory
>  +public class PartSourceFactory implements SourceFactory,
Contextualizable
>   {
>  - /*
>  + Map objectModel;
>  +
>  +/*
> * Returns a new [EMAIL PROTECTED] PartSource} based on the uri.
> *
> * @see
org.apache.excalibur.source.SourceFactory#getSource(java.lang.String,
java.util.Map)
> */
>   public Source getSource(String uri, Map parameters) throws
IOException, MalformedURLException
>   {
>  -return new PartSource(uri);
>  +return new PartSource(uri, this.objectModel);
>   }
>
>/**
>  @@ -82,5 +87,13 @@
>   public void release(Source source)
>   {
>   // Nothing to do here
>  +}
>  +
>  + /**
>  + * Get the objectModel from the Context
>  +

RE: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/acting LocaleAction.java SessionStateAction.java AbstractAction.java Action.java SessionInvalidatorAction.java RequestParameterExistsAction.java ClearPersistentStoreAction.java RequestParamAction.java

2003-10-27 Thread Carsten Ziegeler

Gianugo Rabellino wrote:
> >   +import java.util.*;
> 
> Why this? I thought we agreed not to have "*" imports...
> 
Sorry, it's my default conf.
Did we agree on this? We agreed on so many coding standards and
three weeks later we agree on the opposite (like the "this.",
"super." etc. discussions). Sorry, but I never say/noticed
a discussion of the "import *".

Carsten

Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/acting LocaleAction.java SessionStateAction.java AbstractAction.java Action.java SessionInvalidatorAction.java RequestParameterExistsAction.java ClearPersistentStoreAction.java RequestParamAction.java SetCharacterEncodingAction.java AbstractMultiAction.java SessionValidatorAction.java ResourceExistsAction.java ClearCacheAction.java AbstractComplementaryConfigurableAction.java FormValidatorAction.java InputModuleAction.java SessionPropagatorAction.java SessionIsValidAction.java HelloAction.java HttpHeaderAction.java ServerPagesAction.java AbstractValidatorAction.java

2003-10-27 Thread Gianugo Rabellino

[EMAIL PROTECTED] wrote:
   1.6   +4 -12 
cocoon-2.2/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java
  
  Index: AbstractValidatorAction.java
  ===
  RCS file: /home/cvs/cocoon-2.2/src/java/org/apache/cocoon/acting/AbstractValidatorAction.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- AbstractValidatorAction.java	24 Sep 2003 21:26:51 -	1.5
  +++ AbstractValidatorAction.java	27 Oct 2003 07:28:26 -	1.6
  @@ -50,27 +50,19 @@
   */
   package org.apache.cocoon.acting;
   
  +import java.util.*;
Why this? I thought we agreed not to have "*" imports...

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

53 matches

Mail list logo