[jira] Updated: (COCOON-1438) [MAIL] Weird Encoding problem with SendMailAction

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1438?page=all ]

Jörg Heinicke updated COCOON-1438:
--


> [MAIL] Weird Encoding problem with SendMailAction
> -
>
> Key: COCOON-1438
> URL: http://issues.apache.org/jira/browse/COCOON-1438
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Mail
>Affects Versions: 2.1.6
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Gabriel Gruber
> Assigned To: Cocoon Developers Team
>
> I have a flowscript, wich uses the sendmailaction to send a mail.
> As the mail is supposed to be a html-mail, it is generated through a cocoon-
> pipeline and feeded by a request-param which contains the body-text.
> this body-text is first submitted by a cform.
> the cform correctly delivers the bodytext (after changing all the encoding 
> settings in the web.xml and serializer configs to "UTF-8") with 
> specialcharacters correctly.
> However the mail which is generated doesn't encode the bodytext correctly. 
> the 
> weird thing is that when I submit the same URL I gave to the SendMailaction 
> via 
> a browser, the character-encoding is correct.
> when looking at the following sourcecode, then Bodytext should logically be 
> encoded with UTF-8 (as everything else is done with UTF-8). However in order 
> to 
> work, I had to switch to ISO-8859-1 for this single line. Otherwise the 
> generated html-mail had strange special characters..
> var cocoonurl = "cocoon:/mailtext/arllink/" + myarl + "?body=" + 
> java.net.URLEncoder.encode(model.KollegeEmailBodytext,"ISO-8859-1");
>   
> var mailsender = cocoon.getComponent
> (Packages.org.apache.cocoon.mail.MailSender.ROLE);
> mailsender.setSmtpHost(cocoon.parameters["eohb_smtp_host"],cocoon.parameters
> ["eohb_smtp_user"],cocoon.parameters["eohb_smtp_pwd"]);
> mailsender.setTo(model.KollegeEmail);
> mailsender.setFrom(cocoon.parameters["eohb_smtp_from"]);
> mailsender.setBodyFromSrc(cocoonurl);
> mailsender.setSubject("eOHB Link");
> mailsender.setCharset("UTF-8");
> mailsender.setBodyFromSrcMimeType("text/html; charset=utf-8");
> mailsender.sendIt();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (COCOON-1255) org.apache.cocoon.components.xscript.StringBufferContentHandler produces two default namespaces definitions in produced string

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1255?page=all ]

Jörg Heinicke updated COCOON-1255:
--


What is actually the problem? This looks absolutely ok.

> org.apache.cocoon.components.xscript.StringBufferContentHandler produces two 
> default namespaces definitions in produced string
> --
>
> Key: COCOON-1255
> URL: http://issues.apache.org/jira/browse/COCOON-1255
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: XSP
>Affects Versions: 2.1.5
> Environment: Operating System: All
> Platform: All
>Reporter: Greg Konstantinidis
> Assigned To: Cocoon Developers Team
>
> Hi I have a Transformer that uses the
> org.apache.cocoon.components.xscript.StringBufferContentHandler
> to collect data before posting it to a website. 
> (see between  tags below). 
> The string generated has two default namespaces "book" and "fred".
> The fix is to around lines 118 in startElement. 
> There needs to be some accounting for same name prefixes ("") but differing
> namespaces (book fred) and to use the one that is in scope. 
> (i.e. only xmlns="fred" should only be generated).
> Thanks.
> 
>
>   
>   
>   username="MDEV"/>
>  http://localhost:/samples/greg/echo";>
> 
> 
>
>   
>  
> 
>  
>   
>
> 
>  
>   
>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (COCOON-1449) soap logicsheet doesn't work (xscriptManager component cannot be resolved)

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1449?page=all ]

Jörg Heinicke closed COCOON-1449.
-

Resolution: Cannot Reproduce

Can't reproduce and wonder how it should occur: Your error message says, 
Component is an unknown type, which at the end means, its import is missing. 
But Component is imported already in the xsp.xsl, i.e. it gets imported in 
every XSP-generated Java class.

If it occurs though in your case we probably need more info like the source 
that gets generated etc.

> soap logicsheet doesn't work (xscriptManager component cannot be resolved)
> --
>
> Key: COCOON-1449
> URL: http://issues.apache.org/jira/browse/COCOON-1449
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: XSP
>Affects Versions: 2.1.8
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Bastian Bowe
> Assigned To: Cocoon Developers Team
>
> Running a xsp using the soap logicsheet will result in the following compile 
> error:
> // start error (lines 80-80) "Component cannot be resolved or is not a type"
> manager.release((Component)xscriptManager);
> // end error
> This is my xsp, which worked without problems on cocoon 2.1.6:
> 
>  language="java"
> xmlns:xsp="http://apache.org/xsp";
> xmlns:xsp-request="http://apache.org/xsp/request/2.0";
> xmlns:xscript="http://apache.org/xsp/xscript/1.0";
> xmlns:soap="http://apache.org/xsp/soap/3.0";>
>   
> 
>   
>   SOAP Test
>   
>   
>   Cocoon SOAP Test
>   
>  url="http://localhost:9090/SOLICY_SOAP/services/HelloWorld";>
>   http://soap.solicy.foo.com"/>
> 
>   
>   
> 
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer

2006-10-14 Thread Antonio Gallardo (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442338 
] 

Antonio Gallardo commented on COCOON-1894:
--

If it is the same code, 1 patch is enough. :)


> Added support for the SQL:XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java, 
> SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer

2006-10-14 Thread Geurt Wisselink (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442335 
] 

Geurt Wisselink commented on COCOON-1894:
-

Antonio,

The same file can be used for cocoon 2.2 and 2.1.9. This is actually how I
tested it.
I can provide you with a patch 2.1.9 and one for 2.2.

But the end result will be the same. Is that okay with you?

Regards Geurt 



> Added support for the SQL:XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java, 
> SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (COCOON-1825) [PATCH] Ajax error when an active state widget become invisible state widget

2006-10-14 Thread Antonio Gallardo (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12442322 
] 

Antonio Gallardo commented on COCOON-1825:
--

I asked about the duplicated id just to be sure, but I believe it is a typo.
I agree it is better to use div instead of span.
Sure feel free to send a patch. I will be glad to apply it. :-)

> [PATCH] Ajax error when an active state widget become invisible state widget
> 
>
> Key: COCOON-1825
> URL: http://issues.apache.org/jira/browse/COCOON-1825
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Forms
>Affects Versions: 2.1.9
>Reporter: vincent Demay
> Assigned To: Antonio Gallardo
>
> Some widget (field with selection-list and styling=radio, group, etc...)  can 
> not be hidden (state=invisible)in ajax mode.
> I declare some widgets without state attribute in the form definition, my 
> form is in ajax mode, when I set the widget state to INVISIBLE, the ajax 
> response can not be applied to the form because  id="widget-name">... is not available in source code.
> I think about 2 patches : 
> *putting a  in forms-field-styling.xsl where is not set
> *or modifing abstractWidgetDefinition.java in ordre to generate a placeholder 
> around each widget (but patch seems to need a lot of modification in 
> forms-field-styling.xsl too)
> Here is the patch for first 
> --- forms-field-styling.orig  2006-04-13 15:37:06.590221200 +0200
> +++ forms-field-styling.xsl   2006-04-13 15:38:22.525291200 +0200
> @@ -198,8 +198,9 @@
>  
>   select="string(fi:styling/@list-orientation) != 'horizontal'"/>
>  
> -  
> - title="{fi:hint}">
> +  
> +   
> +   title="{fi:hint}">
>
>  
>  
> @@ -224,6 +225,7 @@
>  
>
>  
> +
>
>
>  
> @@ -682,22 +684,24 @@
>| know where to insert the widget if it becomes visible
>+-->
>
> -
> +
>
>
>
>
> -
> + 
>
>  
>
>
> -
> +
>
> +  
> +  
>  
>
>  
> Here for the second
> --- AbstractWidget.orig   2006-04-13 15:31:07.851701200 +0200
> +++ AbstractWidget.java   2006-04-13 15:30:31.446616200 +0200
> @@ -483,6 +483,10 @@
>  public void generateSaxFragment(ContentHandler contentHandler, Locale 
> locale)
>  throws SAXException {
>  
> + AttributesImpl placeHolderAttrs = new AttributesImpl();
> + placeHolderAttrs.addCDATAAttribute("id", getRequestParameterName());
> +contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", 
> placeHolderAttrs);
> +
>  if (getCombinedState().isDisplayingValues()) {
>  // FIXME: we may want to strip out completely widgets that 
> aren't updated when in AJAX mode
>  String element = this.getXMLElementName();
> @@ -497,15 +501,9 @@
>  
>  generateItemSaxFragment(contentHandler, locale);
>  
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element);
> -
> -} else {
> -// Generate a placeholder that can be used later by AJAX updates
> -AttributesImpl attrs = new AttributesImpl();
> -attrs.addCDATAAttribute("id", getRequestParameterName());
> -contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", attrs);
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
> +contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element); 
>  }
> +contentHandler.endElement(FormsConstants.INSTANCE_NS, "placeholder", 
> FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
>  }
>  
>   public Object getAttribute(String name) {

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (COCOON-1878) Validation block: conflict over Xerces xml-apis and jsr-173 javax.xml.XMLConstants

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1878?page=all ]

Jörg Heinicke closed COCOON-1878.
-

Fix Version/s: 2.2-dev (Current SVN)
   2.1.10-dev (current SVN)
   Resolution: Fixed

It seems that the Validator interface declares some constants with the same 
values too. So replaced the references to XMLConstants's constants with them in 
Validator.

> Validation block: conflict over Xerces xml-apis and jsr-173 
> javax.xml.XMLConstants
> --
>
> Key: COCOON-1878
> URL: http://issues.apache.org/jira/browse/COCOON-1878
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Validation
>Affects Versions: 2.1.8, 2.1.9
>Reporter: Ellis Pritchard
>Priority: Minor
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
>
> blocks/validation/java/org/apache/cocoon/components/validation/jaxp/JaxpSchemaParser.java
>  relies on the following constants defined in javax.xml.XMLConstants :
> XMLConstants.RELAXNG_NS_URI
> XMLConstants.W3C_XML_SCHEMA_NS_URI
> XMLConstants.XML_DTD_NS_URI
> These constants come from xml-apis-1.3.02.jar, which is part of Xerces; 
> however the official release of javax.xml.XMLConstants from Sun (e.g. jsr-173 
> [1]) does not contain these constants, and therefore installing e.g. 
> stax-api-1.0.1.jar, which contains the official XML API, may create a build 
> or run-time failure, depending on the order that jars are loaded.
> These constants should probably be obtained from elsewhere to avoid future 
> problems.
> Work-around: disable validation block, or remove XMLConstants from offical 
> jars.
> [1] http://java.sun.com/webservices/docs/1.6/api/index.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer

2006-10-14 Thread Antonio Gallardo (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1894?page=all ]

Antonio Gallardo updated COCOON-1894:
-


Hi,

Thanks for the feedbak. I had plans to apply the patch today. I have 2 
questions:

1. The previous patch (4 kB) is still valid for cocoon 2.1?
2. Related to the most recent attachment, it is for cocoon 2.2?  Would you 
provide a patch?

BTW, My name is Antonio, not Antonia. :-)

> Added support for the SQL:XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java, 
> SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (COCOON-1417) Jx:set type ??? (JXTemplate Bug List)

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1417?page=all ]

Jörg Heinicke updated COCOON-1417:
--


Can you retest it with the JXTemplateGenerator in the template block instead of 
the one in core please?
The older one has been deprecated in 2.1 and removed in 2.2, so it won't be 
fixed anymore.

> Jx:set type ??? (JXTemplate Bug List)
> -
>
> Key: COCOON-1417
> URL: http://issues.apache.org/jira/browse/COCOON-1417
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Templating
>Affects Versions: 2.2-dev (Current SVN)
> Environment: Operating System: Linux
> Platform: All
>Reporter: Tibor Katelbach
> Assigned To: Cocoon Developers Team
>
>  value="${session.getAttribute('my_key/authentication')}"/>   
>
>   
>
> returns true or false according to the existence of the ID, so far so good 
> OTH   
>  returns always true , bug???

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (COCOON-1438) [MAIL] Weird Encoding problem with SendMailAction

2006-10-14 Thread Gabriel Gruber (JIRA)
[ 
http://issues.apache.org/jira/browse/COCOON-1438?page=comments#action_12442295 
] 

Gabriel Gruber commented on COCOON-1438:


1) Why is it not feasable to change the container-encoding inside the web.xml?  
 

I thought to correctly handle character-encoding with UTF8 throughout my cocoon 
web-application I did modifications inside these files:

a) web.xml


  form-encoding
  utf-8


However now I realised, that this setting is intented to be used, if the 
surruounding servlet container has a encoding other than iso set. At my 
use-case with tomcat that is actually *NOT* the case, as the setting for UTF-8 
has to be done explicitly... this maybe explains my problem...

2) model.KollegeEmailBodyText
This is the String containing the BodyText for the Email being submitted via 
cforms.
This is the full flowcode:

function sendacol() {

// Flowscript um Kollegen einen Link auf ARL zu schicken

var myarl = cocoon.request.get("uid");

var form = new Form("forms/sendacol_form.xml");
form.showForm("forms/sendacol");

var model = form.getModel();


// Send Mail through Mailsender Component

// kurios: body muss mit ISO Charset codiert werden ansonsten ist 
// das endg�ltige HTML-Mail falsch...
// eigentlich unlogisch, da sonst alles UTF-8

var cocoonurl = "cocoon:/mailtext/arllink/" + myarl + "?body=" 
if (model.KollegeEmailBodytext!=null) {
cocoonurl += 
java.net.URLEncoder.encode(model.KollegeEmailBodytext,"ISO-8859-1");
}


var mailsender = 
cocoon.getComponent(Packages.org.apache.cocoon.mail.MailSender.ROLE);

// Logging
if (cocoon.log.isDebugEnabled) {
cocoon.log.debug("cocoon-url f�r mailtext = " + cocoonurl);
cocoon.log.debug("eohb_smtp_host = " + 
cocoon.parameters["eohb_smtp_host"]);
cocoon.log.debug("eohb_smtp_user = " + 
cocoon.parameters["eohb_smtp_user"]);
cocoon.log.debug("eohb_smtp_password = " + 
cocoon.parameters["eohb_smtp_password"]);
}
if ((cocoon.parameters["eohb_smtp_user"] == null) || 
(cocoon.parameters["eohb_smtp_user"] == "anonymous" )) {
// SMTP anmeldung ohne User (anonymous)
mailsender.setSmtpHost(cocoon.parameters["eohb_smtp_host"]);
} else {
// SMTP Anmeldung mit User

mailsender.setSmtpHost(cocoon.parameters["eohb_smtp_host"],cocoon.parameters["eohb_smtp_user"],cocoon.parameters["eohb_smtp_pwd"]);
 
}

mailsender.setTo(model.KollegeEmail);
mailsender.setFrom(cocoon.parameters["eohb_smtp_from"]);
mailsender.setBodyFromSrc(cocoonurl);
mailsender.setSubject("eOHB Link");
mailsender.setCharset("UTF-8");
mailsender.setBodyFromSrcMimeType("text/html; charset=utf-8");

try {
mailsender.send();
} catch (e) {
cocoon.log.error("Problem mit Mailversand",e);
cocoon.sendPage("page_sendmail_failure");
return;
}

if (cocoon.log.isDebugEnabled && model.KollegeEmailBodytext!=null)
cocoon.log.debug("Body-Mailtext: " + 
java.net.URLDecoder.decode(model.KollegeEmailBodytext,"UTF-8"));

cocoon.sendPage("page_sendmail_success");
}

> [MAIL] Weird Encoding problem with SendMailAction
> -
>
> Key: COCOON-1438
> URL: http://issues.apache.org/jira/browse/COCOON-1438
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Mail
>Affects Versions: 2.1.6
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Gabriel Gruber
> Assigned To: Cocoon Developers Team
>
> I have a flowscript, wich uses the sendmailaction to send a mail.
> As the mail is supposed to be a html-mail, it is generated through a cocoon-
> pipeline and feeded by a request-param which contains the body-text.
> this body-text is first submitted by a cform.
> the cform correctly delivers the bodytext (after changing all the encoding 
> settings in the web.xml and serializer configs to "UTF-8") with 
> specialcharacters correctly.
> However the mail which is generated doesn't encode the bodytext correctly. 
> the 
> weird thing is that when I submit the same URL I gave to the SendMailaction 
> via 
> a browser, the character-encoding is correct.
> when looking at the following sourcecode, then Bodytext should logically be 
> encoded with UTF-8 (as everything else is done with UTF-8). However in order 
> to 
> work, I had to switch to ISO-8859-1 for this single line. Otherwise the 
> generated html-mail had strange special characters..
> var cocoonurl = "cocoon:/mailtext/arllink/" + myarl + "?body=" + 
> java.net.URLEncoder.encode(model.KollegeEmailBodytext,"ISO-8859-1");
>   
> var mailsender = cocoon.getComponent
> (Pack

Re: [jira] Updated: (COCOON-1816) JEXL Does not support full cocoon object model on its own

2006-10-14 Thread Joerg Heinicke
Jörg Heinicke (JIRA  apache.org> writes:

> > JEXL Does not support full cocoon object model on its own
> > -
> >
> > Key: COCOON-1816
> > URL: http://issues.apache.org/jira/browse/COCOON-1816
> > Project: Cocoon
> >  Issue Type: Bug
> >  Components: Blocks: Templating
> >Affects Versions: 2.1.8
> >Reporter: Berin Loritsch
> >Priority: Critical
> >

Can somebody comment on this issue? Is this issue about the different object
models in the template when using flow or not? And has it been fixed or not?
Berin's comments are somewhat unspecific.

Jörg



[jira] Closed: (COCOON-1578) WebServiceProxyGenerator sample block error

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1578?page=all ]

Jörg Heinicke closed COCOON-1578.
-

Fix Version/s: 2.2-dev (Current SVN)
   2.1.10-dev (current SVN)
   Resolution: Fixed

This issue is no longer valid "as is". The wsproxy sample relies on xmlforms 
which has been removed completely from the Cocoon code base. So this sample got 
disabled. Before reactivating it, it has to be rewritten completely.

I removed the exclude-namespace-prefix="xalan". Don't know what else should 
have caused your particular error.

Jörg

> WebServiceProxyGenerator sample block error
> ---
>
> Key: COCOON-1578
> URL: http://issues.apache.org/jira/browse/COCOON-1578
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Proxy
>Affects Versions: 2.1.7
> Environment: Operating System: other
> Platform: Other
>Reporter: cogito
> Assigned To: Cocoon Developers Team
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
>
> http://localhost:/samples/blocks/proxy/wsproxy/ doesn't work in 2.1.7 
> build.
> I get this error message:
> "Impossible de résoudre le préfixe de l'espace de noms : xalan"
> (wich means in english: "unable to resolve xalan namespace"
> I've seen that this block has bugs (14916, 21339, 21340, 21399) open in the 
> main SVN trunk... but they don't seem to deal with this problem.
> I tried to remove: 
>   exclude-result-prefixes="xalan"
> from newWizard2html.xsl
> (just to see...)
> I get an other error message:
> C:\...\cocoon-2.1.7\build\webapp\stylesheets\system\xmlform2html.xslt (Le 
> fichier spécifié est introuvable)
> (in english: unable to find .../xmlform2html.xslt)
> Is it solve in the main trunk ?
> --
> Full stacktrace of "unable to resolve xalan namespace":
> org.apache.cocoon.ProcessingException: Unable to get transformer handler for 
> file:/C:/developpement/apache/cocoon-
> 2.1.7/build/webapp/samples/blocks/proxy/stylesheets/newWizard2html.xsl: 
> org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating 
> Transform Handler
>   at org.apache.cocoon.transformation.TraxTransformer.setup
> (TraxTransformer.java:318)
>   at 
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline
> (AbstractProcessingPipeline.java:398)
>   at 
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.se
> tupPipeline(AbstractCachingProcessingPipeline.java:620)
>   at 
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipelin
> e(AbstractProcessingPipeline.java:503)
>   at 
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
> (AbstractProcessingPipeline.java:455)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke
> (SerializeNode.java:120)
>   at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
> odes(AbstractParentProcessingNode.java:46)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
> (PreparableMatchNode.java:130)
>   at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
> odes(AbstractParentProcessingNode.java:68)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
> (PipelineNode.java:138)
>   at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
> odes(AbstractParentProcessingNode.java:68)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
> (PipelinesNode.java:92)
>   at 
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
> (ConcreteTreeProcessor.java:234)
>   at 
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
> (ConcreteTreeProcessor.java:176)
>   at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
> (TreeProcessor.java:243)
>   at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
> (MountNode.java:117)
>   at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
> odes(AbstractParentProcessingNode.java:46)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
> (PreparableMatchNode.java:130)
>   at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
> odes(AbstractParentProcessingNode.java:68)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
> (PipelineNode.java:138)
>   at 
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
> odes(AbstractParentProcessingNode.java:68)
>   at 
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
> (PipelinesNode.java:92)
>   at 
> org.apache.cocoon.components.tr

[jira] Updated: (COCOON-1825) [PATCH] Ajax error when an active state widget become invisible state widget

2006-10-14 Thread Jorg Heymans (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1825?page=all ]

Jorg Heymans updated COCOON-1825:
-

Summary: [PATCH] Ajax error when an active state widget become invisible 
state widget  (was: Ajax errror when an active state widget become invisible 
state widget)

> [PATCH] Ajax error when an active state widget become invisible state widget
> 
>
> Key: COCOON-1825
> URL: http://issues.apache.org/jira/browse/COCOON-1825
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Forms
>Affects Versions: 2.1.9
>Reporter: vincent Demay
> Assigned To: Antonio Gallardo
>
> Some widget (field with selection-list and styling=radio, group, etc...)  can 
> not be hidden (state=invisible)in ajax mode.
> I declare some widgets without state attribute in the form definition, my 
> form is in ajax mode, when I set the widget state to INVISIBLE, the ajax 
> response can not be applied to the form because  id="widget-name">... is not available in source code.
> I think about 2 patches : 
> *putting a  in forms-field-styling.xsl where is not set
> *or modifing abstractWidgetDefinition.java in ordre to generate a placeholder 
> around each widget (but patch seems to need a lot of modification in 
> forms-field-styling.xsl too)
> Here is the patch for first 
> --- forms-field-styling.orig  2006-04-13 15:37:06.590221200 +0200
> +++ forms-field-styling.xsl   2006-04-13 15:38:22.525291200 +0200
> @@ -198,8 +198,9 @@
>  
>   select="string(fi:styling/@list-orientation) != 'horizontal'"/>
>  
> -  
> - title="{fi:hint}">
> +  
> +   
> +   title="{fi:hint}">
>
>  
>  
> @@ -224,6 +225,7 @@
>  
>
>  
> +
>
>
>  
> @@ -682,22 +684,24 @@
>| know where to insert the widget if it becomes visible
>+-->
>
> -
> +
>
>
>
>
> -
> + 
>
>  
>
>
> -
> +
>
> +  
> +  
>  
>
>  
> Here for the second
> --- AbstractWidget.orig   2006-04-13 15:31:07.851701200 +0200
> +++ AbstractWidget.java   2006-04-13 15:30:31.446616200 +0200
> @@ -483,6 +483,10 @@
>  public void generateSaxFragment(ContentHandler contentHandler, Locale 
> locale)
>  throws SAXException {
>  
> + AttributesImpl placeHolderAttrs = new AttributesImpl();
> + placeHolderAttrs.addCDATAAttribute("id", getRequestParameterName());
> +contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", 
> placeHolderAttrs);
> +
>  if (getCombinedState().isDisplayingValues()) {
>  // FIXME: we may want to strip out completely widgets that 
> aren't updated when in AJAX mode
>  String element = this.getXMLElementName();
> @@ -497,15 +501,9 @@
>  
>  generateItemSaxFragment(contentHandler, locale);
>  
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element);
> -
> -} else {
> -// Generate a placeholder that can be used later by AJAX updates
> -AttributesImpl attrs = new AttributesImpl();
> -attrs.addCDATAAttribute("id", getRequestParameterName());
> -contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", attrs);
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
> +contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element); 
>  }
> +contentHandler.endElement(FormsConstants.INSTANCE_NS, "placeholder", 
> FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
>  }
>  
>   public Object getAttribute(String name) {

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1693?page=all ]

Jörg Heinicke updated COCOON-1693:
--


> When using src parameter on sendMail action, body is included as attachment, 
> and when using body parameter, mimeType is always text/html
> 
>
> Key: COCOON-1693
> URL: http://issues.apache.org/jira/browse/COCOON-1693
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Mail
>Affects Versions: 2.1.8
>Reporter: Marc Salvetti
>Priority: Minor
> Attachments: MailMessageSender.java, MailSender.java, Sendmail.java
>
>
> If using the src parameter, the body is included as an attachment (the header 
> Content-disposition=attachment) is set.
> Moreover, when trying to stick some html in the body parameter, the mimeType 
> is always text/html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (COCOON-1438) [MAIL] Weird Encoding problem with SendMailAction

2006-10-14 Thread JIRA
 [ http://issues.apache.org/jira/browse/COCOON-1438?page=all ]

Jörg Heinicke updated COCOON-1438:
--


> [MAIL] Weird Encoding problem with SendMailAction
> -
>
> Key: COCOON-1438
> URL: http://issues.apache.org/jira/browse/COCOON-1438
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Mail
>Affects Versions: 2.1.6
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Gabriel Gruber
> Assigned To: Cocoon Developers Team
>
> I have a flowscript, wich uses the sendmailaction to send a mail.
> As the mail is supposed to be a html-mail, it is generated through a cocoon-
> pipeline and feeded by a request-param which contains the body-text.
> this body-text is first submitted by a cform.
> the cform correctly delivers the bodytext (after changing all the encoding 
> settings in the web.xml and serializer configs to "UTF-8") with 
> specialcharacters correctly.
> However the mail which is generated doesn't encode the bodytext correctly. 
> the 
> weird thing is that when I submit the same URL I gave to the SendMailaction 
> via 
> a browser, the character-encoding is correct.
> when looking at the following sourcecode, then Bodytext should logically be 
> encoded with UTF-8 (as everything else is done with UTF-8). However in order 
> to 
> work, I had to switch to ISO-8859-1 for this single line. Otherwise the 
> generated html-mail had strange special characters..
> var cocoonurl = "cocoon:/mailtext/arllink/" + myarl + "?body=" + 
> java.net.URLEncoder.encode(model.KollegeEmailBodytext,"ISO-8859-1");
>   
> var mailsender = cocoon.getComponent
> (Packages.org.apache.cocoon.mail.MailSender.ROLE);
> mailsender.setSmtpHost(cocoon.parameters["eohb_smtp_host"],cocoon.parameters
> ["eohb_smtp_user"],cocoon.parameters["eohb_smtp_pwd"]);
> mailsender.setTo(model.KollegeEmail);
> mailsender.setFrom(cocoon.parameters["eohb_smtp_from"]);
> mailsender.setBodyFromSrc(cocoonurl);
> mailsender.setSubject("eOHB Link");
> mailsender.setCharset("UTF-8");
> mailsender.setBodyFromSrcMimeType("text/html; charset=utf-8");
> mailsender.sendIt();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (COCOON-1438) [MAIL] Weird Encoding problem with SendMailAction

2006-10-14 Thread JIRA
[ 
http://issues.apache.org/jira/browse/COCOON-1438?page=comments#action_12442280 
] 

Jörg Heinicke commented on COCOON-1438:
---

1. You should NOT change the container-encoding in web.xml.

2. What's model.KollegeEmailBodytext?

> [MAIL] Weird Encoding problem with SendMailAction
> -
>
> Key: COCOON-1438
> URL: http://issues.apache.org/jira/browse/COCOON-1438
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Mail
>Affects Versions: 2.1.6
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Gabriel Gruber
> Assigned To: Cocoon Developers Team
>
> I have a flowscript, wich uses the sendmailaction to send a mail.
> As the mail is supposed to be a html-mail, it is generated through a cocoon-
> pipeline and feeded by a request-param which contains the body-text.
> this body-text is first submitted by a cform.
> the cform correctly delivers the bodytext (after changing all the encoding 
> settings in the web.xml and serializer configs to "UTF-8") with 
> specialcharacters correctly.
> However the mail which is generated doesn't encode the bodytext correctly. 
> the 
> weird thing is that when I submit the same URL I gave to the SendMailaction 
> via 
> a browser, the character-encoding is correct.
> when looking at the following sourcecode, then Bodytext should logically be 
> encoded with UTF-8 (as everything else is done with UTF-8). However in order 
> to 
> work, I had to switch to ISO-8859-1 for this single line. Otherwise the 
> generated html-mail had strange special characters..
> var cocoonurl = "cocoon:/mailtext/arllink/" + myarl + "?body=" + 
> java.net.URLEncoder.encode(model.KollegeEmailBodytext,"ISO-8859-1");
>   
> var mailsender = cocoon.getComponent
> (Packages.org.apache.cocoon.mail.MailSender.ROLE);
> mailsender.setSmtpHost(cocoon.parameters["eohb_smtp_host"],cocoon.parameters
> ["eohb_smtp_user"],cocoon.parameters["eohb_smtp_pwd"]);
> mailsender.setTo(model.KollegeEmail);
> mailsender.setFrom(cocoon.parameters["eohb_smtp_from"]);
> mailsender.setBodyFromSrc(cocoonurl);
> mailsender.setSubject("eOHB Link");
> mailsender.setCharset("UTF-8");
> mailsender.setBodyFromSrcMimeType("text/html; charset=utf-8");
> mailsender.sendIt();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (COCOON-1825) Ajax errror when an active state widget become invisible state widget

2006-10-14 Thread JIRA
[ 
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12442276 
] 

Guillaume Déflache commented on COCOON-1825:


About Antonio's last comment: I think Vincent needs to tell us why he added a 
'span' element with the 'id' attribute when there already was the 'table' 
element to "hook" the 'id' attribute to. Was that really to workaround an IE 
bug as Sylvain suggested, or was only a copy/paste error?

To sum up, for the others modifications IMHO:
1) "fi:placeholder" should be left alone as Sylvain said
2) "fi:group" and "fi:struct" should use a "div" element instead of a "span" 
one, because if we do so:
   i) hope to validate Cocoon Forms HTML generated pages remains: spans cannot 
contain block markup, whereas divs can contain both inline and block markup, so 
nested "div-fi:*'s" are more likely to produce valid HTML
   ii) this is consistent with the way "fi:union" is already handled
   also:
   iii) for rendering issues, these divs can always be made inline in CSS if 
needed
   iv) in practice groups (and structs? never used them) almost always are 
block-level anyway... 
 3) BTW the "fi:imagemap" template probably also lacks an "id" attribute... and 
I have not checked "advanced" styling, there could be more missing... (BTW 
isn't GoogleMap widget _advanced_ styling!?!)

So I volunteer to redo the 1st proposed patch with all above suggestions 
applied! :)
But please Vincent do tell us what was your purpose with the "double-id" thingy!

BTW perhaps someone could add "[PATCH]" in the subject (and fix the typo...) to 
show a patch is available?

> Ajax errror when an active state widget become invisible state widget
> -
>
> Key: COCOON-1825
> URL: http://issues.apache.org/jira/browse/COCOON-1825
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Forms
>Affects Versions: 2.1.9
>Reporter: vincent Demay
> Assigned To: Antonio Gallardo
>
> Some widget (field with selection-list and styling=radio, group, etc...)  can 
> not be hidden (state=invisible)in ajax mode.
> I declare some widgets without state attribute in the form definition, my 
> form is in ajax mode, when I set the widget state to INVISIBLE, the ajax 
> response can not be applied to the form because  id="widget-name">... is not available in source code.
> I think about 2 patches : 
> *putting a  in forms-field-styling.xsl where is not set
> *or modifing abstractWidgetDefinition.java in ordre to generate a placeholder 
> around each widget (but patch seems to need a lot of modification in 
> forms-field-styling.xsl too)
> Here is the patch for first 
> --- forms-field-styling.orig  2006-04-13 15:37:06.590221200 +0200
> +++ forms-field-styling.xsl   2006-04-13 15:38:22.525291200 +0200
> @@ -198,8 +198,9 @@
>  
>   select="string(fi:styling/@list-orientation) != 'horizontal'"/>
>  
> -  
> - title="{fi:hint}">
> +  
> +   
> +   title="{fi:hint}">
>
>  
>  
> @@ -224,6 +225,7 @@
>  
>
>  
> +
>
>
>  
> @@ -682,22 +684,24 @@
>| know where to insert the widget if it becomes visible
>+-->
>
> -
> +
>
>
>
>
> -
> + 
>
>  
>
>
> -
> +
>
> +  
> +  
>  
>
>  
> Here for the second
> --- AbstractWidget.orig   2006-04-13 15:31:07.851701200 +0200
> +++ AbstractWidget.java   2006-04-13 15:30:31.446616200 +0200
> @@ -483,6 +483,10 @@
>  public void generateSaxFragment(ContentHandler contentHandler, Locale 
> locale)
>  throws SAXException {
>  
> + AttributesImpl placeHolderAttrs = new AttributesImpl();
> + placeHolderAttrs.addCDATAAttribute("id", getRequestParameterName());
> +contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", 
> placeHolderAttrs);
> +
>  if (getCombinedState().isDisplayingValues()) {
>  // FIXME: we may want to strip out completely widgets that 
> aren't updated when in AJAX mode
>  String element = this.getXMLElementName();
> @@ -497,15 +501,9 @@
>  
>  generateItemSaxFragment(contentHandler, locale);
>  
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element);
> -
> -} else {
> -// Generate a placeholder that can be used later by AJAX updates
> -AttributesImpl attrs = new AttributesImpl();
> -attrs.addCDATAAttribute("id", getRequestParameterName());
> -contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", attrs);

[jira] Updated: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer

2006-10-14 Thread Geurt Wisselink (JIRA)
 [ http://issues.apache.org/jira/browse/COCOON-1894?page=all ]

Geurt Wisselink updated COCOON-1894:


Attachment: SQLTransformer.java

Dear Antonia,

In the process we found several other issues with the SQL transformer:
-   encoding did not work on Oracle
-   we had the need for XML inside variables

The attachment contains the version we use now with success. It handles
UTF8, etc as it must be.
I created it from the 2.2 version. 

Please check it out and add it to cocoon 2.2

Regards Geurt Wisselink



> Added support for the SQL:XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java, 
> SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira