RE: [VOTE] Avoid checking in JavaDOCs into SVN
Pier Fumagalli wrote: [X] +1 take them out Carsten
Re: [VOTE] Avoid checking in JavaDOCs into SVN
[+1] +1 take them out [ ] 0 I don't care [ ] -1 no, leave them there -- David Crossley
Re: [VOTE] Avoid checking in JavaDOCs into SVN
Le 25 août 04, à 18:05, Pier Fumagalli a écrit : [X ] +1 take them out -Bertrand
Re: [VOTE] Avoid checking in JavaDOCs into SVN
On 25.08.2004 18:05, Pier Fumagalli wrote: [X] +1 take them out Jörg
[VOTE] Status of Portal blocks
We have currently two portal blocks: - the (old) portal-fw block: this is the first portal implementation that is used here and there. The development of this block stopped a long time ago; there were only a few bug fixes and nearly no commits in the last months. - the (new) portal block: this is a new portal implementation (with JSR-168 support blabla) that is already used quiet a lot. It is stable from a user point of view and it is improved continuously. The portal-fw block is marked as stable while the portal block is marked as unstable. I think it's time to change the status of the blocks, so I propose to: a) mark portal-fw as deprecated b) mark portal as stable Please cast your votes Carsten Carsten Ziegeler Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.net/weblogs/rael/
Re: [VOTE] Status of Portal blocks
On 26.08.2004 09:57, Carsten Ziegeler wrote: a) mark portal-fw as deprecated +1 b) mark portal as stable +1 Jörg
Re: [VOTE] Status of Portal blocks
On Thu, 26 Aug 2004, Carsten Ziegeler wrote: We have currently two portal blocks: - the (old) portal-fw block: this is the first portal implementation that is used here and there. The development of this block stopped a long time ago; there were only a few bug fixes and nearly no commits in the last months. - the (new) portal block: this is a new portal implementation (with JSR-168 support blabla) that is already used quiet a lot. It is stable from a user point of view and it is improved continuously. The portal-fw block is marked as stable while the portal block is marked as unstable. I think it's time to change the status of the blocks, so I propose to: a) mark portal-fw as deprecated Hmm.. deprecated mean Hey man, go change you portal as it will be removed in the future is this you want to signal? -0 b) mark portal as stable +1 -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [VOTE] Avoid checking in JavaDOCs into SVN
FYI: Done. Pier On 25 Aug 2004, at 17:05, Pier Fumagalli wrote: I'm rebuilding the site and javadocs, and I seriously fail the point of checking in generated javadocs... There are something like more than 5600 files, and my SVN is crashing... Plus, we're wasting resources for something that can be so easily generated (even on minotaur): # svn co 'http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/' cocoon # cd cocoon # ./build.sh javadocs # cp -R build/cocoon-*/javadocs/. /www/cocoon.apache.org/2.1/apidocs/. # chgrp -R cocoon /www/cocoon.apache.org/apidocs/ # chmod -R g+w /www/cocoon.apache.org/apidocs/ # Ok for the site, but the APIs, it's just a waste... [ ] +1 take them out [ ] 0 I don't care [ ] -1 no, leave them there Pier smime.p7s Description: S/MIME cryptographic signature
RE: [VOTE] Status of Portal blocks
Giacomo Pati wrote: a) mark portal-fw as deprecated Hmm.. deprecated mean Hey man, go change you portal as it will be removed in the future is this you want to signal? Yes :( The portal-fw is a nice portal framework, but the code is very very ugly (I know it 'cause I wrote it). The new portal block is (apart from tools) a 100% replacement which is even faster and consumes less memory. Deperecating does not mean removing and deprecating means that it is still supported. So if any bugs occur, we will fix them - but if you start a new project, you should use the new portal block; that's why I think we should deprecate the old one. Carsten
DO NOT REPLY [Bug 24647] - content-length in ResourceReader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24647. 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=24647 content-length in ResourceReader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-08-26 12:50 --- *** This bug has been marked as a duplicate of 25712 ***
DO NOT REPLY [Bug 25712] - [PATCH] ResourceReader does not support resumes/byteranges correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25712. 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=25712 [PATCH] ResourceReader does not support resumes/byteranges correctly [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-08-26 12:50 --- *** Bug 24647 has been marked as a duplicate of this bug. ***
Re: [VOTE] Status of Portal blocks
At 8/26/2004 12:57 AM, you wrote: a) mark portal-fw as deprecated b) mark portal as stable I am +1 to both of these - with a couple of caveats. 1. The old portal contains at least a minimal amount of portal administration functionality. The new portal contains nothing. 2. The new portal documentation is poor. We are currently trying to figure out how to heavily leverage it and there is no documentation on Aspects, rendering, when and how the various stylesheets are invoked and how they relate to the various portal.xml files. Currently, the only way to figure it out is to modify the sample portal in a piecemeal fashion and see what happens - and then look at the code to figure out why. This takes a LONG time. In short, the portal documentation on the web site needs to be improved to discuss some of the internals (especially since there are no administration tools).
Re: Improving portals block [was: Re: [VOTE] Status of Portal blocks]
Carsten Ziegeler wrote:
Ralph Goers wrote:
1. The old portal contains at least a minimal amount of
portal administration functionality. The new portal contains nothing.
Unfortunately this is true, but I'm really sure that soon
some tools for the new portal will appear and with a little
luck a real portal tool community will be established
improving this area.
2. The new portal documentation is poor. We are currently
trying to figure out how to heavily leverage it and there is
no documentation on Aspects, rendering, when and how the
various stylesheets are invoked and how they
relate to the various portal.xml files. Currently, the only
way to figure
it out is to modify the sample portal in a piecemeal fashion
and see what happens - and then look at the code to figure
out why. This takes a LONG time. In short, the portal
documentation on the web site needs to be improved to discuss
some of the internals (especially since there are no
administration tools).
Now, let me give the dumb open source answer (this is not
targetted at you, Ralph). Cocoon and the portal block are
open source. So, if something is missing or not the way you
like it etc., you can change it. This is usually how open
source works: someone has an itch and starts scratching
it - perhaps over time others help scratching ;)
So, comming back to the topic at hand: yes, the docs about
the portal are not perfect and I can only hope that they
will improve over time.
Documentation can grow in small steps: Each time someone
finds that an information is missing in the docs, she can
contribute a small patch with just this piece of information.
This only takes some minutes to do (ok, first you have to
find the information, but once you got it, providing the
patch is simple).
If something is unclear in the docs, ask and the docs
can be made more clear. And so on.
Mmmh... I'm not sure the scratch an itch pattern applies to docs.
With code, you start scratching because you need a new feature, and
since you need to write that new feature for your own need, you can with
not much additional cost share it with others.
With docs that lack the information you're need, you will dig in the
code and samples to find that information, and once you've found the
answer, your problem is solved. Writing docs requires the extra effort
of taking the time to share your findings with the community.
That certainly explains why our docs are so bad compared to all the
features Cocoon provides.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Improving portals block [was: Re: [VOTE] Status of Portal blocks]
Sylvain Wallez wrote: Mmmh... I'm not sure the scratch an itch pattern applies to docs. With code, you start scratching because you need a new feature, and since you need to write that new feature for your own need, you can with not much additional cost share it with others. With docs that lack the information you're need, you will dig in the code and samples to find that information, and once you've found the answer, your problem is solved. Writing docs requires the extra effort of taking the time to share your findings with the community. Exactly and my point is that this extra time is really, really not very much. You can simply write down your problem and the solution in a language that somehow looks like english (that's the way I write most times...) and file the patch. With this you help others and someday someone will help you. So it will pay back. That certainly explains why our docs are so bad compared to all the features Cocoon provides. :) Carsten
RE: [VOTE] Status of Portal blocks
On Thu, 26 Aug 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: a) mark portal-fw as deprecated Hmm.. deprecated mean Hey man, go change you portal as it will be removed in the future is this you want to signal? Yes :( The portal-fw is a nice portal framework, but the code is very very ugly (I know it 'cause I wrote it). The new portal block is (apart from tools) a 100% replacement which is even faster and consumes less memory. Deperecating does not mean removing and deprecating means that it is still supported. So if any bugs occur, we will fix them - but if you start a new project, you should use the new portal block; that's why I think we should deprecate the old one. If one deprecates something it suggests a replacement. IIRC the new portal lacks some administration tools which the old one has (user admin, etc.), right? So, what is your suggestion instead of using the old portal block than? -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RE: [VOTE] Status of Portal blocks
Giacomo Pati wrote: If one deprecates something it suggests a replacement. IIRC the new portal lacks some administration tools which the old one has (user admin, etc.), right? So, what is your suggestion instead of using the old portal block than? If you have an existing project, you don't have to migrate. So imho this question is only relevant for new projects. And my suggestion here is: use the new portal and develop the tools you need (and then contribute them). Again, tools for the new portal are only a matter of time. If we deprecate the old portal this gives users the right signal: the development of the old portal has stopped. A stable block indicates that the development continues. Carsten
Re: Improving portals block [was: Re: [VOTE] Status of Portal blocks]
Carsten Ziegeler said: Now, let me give the dumb open source answer (this is not targetted at you, Ralph). Cocoon and the portal block are open source. So, if something is missing or not the way you like it etc., you can change it. This is usually how open source works: someone has an itch and starts scratching it - perhaps over time others help scratching ;) So, comming back to the topic at hand: yes, the docs about the portal are not perfect and I can only hope that they will improve over time. Documentation can grow in small steps: Each time someone finds that an information is missing in the docs, she can contribute a small patch with just this piece of information. This only takes some minutes to do (ok, first you have to find the information, but once you got it, providing the patch is simple). If something is unclear in the docs, ask and the docs can be made more clear. And so on. As more and more people are actually using the portal, I have the hope that the docs will improve as well. Believe me, I am familiar with this philosophy. With most Cocoon components I really don't have much of a problem with the doc. Most generators, input modules, etc. have enough Javadoc that you can get what you need from them. However, the Portal is a large piece of work and it can be difficult to figure out just what is happening just by looking at the code. I just took a look at the existing doc and it is OK from a 30,000 foot view. The problem is when you actually want to use it and you need to have it behave just slightly differently you need a little more than just samples to clone. All that is missing, from my point of view, is a sort of sequence diagram that shows how a request gets processed through the framework. That would be an immense help. I'd be happy to write it - but since I don't yet have the understanding to do that it wouldn't be of much use to anybody. Ralph
Portal - PortletDefinitionRegistryImpl question
I posted this last week and just want to make sure I'm not doing anything wrong, as I plan to submit a patch as soon as I verify that it works correctly (I'm not getting a NullPointerException at startup at least). I am trying to modify the pluto support so that it will work in a war file. In looking at PortletDefinitionRegistryImpl I see that it is looking at every webapp deployed in this server and calling castor to convert the portlet.xml and web.xml to objects for every webapp that has a portlet.xml. Why would it be doing that? That would seem like a violation of security or at least bad manners. Of course, it is also impossible to do in an environment where war files are used. Ralph
DO NOT REPLY [Bug 24647] - content-length in ResourceReader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24647. 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=24647 content-length in ResourceReader --- Additional Comments From [EMAIL PROTECTED] 2004-08-26 15:39 --- Why is content-length a duplicate of byte-range?
Re: [VOTE] Status of Portal blocks
Hmm.. deprecated mean Hey man, go change you portal as it will be removed in the future is this you want to signal? Yes :( The portal-fw is a nice portal framework, but the code is very very ugly (I know it 'cause I wrote it). The new portal block is (apart from tools) a 100% replacement which is even faster and consumes less memory. Deperecating does not mean removing and deprecating means that it is still supported. So if any bugs occur, we will fix them - but if you start a new project, you should use the new portal block; that's why I think we should deprecate the old one. Why do we always need to discuss what deprecated means? Jörg
RE: [VOTE] Status of Portal blocks
On Thu, 26 Aug 2004, Carsten Ziegeler wrote: If we deprecate the old portal this gives users the right signal: the development of the old portal has stopped. A stable block indicates that the development continues. IMHO 'deprecated' mean much more than just 'the development of the old portal has stopped'. But anyway, go ahead. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
DO NOT REPLY [Bug 30874] New: - SQLTransformer throws exception with stored procs on Sybase
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30874.
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=30874
SQLTransformer throws exception with stored procs on Sybase
Summary: SQLTransformer throws exception with stored procs on
Sybase
Product: Cocoon 2
Version: 2.1.5
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I'm wanting to use the SQLTransformer to call a stored procedure on a Sybase
database, using their jConnect JDBC driver. My query definition is
?xml version=1.0?
page xmlns:sql=http://apache.org/cocoon/SQL/2.0;
accountdetails
execute-query xmlns=http://apache.org/cocoon/SQL/2.0;
query isstoredprocedure=true
{call spu_Valuation_Report 'sql:substitute-value sql:name=portfolio/',
'sql:substitute-value sql:name=login_id/'}
/query
/execute-query
/accountdetails
/page
However, when this runs I get no data returned (running the same call in ISQL
returns half a dozen rows) and the sitemap.log contains the following exception:
WARN(2004-08-26) 18:05.20:171 [sitemap.transformer.sql]
(/imuk/generated/pages/imuk/secure/reports/portfoliovaluation-en-UK.jsp)
http7081-Processor8/SQLTransformer: SQLTransformer: Could not close JDBC connection
java.sql.SQLException: JZ0S2: Statement object has already been closed.
at com.sybase.jdbc2.jdbc.ErrorMessage.raiseError(ErrorMessage.java:436)
at com.sybase.jdbc2.jdbc.SybStatement.checkDead(SybStatement.java:1654)
at com.sybase.jdbc2.jdbc.SybStatement.close(SybStatement.java:420)
at
org.apache.commons.dbcp.DelegatingCallableStatement.close(DelegatingCallableStatement.java:199)
at
org.apache.cocoon.transformation.SQLTransformer$Query.close(SQLTransformer.java:1193)
at
org.apache.cocoon.transformation.SQLTransformer.executeQuery(SQLTransformer.java:368)
at
org.apache.cocoon.transformation.SQLTransformer.endExecuteQueryElement(SQLTransformer.java:478)
...
The problem is that in the execute() method the SQLTransformer has (lines 1075-1087)
if ( oldDriver ) {
cst = conn.prepareCall( query );
} else {
cst = conn.prepareCall( query,
ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY );
}
registerOutParameters( cst );
pst = cst;
}
registerInParameters( pst );
boolean result = pst.execute();
Note the pst = cst line - this is fine it itself, but has the side-effect that
the close() method (lines 1189-1194)
if ( pst != null )
pst.close();
pst = null;// Prevent using pst again.
if ( cst != null )
cst.close();
cst = null;// Prevent using cst again.
is therefore closing the statement twice, once through pst and again through
cst. Presumably, other DBMS' drivers don't mind this, but jConnect does...
DO NOT REPLY [Bug 30883] - Cocoon 2.1.5.1 build fails with JDK1.5.0-beta2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30883. 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=30883 Cocoon 2.1.5.1 build fails with JDK1.5.0-beta2 --- Additional Comments From [EMAIL PROTECTED] 2004-08-27 01:42 --- trying to compile via ant --verbose: [EMAIL PROTECTED] cocoon-2.1.5.1]# ant -verbose Apache Ant version 1.6.2 compiled on August 26 2004 Buildfile: build.xml Detected Java version: 1.5 in: /usr/java/jdk1.5.0/jre Detected OS: Linux parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/build.xml Project base dir set to: /home/sonic/rpm/cocoon-2.1.5.1 Importing file tools/targets/init-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/init-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/init-build.xml Importing file tools/targets/compile-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/compile-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/compile-build.xml Importing file tools/targets/validate-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/validate-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/validate-build.xml Importing file tools/targets/samples-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/samples-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/samples-build.xml Importing file tools/targets/webapp-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/webapp-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/webapp-build.xml Importing file tools/targets/ide-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/ide-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/ide-build.xml Importing file tools/targets/test-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/test-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/test-build.xml Importing file tools/targets/docs-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/docs-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/docs-build.xml Importing file tools/targets/dist-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/dist-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/dist-build.xml Importing file tools/targets/admin-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/admin-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/admin-build.xmlImporting file tools/targets/standalone-demo-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/standalone-demo-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/standalone-demo-build.xml Importing file tools/targets/instrumentation-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/instrumentation-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/instrumentation-build.xml Importing file tools/targets/upgrade-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/upgrade-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/upgrade-build.xml Importing file tools/targets/tools-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/tools-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/tools-build.xmlImporting file tools/targets/forrest-build.xml from /home/sonic/rpm/cocoon-2.1.5.1/build.xml parsing buildfile /home/sonic/rpm/cocoon-2.1.5.1/tools/targets/forrest-build.xml with URI = file:///home/sonic/rpm/cocoon-2.1.5.1/tools/targets/forrest-build.xml Build sequence for target `webapp' is [init, init-tasks, prepare, compile-core, compile-deprecated, compile-tests, compile, prepare-blocks, blocks, block-roles, package-core, package-deprecated, package-testcase, package, prepare-webapp, samples, block-samples, prepare-webapp-samples, prepare-docs, validate-xdocs, validate-jars,
Re: [VOTE] Status of Portal blocks
Carsten Ziegeler dijo: a) mark portal-fw as deprecated +1 b) mark portal as stable +1 Best Regards, Antonio Gallardo
Re: [VOTE] Status of Portal blocks
Carsten Ziegeler wrote: a) mark portal-fw as deprecated +1 b) mark portal as stable +1 -- Reinhard
RE: Portal - PortletDefinitionRegistryImpl question
Ralph Goers wrote: I posted this last week and just want to make sure I'm not doing anything wrong, as I plan to submit a patch as soon as I verify that it works correctly (I'm not getting a NullPointerException at startup at least). I am trying to modify the pluto support so that it will work in a war file. In looking at PortletDefinitionRegistryImpl I see that it is looking at every webapp deployed in this server and calling castor to convert the portlet.xml and web.xml to objects for every webapp that has a portlet.xml. Why would it be doing that? That would seem like a violation of security or at least bad manners. Of course, it is also impossible to do in an environment where war files are used. This is the way, Pluto works, so it just has been copied to Cocoon. Somehow, the Cocoon portal has to know which JSR-168 portlets are available and this search mechanism tries to look through all mounted webapps and extracts the portlet information (if available). Now, a nicer solution would be if we have a deployment tool where you drop your portlet war file into, the portlets are registered and Cocoon does not need to scan all webapps Carsten
