Re: SendMailTransformer
On 01.10.2008 01:46, Christian Decker wrote: I wonder why you are not using 2.2's SendMailTransformer. There actually isn't any reason that I'm not using the 2.2's SendMailTransformer, except I was unable to find it. You see, I;m using mvn to manage the project and there appears to be no online repository that provides me the 2.2's version of cocoon-mail (according to http://maven.ozacc.com/search?keyword=cocoon-mail&type=all ) or am I just shooting in the wrong direction? I see it in the sources. Maybe we are just not yet releasing the mail block in 2.2. Reinhard? Is there any work left to do with this block? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMailTransformer
Joerg Heinicke wrote: > > That's indeed the problem. The getLogger() implementations of 2.1 and > 2.2 are incompatible. In 2.1 it returns > o.a.avalon.framework.logger.Logger while in 2.2 we Apache Commons > Logging and so the method returns o.a.commons.logging.Log. Compiling > 2.1.9's SendMailTransformer against 2.2 libs should fix this but I > wonder why you are not using 2.2's SendMailTransformer. > There actually isn't any reason that I'm not using the 2.2's SendMailTransformer, except I was unable to find it. You see, I;m using mvn to manage the project and there appears to be no online repository that provides me the 2.2's version of cocoon-mail (according to http://maven.ozacc.com/search?keyword=cocoon-mail&type=all ) or am I just shooting in the wrong direction? Regards, Christian -- View this message in context: http://www.nabble.com/SendMailTransformer-tp19680193p19752383.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMailTransformer
On 01.10.2008 01:14, Christian Decker wrote: java.lang.NoSuchMethodError: org.apache.cocoon.mail.transformation.SendMailTransformer.getLogger()Lorg/apache/avalon/framework/logger/Logger; at org.apache.cocoon.mail.transformation.SendMailTransformer.setup(SendMailTransformer.java:313) BTW: I'm using cocoon-mail-2.1.9 with cocoon 2.2, is that a problem and if yes how could I work around it? That's indeed the problem. The getLogger() implementations of 2.1 and 2.2 are incompatible. In 2.1 it returns o.a.avalon.framework.logger.Logger while in 2.2 we Apache Commons Logging and so the method returns o.a.commons.logging.Log. Compiling 2.1.9's SendMailTransformer against 2.2 libs should fix this but I wonder why you are not using 2.2's SendMailTransformer. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SendMailTransformer
Felix Knecht-2 wrote: > > Christian Decker schrieb: >> Hi all, >> >> I'm currently looking into the SendMailTransformer for the sending of >> emails as it looks like the best choice for this job. But I got stuck >> pretty fast and the web isn't too >> helpful either. What I'm having problems with is that I don't see how >> to get the templates, fill them in using JX and then passing them to >> the SendMailTransformer. Somehow everything I found on the web was on >> how to send unparameterized emails directly from the sitemap, which is >> not helpful at all :-( >> Does someone know a good place for me to learn how to use this? >> > See also http://cocoon.apache.org/2.2/blocks/mail/1.0/1099_1_1.html > You can use jx-generator instead of default generator to get some data > into the 'sendmail.xml'. > > HTH, but I haven't tested it. > > Felix > >> Regards, >> Christian > Hi again, I think that I'm on the right track now: I have a flowscript that uses processPipelineTo to actually call the pipeline that's send the mail and all the pipelines in place to get the template, fill it up with JX and then pass it to the transformer. Except I got this little problem now: java.lang.NoSuchMethodError: org.apache.cocoon.mail.transformation.SendMailTransformer.getLogger()Lorg/apache/avalon/framework/logger/Logger; at org.apache.cocoon.mail.transformation.SendMailTransformer.setup(SendMailTransformer.java:313) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) at $Proxy15.setup(Unknown Source) ... Any idea why? BTW: I'm using cocoon-mail-2.1.9 with cocoon 2.2, is that a problem and if yes how could I work around it? Regards, Christian -- View this message in context: http://www.nabble.com/SendMailTransformer-tp19680193p19751197.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mock webservices - possible use for Cocoon 3.0
Reinhard Pötz wrote: Luca Morandini wrote: Kamal wrote: Hi, I have been thinking about testing REST based web services of late. It occurred to me that these web services are very difficult to test Really ? My impression is the opposite: a REST-style web service should be usable by humans and machines alike, which makes them easier to test (easier then the RPC-style web services, anyway). Same impression here. The Cocoon 3 integration tests should give you some hints how the testing can be done via HTTP. See the cocoon-sample and cocoon-sample-webapp module. OK, I should clarify. The problem with REST style web services are the same for non-REST style web services. My above statement was probably not the best one. In many cases, you do not own the service. For example, it may be impossible to force certain error conditions. Even for systems that are in your control, may not be easily mocked. Here is a (fictional) use case. I have a weather forcast interface that relies specifies dates. That is, you specify a date, then you get returned the weather for that day. I could setup requests for a particular date, but those dates may become irrelevant in a couple of months (because the interface only supports forecasting). To make things more difficult, the weather service may return your date in the response. Now, if you could take the request, work out what date it selected and then create a mock response based on those dates, you can unit test your interface. I realise that Cocoon 2.1 and 2.2 may support this, but I think the syntax described is very, well, cocoon-y. It may be great for those who have been working with Cocoon for years, but it isn't user friendly for the intended purpose. That is why I was thinking about some other process we could use. Now, all that said, after some more Googling, I did find the following: http://synapse.apache.org/index.html So maybe what I want to do is look at that (though the documentation seems a little confusing to me, but only because my understanding of SOAP based interfaces is pretty poor). against. I was thinking that maybe there is some funky way of mocking a web service, using XPath and regexes to match on the requst, and use a templating language to generate the response (based on variables generated from the XPath and regexes). I was thinking maybe Cocoon 3.0 might help me here. I think you could do the same with 2.1 or 2.2 as well. Yes, or you can use the Cocoon 3 REST module which provides a JSR311 inspired controller implementation. Also see http://cocoon.apache.org/3.0/features.html for a basic example. OK, that is nicer. I may look at that. Regarding your testing question above, those REST controller classes can be unit tested easily. -- Kamal Bhatt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mock webservices - possible use for Cocoon 3.0
Luca Morandini wrote:
> Kamal wrote:
>> Hi,
>> I have been thinking about testing REST based web services of late. It
>> occurred to me that these web services are very difficult to test
>
> Really ? My impression is the opposite: a REST-style web service should
> be usable by humans and machines alike, which makes them easier to test
> (easier then the RPC-style web services, anyway).
Same impression here.
The Cocoon 3 integration tests should give you some hints how the
testing can be done via HTTP. See the cocoon-sample and
cocoon-sample-webapp module.
>> against. I was thinking that maybe there is some funky way of mocking
>> a web service, using XPath and regexes to match on the requst, and use
>> a templating language to generate the response (based on variables
>> generated from the XPath and regexes). I was thinking maybe Cocoon 3.0
>> might help me here.
>
> I think you could do the same with 2.1 or 2.2 as well.
Yes, or you can use the Cocoon 3 REST module which provides a JSR311
inspired controller implementation. Also see
http://cocoon.apache.org/3.0/features.html for a basic example.
Regarding your testing question above, those REST controller classes can
be unit tested easily.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
