I am not sure exactly why it stopped working, but I have noticed that
sometimes Resin, over time, becomes more and more spec-compliant. this
often means things that worked in the past, even though they were
against the spec, stop working.
check your .tld file to make sure that the moduleName
Hi all,
Long story short: I started consulting in a company that is developing
a product using Tomcat. They want to be able to run the application in
different containers to make sure they are spec compliant and all, so
I suggested Resin as an alternative.
I've been able to configure the
--- Sergey Plehov [EMAIL PROTECTED] wrote:
This issue with Resin 3.1.2 and Resin 3.1.3
I send in attachment source files.
Thanks Sergey. I have filed a new bug report:
http://bugs.caucho.com/view.php?id=2048
At the moment, there is not a good workaround, i.e. you would need to
You could probably implement your own authenticator, possibly just
subclassing the JdbcAuthenticator (see below), then use that
authenticator in resin-web.xml.
I myself wrote a patch for a Tomcat only webapp, that contains this
plus dummy implementations of Tomcat classes/interfaces like
Yes, Resin 3.x is much more picky about rtexprvaluetrue/rtexprvalue
in your TLD files.
That is most probably what you are seeing.
Mike Wynholds wrote:
I am not sure exactly why it stopped working, but I have noticed that
sometimes Resin, over time, becomes more and more spec-compliant.
this
For us, migrating from 2.1 to 3.0 took longer than expected.
First you need to restructure your resin.conf and possibly web.xml (as
Resin 3.0 is much more picky about the order of the tags).
You need to make sure rtexprvalue is provided in your TLDs when
appropriate, as currently discussed in a
It sounds great, and especially thanks for the update from resin
developers. When this is solved, axis users will not need to manually
modify the axis2-generated stub code. Looking forward to it ...
Huitang
Emil Ong wrote:
--- Huitang Li [EMAIL PROTECTED] wrote:
I found the cause of
