It'd be good to get a public update out there to run the new JSF
releases as part of JEE 5 (I realize this is at the bottom of most
other's priorities).
Remy Maucherat wrote:
Candidate binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.9/
According to the (slightly) up
Was there ever a condition where the listeners wouldn't run?
Remy Maucherat wrote:
Hi,
I tested JSF since some people said the listener wasn't being found
(the said listener is declared in a TLD which is in a JAR). I found it
worked very well, but the way it is handled is funny because of the
+1
Remy Maucherat wrote:
Hi,
In line with what Filip wanted to have, I propose releasing a new
6.0.3 test build, which will incorporate the fixes that have been made
since 6.0.2.
Comments ?
Rémy
-
To unsubscribe, e-mail:
Logic could have very well changed in the JSF 1.2 API implementation of the
FacesServlet, I would first compare your code to the source distribution of JSF
1.2 available at Java.net.
>I guess it would help to specify what kind of problem I am experiencing!!!
>;-)
>
>Here is the exception stack
What's not working specifically?
>My Web application relies on a custom Faces servlet to handle server
>errors. This custom Faces servlet used to work well inside Tomcat
>5.5.16 but not anymore in Tomcat 6.0.2. I do not know if this problem
>is a limitation of Tomcat 6.0.2 or a change in the way J
awesome :-)
>I downloaded a snapshot of the sources today and have verified that
>the converter problem is solved. The page that uses a converter in
>jsf-cardemo works fine now.
>
>Thanks.
>
>Martin
>
>On 11/29/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>> Martin Dubuc wrote:
>> > There seems
btw, I can't believe that wouldn't have gotten caught in the TCK in general
checking of literal used in deferred EL assignment.
>[EMAIL PROTECTED] wrote:
>> It doesn't look like it's picking up the fact that the expression is
>literal.
>>
>> Both pertinent classes look correct from Tomcat:
>>
Literals are acceptable for both MethodExpression and ValueExpression in both
deferred and immediate invocation.
MethodExpression example: public String method() can just be 'cart', which will
be returned as the result.
In the converter case, a single attribute handles both the 'named' converte
It doesn't look like it's picking up the fact that the expression is literal.
Both pertinent classes look correct from Tomcat:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/jasper/el/JspValueExpression.java
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apac
What version of JSF 1.2 are you running exactly?
>There seems to be a problem with Converter subclasses when running a
>JSF 1.2 Web app inside Tomcat 6.0.2. This problem can be reproduced by
>running the JSF car demo Web app that comes with the JSF 1.2
>distribution. To reproduce, in the car demo
Would it be suitable to focus on JEE 5 compliance in the short run for a soon
to be released TC 6, then enhance the value adds of TC for a 6.1 release later
this year?
>On 5/5/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Remy started a thread talking about source tree reorg. It soon
ondering in relation to debuggers, if there's a better way to
tackle this?
Again, it's big complaint by users and having this simple wrapper for
deferred expression, within the Jasper compiler, would be really beneficial.
-- Jacob
--
Given the 'supposed' issues with Tomcat's classloader and static/class
references not being re-claimed, I doubt that these patches would even work
other than in theory.
>Costin Manolache wrote:
>> Why would anyone serve 'uncached small files' or parse properties on
>> each request ???
>> Well,
of the org.apache.el explicitly in the Jasper code base
2) Minimize the use of org.apache.el implementation references to
possibly allow other EL implementations (even for alternate syntaxes) to
be used at runtime, such as using a JEXL or OGNL ExpressionFactory w/ JSP.
--
Jacob Ho
the
current compilation
is not the only solution or only way to generate java from the jsps.
I also agree with you that JSPs are complex enough that messing with the
code generation
is too dangerous - I wouldn't touch it, but if some people have patches, we
should consider
them.
Costin
You can't compare a JSR spec to something like commons-logging, plus
there are people requesting that it's separate for practical use.
Remy Maucherat wrote:
Jacob Hookom wrote:
I would like to suggest splitting EL off as a separate library from
Tomcat. The EL-API is expected to r
I would like to suggest splitting EL off as a separate library from
Tomcat. The EL-API is expected to rev in it's own specification in the
future. It is not have any dependencies on the Servlet API or JSP API
and can be utilized in the same fashion as the commons-el project.
--
Jacob H
ical to just use the org.apache.el for expression
validation without maintaining a separate set of parsing logic within
jasper itself?
I guess coming from the Facelets project, I just delegated pre-parsing
to the javax.el.ExpressionFactory instead of re-implementing the EL-spec
within the compile
What steps would I need to take to get contributor status and develop
the JSP 2.1 implementation with the rest of the tomcat-dev team? Do I
have to get elected, then complete the ICLA or is it in the reverse order?
Thanks!
Jacob
Bill Barker wrote:
-Original Message-
From
I was under the assumption that we couldn't include the javax.el.* stuff under
Apache licensing-- hence the JSP and Servlet API folders within Tomcat.
>
>Bill Barker wrote:
>> Shouldn't we also have something under servletapi for the javax.el stuff?
>I was applying lazy instantiation ;) When some
Thanks Mark!
>
>Mark Thomas wrote:
>> Based on this, I propose the following changes to svn.
>>
>> copy /tomcat/jasper/tc5.5.x/ to /tomcat/jasper/tc6.0.x/
>Slight change. I removed the jasper2 directory so
>/tomcat/jasper/tc5.5.x/ was copied to /tomcat/jasper/tc6.0.x/
>
>> create /tomcat/jasper/t
I've posted an initial contribution of a complete EL-API implementation
under Apache 2.0 licensine, along with the EL-API itself (JSR-245-EL).\
EL Implementation (org.apache.el.*)
http://www.hookom.net/jacob/tomcat/el.zip
EL API (javax.el.*)
http://www.hookom.net/jacob/jsr245-el.zip
I&#x
g and code placement-- are there
'rules' the group is expecting? Also, would you like to keep the EL
separate and instead guide EL implementation into Commons-EL?
If anyone has any clarifications, questions, or recommendations, just
let me know--
--
Jacob Hookom - Minneapolis
to gain
those capabilities. Ex, the JSF RI silently relies on Glassfish's Injection
objects to provide spec behavior.
-- Jacob
>
>Personally I am a fan of the light-weight approach. Using Tomcat but
>adding "enterprise" value at webapp level with Spring and Hiberna
for
expression serialization and some of the new EL-API concerns.
-- Jacob
Bill Barker <[EMAIL PROTECTED]> wrote on 12/20/2005, 09:51:18 PM:
>
>
> > -Original Message-
> > From: Remy Maucherat [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 20
25 matches
Mail list logo
