Re: DatabaseReader problem with 2.1.7, help needed (fwd)

[Andrew Franz]

Try Joerg's suggestion: i.e. Look at the actual exception

You can do this quickly & easily, outside Cocoon with JSTL/JSP as follows:


   startRow="0">SELECT * FROM mytable



   *(dump exception here)*


The rest is as below.

After that, I'm out of suggestions


Tuomo L wrote:

SQL Transformer works fine, so does ESQL and other stuff, only the 
DatabaseReader fails when reading and serializing a binary column. 
This is very bizarre. I've also tried putting the mime-type setting in 
the component configuration, sitemap-invocation, the "content-type" 
-parameter, "type-column", switched between JDK1.5/JDK1.4, 
Tomcat4/Tomcat5.5, Cocoon2.1.5/Cocoon2.1.7 and all different 
combinations of these. I also built the 2.1.7 from scratch as is, 
without modifications but the SQL-driver in web.xml and 
JDBC-configuration in cocoon.xconf to match SQL Server's needs. The 
upload/download -sample does the same thing, returning 0 bytes.


How could I debug this more?

-Tuomo

On Sun, 17 Jul 2005, Andrew Franz wrote:


I haven't used SQL server from C2.
All I can suggest is to keep on isolating the problem, e.g try the 
JDBC driver directly under Tomcat using JSP

e.g. try the following - put it under webapps/jsp-examples
(substitute driver & url accordingly, the following is for Oracle)

If it works, the problem is your Cocoon setup or Cocoon. If not, the 
problem is the driver or JDBC setup.


Sometimes I think that it would be quicker and easier to strip away 
*all* of the layers and go back to using the file system.




http://java.sun.com/JSP/Page";
  xmlns:c="http://java.sun.com/jsp/jstl/core";
  xmlns:sql="http://java.sun.com/jsp/jstl/sql";>



url="jdbc:oracle:thin:@localhost:1521:dbname"  user="scott"  
password="tiger" />



startRow="0">SELECT * FROM mytable


value="${columnName}"/>


  value="${col}"/>








Tuomo L wrote:

Thanks, I tested the sample, and it does work with HSQLDB. But when 
I tested it against SQL Server with similar results I got before: 
Upload works but reading the file with DatabaseReader returns 0 
bytes. :(


So, my guess is, something has changed between 2.1.5 and 2.1.7 that 
makes
the JDBC driver for SQL Server incompatible with Cocoon. With the 
jar-files from 2.1.5 (same setup otherwise) this works. What could 
this change be?


The method that throws this error "Assuming client reset stream" in 
DatabaseReader.java is:


public void generate() throws ProcessingException, SAXException, 
IOException {

try {
Response response = 
ObjectModelHelper.getResponse(objectModel);

this.serialize(response);
} catch (IOException ioe) {
getLogger().warn("Assuming client reset stream");

this.doCommit = false;
} catch (Exception e) {
this.doCommit = false;

throw new ResourceNotFoundException("DatabaseReader 
error:", e);

}
}


-Tuomo

On Sun, 17 Jul 2005, Andrew Franz wrote:


DatabaseReader is used in the samples:
http://localhost:8080/cocoon/samples/blocks/databases/mod-db/file-upload-blob 
(Cocoon 2.1.7, Tomcat 5.5)


After upload, this uses DatabaseReader to retrieve the image from 
HSQLDB.
If this works ok, then the problems are with SQL Server maybe the 
column definition



Tuomo L wrote:


Hi,

Is anyone using the DatabaseReader with Cocooon 2.1.7 ? We just 
cannot get

it to function. Log says "Assuming client reset stream".

If it works, could you please tell which versions of Java, Tomcat 
and db you have on what system? We're trying to figure out the 
source for this
problem. With Cocoon 2.1.5 everything works fine. We are using SQL 
Server

2000 and it's latest JDBC driver provided by MS.

-Tuomo


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





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




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

Re: DatabaseReader problem with 2.1.7, help needed (fwd)

[Andrew Franz]

I haven't used SQL server from C2.
All I can suggest is to keep on isolating the problem, e.g try the JDBC 
driver directly under Tomcat using JSP

e.g. try the following - put it under webapps/jsp-examples
(substitute driver & url accordingly, the following is for Oracle)

If it works, the problem is your Cocoon setup or Cocoon. If not, the 
problem is the driver or JDBC setup.


Sometimes I think that it would be quicker and easier to strip away 
*all* of the layers and go back to using the file system.




http://java.sun.com/JSP/Page";
   xmlns:c="http://java.sun.com/jsp/jstl/core";
   xmlns:sql="http://java.sun.com/jsp/jstl/sql";>



url="jdbc:oracle:thin:@localhost:1521:dbname"  user="scott"  
password="tiger" />



startRow="0">SELECT * FROM mytable


value="${columnName}"/>


   value="${col}"/>








Tuomo L wrote:

Thanks, I tested the sample, and it does work with HSQLDB. But when I 
tested it against SQL Server with similar results I got before: Upload 
works but reading the file with DatabaseReader returns 0 bytes. :(


So, my guess is, something has changed between 2.1.5 and 2.1.7 that makes
the JDBC driver for SQL Server incompatible with Cocoon. With the 
jar-files from 2.1.5 (same setup otherwise) this works. What could 
this change be?


The method that throws this error "Assuming client reset stream" in 
DatabaseReader.java is:


public void generate() throws ProcessingException, SAXException, 
IOException {

try {
Response response = 
ObjectModelHelper.getResponse(objectModel);

this.serialize(response);
} catch (IOException ioe) {
getLogger().warn("Assuming client reset stream");

this.doCommit = false;
} catch (Exception e) {
this.doCommit = false;

        throw new ResourceNotFoundException("DatabaseReader 
error:", e);

}
}


-Tuomo

On Sun, 17 Jul 2005, Andrew Franz wrote:


DatabaseReader is used in the samples:
http://localhost:8080/cocoon/samples/blocks/databases/mod-db/file-upload-blob 


(Cocoon 2.1.7, Tomcat 5.5)

After upload, this uses DatabaseReader to retrieve the image from 
HSQLDB.
If this works ok, then the problems are with SQL Server maybe the 
column definition



Tuomo L wrote:


Hi,

Is anyone using the DatabaseReader with Cocooon 2.1.7 ? We just 
cannot get

it to function. Log says "Assuming client reset stream".

If it works, could you please tell which versions of Java, Tomcat 
and db you have on what system? We're trying to figure out the 
source for this
problem. With Cocoon 2.1.5 everything works fine. We are using SQL 
Server

2000 and it's latest JDBC driver provided by MS.

-Tuomo


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





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




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

Re: DirectoryGenerator using abstract Source

[Andrew Franz]

Unico Hommes wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Wechner wrote:
 


Joerg Heinicke wrote:

   


On 13.07.2005 00:28, Michael Wechner wrote:

 


It seems to me that the directory generator is not really based
on the "abstract methods" of an excalibur Source, but rather takes
the source and "maps" it onto a java.io.File.

Is that intended or just not implemented for the lack of time?

I would like to make this more generic with regard to other sources,
e.g.
JCR or whatever. If this makes sense then I would patch the
DirectoryGenerator,
but otherwise I would write a "DirectoryGenerator" from scratch, e.g
CollectionGenerator which is making use the TraversableSource interface.
   



You don't have to:
$COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java

 



thanks very much for the pointer. I think it would make sense to make a
note
within the DirectoryGenerator that the TraversableGenerator exists and is
more generic.

   



In fact IMHO, it should be deprecated in favor of TraversableGenerator...

- --
Unico

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC1UORcuec8tVNKAwRAiA4AJ94XDoBh0ACS2iTFW+uqTDcIBJ6lQCg34Fr
xYZdDb1pyefSC/Wlf2FAyjw=
=y0i0
-END PGP SIGNATURE-


 



As a user, I found that DirectoryGenerator didn't do what I wanted, so I 
went down the path of creating a variant of (not extending) 
DirectoryGenerator essentially to show meta-information (using POIFS) of 
MS-Office files and images (I also added ImageGenerator functionality 
and added .png, .ico, .bmp).

Output looks like this:

- <#>lastModified="*1118747923320*" date="*6/14/05 9:18 PM*" size="*110080*">
  

 
 lastModified="*998171376000*" date="*8/19/01 7:49 AM*" size="*96256*">

 
 
- <#>name="*PPT1.ppt*" lastModified="*1116947798687*" date="*5/25/05 1:16 
AM*" size="*11264*">
savedate="*5/25/05 1:16 AM*" />

 


 
 


Looking at TraversableGenerator, I saw a reference to an 
'InspectableSource'. This seems a better way to go.


(As a user) Is there a way to achieve the same outcome using 
TraversableGenerator and 'InspectableSource'?
(As a developer) Should I be extending 'InspectableSource' with POIFS or 
am I better off sticking with a custom generator?


The end goal is to extract meta-info and include it in the directory 
listing & then use Lucene to index the meta info - so a variety of file 
types need to be 'inspected'

Re: Running cocoon as a war archive

[Andrew Franz]

Irv Salisbury wrote:


I have always run cocoon as an expanded war directory.  Our current
customer is requesting we run as a war file.  Are there any resources
or problems people have found with this strategy?

Thanks,

Irv


 



I had occasion to deal with an individual who insisted on this approach. 
It stems from a desire to 'lock down' production servers to prevent any 
changes. In practice, no software is perfect and there are times when a 
simple one-line change will immediately fix the problem. When you need 
to do this, you don't want to be making a one-line change in a staging 
environment and then re-deploying a 50Mb war file. Also you can't be 
totally certain that no other changes have been made in the staging 
environment. I would argue from a management perspective that deploying 
an expanded servlet is less risky and allows more responsive support. If 
the individual insists on the .war file approach, one possible approach 
is to run a staging servlet (expanded) in parallel with the production 
servlet (war file) - this has the advantage of the identical 
environment, available to test under production conditions & available 
as a backup in an emergency.


On the technical level, there are issues with anything that needs to be 
written to, such as HSQLDB.
   See 
http://www.mail-archive.com/cocoon-users@xml.apache.org/msg07183.html


Doesn't this belong in [EMAIL PROTECTED]

Re: iCal

[Andrew Franz]

Andrew Franz wrote:


Sylvain Wallez wrote:


Tony Collen wrote:


Sylvain Wallez wrote:


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?






It would be great to have an iCal generator / iCal serializer!

Want to write it ?



http://www.ietf.org/rfc/rfc2445.txt





Yeah, but that's not XML ;-)

Sylvain



I was tempted enough to read the RTF - all 148 pages!!


RFC (!)



But no, I have a day job, no expertise in this area & the extent of my 
cocoon knowledge is writing *one* generator


Thanks for the suggestion though ;-)

Re: iCal

[Andrew Franz]

Sylvain Wallez wrote:


Tony Collen wrote:


Sylvain Wallez wrote:


Andrew Franz wrote:


Has anyone thought about integrating iCal with Cocoon?





It would be great to have an iCal generator / iCal serializer!

Want to write it ?



http://www.ietf.org/rfc/rfc2445.txt




Yeah, but that's not XML ;-)

Sylvain



I was tempted enough to read the RTF - all 148 pages!!

But no, I have a day job, no expertise in this area & the extent of my 
cocoon knowledge is writing *one* generator


Thanks for the suggestion though ;-)

Re: Extending DirectoryGenerator

[Andrew Franz]

(reposted from the user mailing list)

Andrew Franz wrote:

I am thinking about a simple CMS (Content Management System) which 
would have the following features:
1. Ability to list MS-Office files along with their 
 attributes (this would use Jakarta POI), ability 
to list "image" files (basically by cloning the functionality in 
ImageDirectoryGenerator) and be able to be extended to other commonly 
used document formats such as PDF

2. The output of #1 would be used as input to create a Lucene Index.
3. The Lucene index would be used to search an Intranet by Author, 
Title, Subject, etc.


This would mean that content-creators in the organisation would 
categorise documents simply by updating  
('Properties' in MS-Office applications) and then uploading the file 
(the current implementation requires them to update a database 
separate to the document itself). The Cocoon application would 
automatically categorise the document, either by using Lucene or from 
the SummaryInformation. Indexing would only apply to the header/meta 
info - full text indexing of content is not required.


The question (to experienced Cocoon developers) is what is the 
preferred method of implementation?


Option 1. Extend DirectoryGenerator similar to the way 
ImageDirectoryGenerator is implemented but adding new file types


Option 2. Use DirectoryGenerator 'as is' but augment it with a 
HeaderGenerator per file/mimetype and then aggregate results such that 
the output is similar to #1


Option 3. Tell the users to 'SaveAs' MS-Office documents into an XML 
format and use XSLT to extract the summary information. For example 
Visio binary format (VSD) can be saved as VXD and the same information 
can be extracted via XSLT


All of the above are feasible and invariant to the user-interface so 
the question is more about performance.


Has anyone gone down this route? Are there any pitfalls I need to be 
aware of? For the experienced Cocoon developers, what is your gut-feel 
about which is the preferred option?


Replies much appreciated.

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

iCal

[Andrew Franz]

Has anyone thought about integrating iCal with Cocoon?