Re: JASPIC progress
Mark Thomas-2 wrote
> As I thought about this some more, I realised that there is nothing in
> the Servlet Container profile in the JASPIC spec (that I have been able
> to find) about when AuthConfigProvider registration takes place. This
> means that AuthConfigProvider registrations and de-registrations could
> take place while the web application is running.
It's a good point indeed. In practice it always seems to be either a
ServletContainerInitializer or a ServletContextListener, or of course via a
server proprietary method (outside the application).
I'm not entirely sure what the use case was for having this flexibility.
I'll try to see if I can get a clarification from Ron about this. I wonder
how many implementations even support registrations and de-registrations at
arbitrary moments.
Mark Thomas-2 wrote
> - have authenticate() check (i.e. on every request) for a JASPIC config
> and use it if present
> - cache what I can (for speed) and use a RegistrationListener to track
> updates
That should indeed be the approach.
What the RI roughly does is from its embedded Tomcat in
AuthenticatorBase#invoke it calls an adapter:
com.sun.web.security.RealmAdapter#invokeAuthenticateDelegate
That contains code like the following (simplified):
ServerAuthConfig serverAuthConfig = null;
if (helper != null) {
serverAuthConfig = helper.getServerAuthConfig();
}
if (serverAuthConfig != null) {
// JSR 196 is enabled for this application. Call it.
result = validate(request, response, config, authenticator,
calledFromAuthenticate);
} else {
// JSR 196 is not enabled for this application. Use the current
authenticator
result = ((AuthenticatorBase) authenticator).authenticate(request,
response, config);
}
The "helper" variable is set outside the request call, so it functions as a
very quick switch.
getServerAuthConfig() essentially does the following:
AuthConfig authConfig = listener.getConfig();
if (authConfig == null) {
authConfig = factory.getConfigProvider(layer, appCtxt, listener);
listener.setConfig(authConfig);
}
return authConfig;
Where listener and the AuthConfig it holds are just instance variables. One
subtle thing to notice is that when the listener is called to track an
update the config it holds is null'ed instead of actually being updated at
that point.
The actual implementation is a bit more hairy but in broad lines it boils
down to the above, see:
com.sun.enterprise.security.jmac.config.ConfigHelper#getServerAuthConfig
Hope this helps.
Kind regards,
Arjan Tijms
--
View this message in context:
http://tomcat.10.x6.nabble.com/JASPIC-progress-tp5046266p5046307.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, See you guys are making good progress with the JASPIC implementation in Tomcat. One commit that I noticed is the following: https://github.com/apache/tomcat/commit/3e1b4931867a12a74e9e9fe7ff86484cc65a21e6 It says: "Remove the programmatic login/logout override, as I don't see how JASPIC can interact with it." I haven't looked further for the exact context here, but in general JASPIC interacts with both the corresponding methods in HttpServletRequest. In case of login(), an exception has to be thrown when a SAM is configured. The rationale is that a SAM can't handle just login(), as a SAM is an authentication mechanism that may or may not delegate to an identity store. Login() is intended to go to a server specific identity store (Tomcat calls it realm). Since there's no standard mechanism for a SAM to delegate to this server specific identity store, it can't handle login(), hence the exception. In case of logout(), next to what the server normally would do, the SAM's cleanSubject() method has to be called. Hope this helps. Kind regards, Arjan Tijms -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5043520.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Fri, Oct 16, 2015 at 12:56 PM, Jess Holle [via Tomcat] <ml-node+s10n5040848...@n6.nabble.com> wrote: > My understanding with JASPIC is that one should be able to add > authentication mechanisms that (1) use the same code across any > container that supports JASPIC [as Mark notes] and (2) still use > standard security constraints in one's web.xml to configure > authentication constraints. Those are indeed the main reasons for JASPIC. JASPIC authentication modules should be fully equivalent to any of the build-in authentication mechanisms like FORM, BASIC, etc in terms of what they can do and how they are treated by the container. This specifically means they fully integrate with any of the existing security mechanisms, such as constraints in web.xml. An other advantage of JASPIC is that the same authentication module can be either installed at the container, shipped with the application, or deployed separately (via its own war). Furthermore, the Security EG (JSR 375) is looking at building higher level functionality that uses the JASPIC APIs as a base, so this may possibly increase the demand for JASPIC in the future. Kind regards, Arjan Tijms > > -- > Jess Holle > > > - > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > > > If you reply to this email, your message will be added to the discussion > below: > http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040848.html > To unsubscribe from Consider support for the Servlet profile of JSR 196 > (JASPIC) in Tomcat 7.0.x, click here. > NAML -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040852.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
On Fri, Oct 16, 2015 at 4:27 PM, remm [via Tomcat] <ml-node+s10n5040857...@n6.nabble.com> wrote: > 2015-10-16 16:11 GMT+02:00 Arjan Tijms <[hidden email]>: > I was not talking about this future specification, since I never had a look. Okay, my bad. I thought it was in reply to the JSR 375 work. But what did you mean exactly then? Tomcat now ships with 6 "authenticators" if I'm not mistaken; Basic, Digest, Form, NonLogin, SSL, Spnego. If these used the JASPIC API of Tomcat, then at least when used with Tomcat these would be just as predictable when used with Tomcat as they are when using the proprietary (Authenticator) API, right? > So I plan to review the three auth modules that have been contributed, > that's a start. Good start indeed ;) Kind regards, Arjan Tijms > > Rémy > > > > If you reply to this email, your message will be added to the discussion > below: > http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040857.html > To unsubscribe from Consider support for the Servlet profile of JSR 196 > (JASPIC) in Tomcat 7.0.x, click here. > NAML -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040860.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Fri, Oct 16, 2015 at 3:35 PM, remm [via Tomcat] <ml-node+s10n5040855...@n6.nabble.com> wrote: > I still think it is far preferable at the moment to implement 4 or 5 > proprietary auth "modules" Well, the higher level functionality does not necessarily mean that JSR 375 is going to provide standard authentication modules that build on top of JASPIC (although this was mentioned at some point). It's for now more like introducing convenience APIs so users can more easily create their own custom modules. > that will behave predictably than try to use > this standard API that is far more complex and has behavior differences on > each server. Historically very little code has indeed been 100% portable between implementations of various APIs. Be it JPA, CDI, or even Servlet. That said, proprietary implementations of FORM may not all behave in exactly the same way either. They should, but I remember having seen small differences in the past where it concerns forwards, includes and redirects. So while I generally agree that there can be behavioral differences between each server, I'm not really sure if using the standard API vs proprietary API will make a huge difference there. Also, JASPIC is not a terribly complex API. Tedious for some things maybe, and low level and abstract, but it's rather small really and not overly complex (IMHO). > Of course it would be better if this was not the case. Of course, so another ongoing business is testing the implementations of all vendors and reporting behavioral differences and spec violations to them. I've added many of those to a series of tests here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic Some of those are likely to be fed back into the official TCK (which for EE 7 is really small, unfortunately). Kind regards, Arjan Tijms -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040856.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi there,
Haven't seen updates for some time here. Wonder what the current
status is and what exactly happened in the last months. Last commits
in the Tomcat repo are from 3 months ago.
Kind regards,
Arjan Tijms
On Thu, Jun 11, 2015 at 10:39 AM, markt [via Tomcat]
<ml-node+s10n5035913...@n6.nabble.com> wrote:
> On 10/06/2015 16:43, Arjan Tijms wrote:
>
>> Hi,
>>
>> On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat] <
>> [hidden email]> wrote:
>>
>>> I don't really understand what the requirement is here. Can you expand /
>>> point me to the part of the spec?
>>>
>>
>> It's simply that from within a SAM you can forward/include to a Servlet
>> using a dispatcher, such that the output of that Servlet is inserted in
>> the
>> response.
>
> Thanks for the clarification. You can do that easily from a Valve in a
> couple of lines of code. No need for extra internal plumbing that I can see.
>
> Mark
>
>>
>> It's in section 3.8.3.4 of the JASPIC spec:
>>
>>
>> "3.8.3.4
>> Forwards and Includes by Server Authentication Modules
>>
>> The message processing runtime must support the acquisition and use of
>> RequestDispatcher objects by authentication modules within their
>> processing
>> of validateRequest.
>>
>> Under the constraints defined by RequestDispatcher, authentication modules
>> must be able to forward and include using the request and response objects
>> passed in MessageInfo. In particular, an authentication module must be
>> able
>> to acquire a RequestDispatcher from the request obtained from MessageInfo,
>> and uses it to forward the request (and response) to a login form.
>> Authentication modules should catch and rethrow as an AuthException any
>> exception thrown by these methods."
>>
>>
>> A test/example showing this in practice is the following:
>>
>>
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching
>>
>> Specifically, this code shows both an include and a forward done by a SAM:
>>
>> public AuthStatus validateRequest(MessageInfo messageInfo, Subject
>> clientSubject, Subject serviceSubject) throws AuthException {
>> try {
>> HttpServletRequest request = (HttpServletRequest)
>> messageInfo.getRequestMessage();
>> HttpServletResponse response = (HttpServletResponse)
>> messageInfo.getResponseMessage();
>>
>> if ("include".equals(request.getParameter("dispatch"))) {
>> request.getRequestDispatcher("/includedServlet")
>>.include(request, response);
>>
>> // "Do nothing", required protocol when returning SUCCESS
>> handler.handle(new Callback[] { new
>> CallerPrincipalCallback(clientSubject, (Principal) null) });
>>
>> // When using includes, the response stays open and the
>> main
>> // resource can also write to the response
>> return SUCCESS;
>>
>> } else {
>> request.getRequestDispatcher("/forwardedServlet")
>>.forward(request, response);
>>
>> // MUST NOT invoke the resource, so CAN NOT return SUCCESS
>> here.
>> return SEND_CONTINUE;
>> }
>>
>> } catch (IOException | ServletException |
>> UnsupportedCallbackException e) {
>> throw (AuthException) new AuthException().initCause(e);
>> }
>> }
>>
>>
>> Sounds good. Thanks for the tip.
>>>
>>
>> You're welcome ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> mark
>>>
>>> -
>>> To unsubscribe, e-mail: [hidden email]
>>> <http:///user/SendEmail.jtp?type=node=5035887=0>
>>> For additional commands, e-mail: [hidden email]
>>> <http:///user/SendEmail.jtp?type=node=5035887=1>
>>>
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>>
>>> http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
>>> To unsubscribe from Consider support for the Servlet prof
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Wed, Jun 10, 2015 at 2:31 PM, Fjodor Vershinin [via Tomcat] ml-node+s10n5035882...@n6.nabble.com wrote: Hi, guys! This week goal is to replace current valve based authentication with JASPIC based mechanism. It is what I am currently working on. Nice ;) From my research Geronimo's implementation is also based on tomcat's valves, and it's pretty straightforward how to integrate SecurityValve into Tomcat's codebase. However, I am not sure, is that correct way? I'm pretty sure this should be the way forward, or at the very least the place where to start. Do you have better ideas? And what about code backward compatibility for Geronimo, should code ported back, or new Geronimo release can use our implementation? I can't speak for the Apache organization of course, but as an external observer I wouldn't hold my breath for a new Geronimo release. See David Blevins comments here: http://arjan-tijms.omnifaces.org/2014/05/implementation-components-used-by.html We are implementing JASPIC 1.1, and there will be quite a lot changes anyway. JASPIC 1.1 itself was not a huge change over JASPIC 1.0, but it did put some extra requirements in place like the ability to forward and include resources using the HttpServletRequest and HttpServletResponse that's made available to a SAM. If a Tomcat valve can already do forwards/includes correctly, then this is trivial to support (no extra code needed). However, IFF Tomcat would not support those, then some extra coding inside Tomcat's internals *may* be needed (but Mark would know more about how to forward then). Also, Geronimo uses OSGi framework in their code, which must be dropped off, because Tomcat is not OSGi based. What about JASPIC configuration, I am curious, where we want to hold configuration files. Different vendors use special xml files, for example geronimo-web.xml, for configuring realms and other security stuff. Do we need something like tomcat-web.xml? Not necessarily. JASPIC is first and foremost configured using a programmatic API from within the application. See http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html When an application performs this programmatic configuration (typically from a @WebListener/ServletContextListener), it overrides whatever auth-method is configured in web.xml, e.g. FORM, BASIC, etc. It's more or less a best practice not to put any auth-method in web.xml if the application configures JASPIC. When a JASPIC authentication module is configured programmatically via the standard JASPIC API, there is not really a mechanism available to delegate user/role retrieval to an identity store (Tomcat calls this realm). The JASPIC module is in full control then and ought to handle this itself using whatever internal mechanism it sees fit. Optionally (but highly recommended!) a JASPIC authentication module can be registered at the container level using a vendor specific mechanism. If I'm not mistaken Mark made some remarks about this earlier. Tomcat already has some dedicated configuration files for this. My take is that for step 1 it's best to focus on the programmatic installation of an authentication module (and wrapper artifacts) first, and make sure the most simple authentication case works (which means just passing the username/roles to the container and doing nothing else). Then look at the container side registration later. And what about JACC support? Geronimo uses JACC for authorization config, what about Tomcat? JACC is an entirely different specification. It standardizes some of the authorization decisions a container makes. It works in tandem with JASPIC, but is not required by it. I don't think it's needed to look at JACC for this project. Kind regards, Arjan Tijms Thanks, Fjodor 2015-05-04 16:49 GMT+03:00 Arjan Tijms [hidden email] http:///user/SendEmail.jtp?type=nodenode=5035882i=0: Hi, Great news! Do you have any definite start date for the actual coding already? A short while ago I did a very small and simple implementation of the Servlet BASIC auth mechanism using JASPIC, which is one of the 4 mechanisms required by Servlet. See: https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java Calling out to the identity store is however not standardised yet (the example code simply uses CDI) and has to be done in a Tomcat specific way. Kind regards, Arjan Tijms On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] [hidden email] http:///user/SendEmail.jtp?type=nodenode=5035882i=1 wrote: Good news, everyone! I am happy to announce that our project has been accepted to participate in GSoC. Now it's community binding period, so I need to introduce myself to other developers. Some brief information about me: My name is Fjodor Vershinin, I am 2'th grade computer science student from Estonia
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Wed, Jun 10, 2015 at 3:09 PM, markt [via Tomcat] ml-node+s10n5035886...@n6.nabble.com wrote: A Valve is certainly a likely candidate since the current Authenticator implementations are all Valves. It really depends on whether access is required to Tomcat's internals. If you need access to the internals, a Valve is probably the way to go. If the Servlet API is sufficient then a Filter may be an option. Depending on exactly what the integration points are there may be other options. Traditionally it has not been really possible to implement JASPIC via the Servlet API. A requirement of JASPIC is that a SAM is called before the Servlet chain is invoked, which is by definition not possible (Filters are part of that chain). Even if you relax the rules a little, then you'd need to make sure that the Filter that's calling the SAM is absolutely guaranteed to be the very first, with no possible way that any other Filter could be placed before it. Then, via the standard Servlet API you cannot really establish the authenticated identity. You can fake it a little by wrapping HttpServletRequest and returning your own values for things like isUserInRole, but you'd also have to process auth-constraints defined in web.xml and @WebServlet annotations, which is quite hard to do from a filter (you'd be duplicating the web.xml parsing and annotation scanning from the Servlet container). Also, a SAM should be called when HttpServletRequest.authenticate and HttpServletRequest.logout is called from a Filter or Servlet. Typically the best thing is that whatever kind of code the Servlet container is already using to implement the standard authentication mechanisms BASIC, FORM, etc is also used to implement JASPIC. I have to double check, but if I'm not mistaken this is what most containers are indeed doing. Is the configuration always going to be per web application (in which case context.xml is a likely candidate) or can it be per Host or per Engine (which suggests server.xml)? There are two options in JASPIC: 1. Per web application. Programmatically (from within the application) this is done by passing an appContextID to the JASPIC factory that is used for registration. This appContextID is computed as follows: String getAppContextID(ServletContext context) return context.getVirtualServerName() + + context.getContextPath(); } 2. Globally for the entire container (all applications running on it). Programmatically this is done by passing a null to the JASPIC factory. Doing this from an application is maybe rare, but with it you could theoretically deploy an authentication module to a server by deploying a war that only contains the SAM and the registration code. Are there any 'standard' configuration files defined by JASPIC? Nope. I more or less happened to mention this in my reply to Fjodor, but there is not a single standard configuration file. The only standardized way is by using the AuthConfigFactory. Kind regards, Arjan Tijms And what about JACC support? Geronimo uses JACC for authorization config, what about Tomcat? Tomcat currently uses Realms. It was not intended to implement JACC as part of the GSoC project. If the project goes well and the JASPIC work is completed early, taking a look at JACC would be a useful thing to do. Mark Thanks, Fjodor 2015-05-04 16:49 GMT+03:00 Arjan Tijms [hidden email] http:///user/SendEmail.jtp?type=nodenode=5035886i=0: Hi, Great news! Do you have any definite start date for the actual coding already? A short while ago I did a very small and simple implementation of the Servlet BASIC auth mechanism using JASPIC, which is one of the 4 mechanisms required by Servlet. See: https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java Calling out to the identity store is however not standardised yet (the example code simply uses CDI) and has to be done in a Tomcat specific way. Kind regards, Arjan Tijms On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] [hidden email] http:///user/SendEmail.jtp?type=nodenode=5035886i=1 wrote: Good news, everyone! I am happy to announce that our project has been accepted to participate in GSoC. Now it's community binding period, so I need to introduce myself to other developers. Some brief information about me: My name is Fjodor Vershinin, I am 2'th grade computer science student from Estonia. One of my hobbies is writing OSS software, mainly in Java and Python. I hope to finish JASPIC implementation during this summer and make Tomcat better ;) Fjodor. 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin [hidden email] http:///user/SendEmail.jtp?type=nodenode=5034072i=0: Hello! It looks like ASF has been selected for GSOC 2015 and I am interested in pushing this project forward. So, in meantime I'll start writing proposal
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi,
On Wed, Jun 10, 2015 at 3:28 PM, markt [via Tomcat]
ml-node+s10n5035887...@n6.nabble.com wrote:
I don't really understand what the requirement is here. Can you expand /
point me to the part of the spec?
It's simply that from within a SAM you can forward/include to a Servlet
using a dispatcher, such that the output of that Servlet is inserted in the
response.
It's in section 3.8.3.4 of the JASPIC spec:
3.8.3.4
Forwards and Includes by Server Authentication Modules
The message processing runtime must support the acquisition and use of
RequestDispatcher objects by authentication modules within their processing
of validateRequest.
Under the constraints defined by RequestDispatcher, authentication modules
must be able to forward and include using the request and response objects
passed in MessageInfo. In particular, an authentication module must be able
to acquire a RequestDispatcher from the request obtained from MessageInfo,
and uses it to forward the request (and response) to a login form.
Authentication modules should catch and rethrow as an AuthException any
exception thrown by these methods.
A test/example showing this in practice is the following:
https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/dispatching
Specifically, this code shows both an include and a forward done by a SAM:
public AuthStatus validateRequest(MessageInfo messageInfo, Subject
clientSubject, Subject serviceSubject) throws AuthException {
try {
HttpServletRequest request = (HttpServletRequest)
messageInfo.getRequestMessage();
HttpServletResponse response = (HttpServletResponse)
messageInfo.getResponseMessage();
if (include.equals(request.getParameter(dispatch))) {
request.getRequestDispatcher(/includedServlet)
.include(request, response);
// Do nothing, required protocol when returning SUCCESS
handler.handle(new Callback[] { new
CallerPrincipalCallback(clientSubject, (Principal) null) });
// When using includes, the response stays open and the main
// resource can also write to the response
return SUCCESS;
} else {
request.getRequestDispatcher(/forwardedServlet)
.forward(request, response);
// MUST NOT invoke the resource, so CAN NOT return SUCCESS
here.
return SEND_CONTINUE;
}
} catch (IOException | ServletException |
UnsupportedCallbackException e) {
throw (AuthException) new AuthException().initCause(e);
}
}
Sounds good. Thanks for the tip.
You're welcome ;)
Kind regards,
Arjan Tijms
Cheers,
mark
-
To unsubscribe, e-mail: [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5035887i=0
For additional commands, e-mail: [hidden email]
http:///user/SendEmail.jtp?type=nodenode=5035887i=1
--
If you reply to this email, your message will be added to the discussion
below:
http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035887.html
To unsubscribe from Consider support for the Servlet profile of JSR 196
(JASPIC) in Tomcat 7.0.x, click here
http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA==
.
NAML
http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
--
View this message in context:
http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5035891.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, Fjodor, for you (and everyone else interested) I've created a central hub page for JASPIC on ZEEF.com, see https://jaspic.zeef.com It contains links to existing implementations, various examples, articles, and background. Hope it helps! Kind regards, Arjan Tijms On Mon, May 4, 2015 at 10:06 PM, Mark Thomas-2 [via Tomcat] ml-node+s10n5034096...@n6.nabble.com wrote: On 04/05/2015 10:49, Fjodor Vershinin wrote: Good news, everyone! I am happy to announce that our project has been accepted to participate in GSoC. Now it's community binding period, so I need to introduce myself to other developers. Some brief information about me: My name is Fjodor Vershinin, I am 2'th grade computer science student from Estonia. One of my hobbies is writing OSS software, mainly in Java and Python. I hope to finish JASPIC implementation during this summer and make Tomcat better ;) Fjodor. That is good news. Welcome to the Tomcat community. A good way to get to know the community better is to work on some simple bug fixes. You are welcome to choose one yourself or you, if you prefer a recommendation, I suggest bug 57665. If you do opt to look at bug 57665, you might find my recent fix for bug 57856 (r1676364) informative. Mark - To unsubscribe, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5034096i=0 For additional commands, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5034096i=1 -- If you reply to this email, your message will be added to the discussion below: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034096.html To unsubscribe from Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x, click here http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA== . NAML http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034845.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, Great news! Do you have any definite start date for the actual coding already? A short while ago I did a very small and simple implementation of the Servlet BASIC auth mechanism using JASPIC, which is one of the 4 mechanisms required by Servlet. See: https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/authmodules/BasicAuthModule.java Calling out to the identity store is however not standardised yet (the example code simply uses CDI) and has to be done in a Tomcat specific way. Kind regards, Arjan Tijms On Monday, May 4, 2015, Fjodor Vershinin [via Tomcat] ml-node+s10n503407...@n6.nabble.com wrote: Good news, everyone! I am happy to announce that our project has been accepted to participate in GSoC. Now it's community binding period, so I need to introduce myself to other developers. Some brief information about me: My name is Fjodor Vershinin, I am 2'th grade computer science student from Estonia. One of my hobbies is writing OSS software, mainly in Java and Python. I hope to finish JASPIC implementation during this summer and make Tomcat better ;) Fjodor. 2015-03-04 11:09 GMT+02:00 Fjodor Vershinin [hidden email] http:///user/SendEmail.jtp?type=nodenode=5034072i=0: Hello! It looks like ASF has been selected for GSOC 2015 and I am interested in pushing this project forward. So, in meantime I'll start writing proposal and hope this project will be selected to participate in Gsoc program. Best regards, Fjodor. 2015-02-10 22:44 GMT+02:00 Arjan Tijms [hidden email] http:///user/SendEmail.jtp?type=nodenode=5034072i=1: Hi, On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat] [hidden email] http:///user/SendEmail.jtp?type=nodenode=5034072i=2 wrote: If you do look at JBoss keep in mind it is GPL licensed and we need to be very careful that we don't end up with GPL'd code in Tomcat. That's absolutely true. The code there shouldn't not be copied in any way. It's only useful as an example of how a Tomcat Valve can integrate with something like JASPIC. As for the JASPIC code there, it wouldn't make sense to copy it anyway, since A) it's JBoss specific (builds up JBoss principal, calls JBoss security service, etc) and B) there are various issues with it (it looks like JBoss pretty much rewrote everything from scratch for Undertow, which is completely different). Personally, I'd look more much more closely at Geronimo. You're right, and since that one is Apache licensed one can even copy from it if needed. Keep in mind that part of the goal is to replace the existing authenticators with JASPIC modules. (As suggested on the Servlet EG list.) It's good to have that as part of the goal indeed. Such auth modules could even be implemented by a separate (group) of students if needed, as they would not necessarily depend on the JASPIC implementation for Tomcat. As long as that one is not finished they could test it on any existing JASPIC implementation (e.g. the RI, GlassFish). I think we all know that feeling - hence why I suggested it for GSoC. Yeah, I get that, thanks! It's still something that I'd really love to do, but with the work for the startup zeef.com, open source projects OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon for the security EG, there is not always much time left. I had this on my sketchy todo list for ~end of this month, but I'll see what happens with the GSoC project now ;) Kind regards, Arjan Mark - To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] If you reply to this email, your message will be added to the discussion below: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html To unsubscribe from Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x, click here. NAML -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. -- If you reply to this email, your message will be added to the discussion below: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5034072.html To unsubscribe from Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x, click here http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA== . NAML http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Tuesday, February 10, 2015, Fjodor Vershinin [via Tomcat] ml-node+s10n5029627...@n6.nabble.com wrote: Hello! I am CS student and it looks like that this task is quite interesting. I would take it for GSOC if ASF organization will be selected. Currently I have some time to do research in Tomcat codebase. Could you provide me some entry points? Thanks for your interest in this. An entry point could be my original JASPIC article that you can find here; http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html At the end of the article you'll find a list of resources. My approach would be to investigate how Tomcat integrates authentication modules, eg look at the source of the JAAS support in Tomcat; that code has to do similar integration. You can look at JBoss 7.x for an example too, it used Tomcat and an integration Valve (WebJaspiAuthenticator seehttp:// grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-web/7.1.1.Final/org/jboss/as/web/security/jaspi/WebJASPIAuthenticator.java ) Geronimo also implemented JASPIC and used Tomcat, so that implementation would be high on the list to study too. Many implementations have a (large) part of their code dedicated to handling some xml file where jaspic auth modules are defined. Strictly speaking this is not a required part of JASPIC, but it's somewhat expected for configuring modules at the container side (as apposed to from within the app archive). I did actually more or less promise to do this implementation myself, but so far havent found the time for it. Let me know if this is enough to get started. Kind regards, Arjan Thanks, Fjodor -- If you reply to this email, your message will be added to the discussion below: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029627.html To unsubscribe from Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x, click here http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4993387code=YXJqYW4udGlqbXNAZ21haWwuY29tfDQ5OTMzODd8LTM3MzU5NTg0OA== . NAML http://tomcat.10.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029633.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Tue, Feb 10, 2015 at 8:34 PM, Mark Thomas-2 [via Tomcat] ml-node+s10n502964...@n6.nabble.com wrote: If you do look at JBoss keep in mind it is GPL licensed and we need to be very careful that we don't end up with GPL'd code in Tomcat. That's absolutely true. The code there shouldn't not be copied in any way. It's only useful as an example of how a Tomcat Valve can integrate with something like JASPIC. As for the JASPIC code there, it wouldn't make sense to copy it anyway, since A) it's JBoss specific (builds up JBoss principal, calls JBoss security service, etc) and B) there are various issues with it (it looks like JBoss pretty much rewrote everything from scratch for Undertow, which is completely different). Personally, I'd look more much more closely at Geronimo. You're right, and since that one is Apache licensed one can even copy from it if needed. Keep in mind that part of the goal is to replace the existing authenticators with JASPIC modules. (As suggested on the Servlet EG list.) It's good to have that as part of the goal indeed. Such auth modules could even be implemented by a separate (group) of students if needed, as they would not necessarily depend on the JASPIC implementation for Tomcat. As long as that one is not finished they could test it on any existing JASPIC implementation (e.g. the RI, GlassFish). I think we all know that feeling - hence why I suggested it for GSoC. Yeah, I get that, thanks! It's still something that I'd really love to do, but with the work for the startup zeef.com, open source projects OmniFaces and OmniSecurity, the work for the JSF EG and perhaps soon for the security EG, there is not always much time left. I had this on my sketchy todo list for ~end of this month, but I'll see what happens with the GSoC project now ;) Kind regards, Arjan Mark - To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] If you reply to this email, your message will be added to the discussion below: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029643.html To unsubscribe from Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x, click here. NAML -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5029664.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, On Thursday, August 15, 2013, markt [via Tomcat] wrote: On 15/08/2013 00:02, David Blevins wrote: If you wanted to roll up your sleeves, we'd be more than happy to see it ported or reimplemented in TomEE. or Tomcat :) Definitely! I'll also try to contact the guys who said to be working on a Tomcat JASPIC bridge already. One of them had the intention to release his work as open source, although he said he had to target Tomcat 6 specifically. Kind regards, Arjan Tijms -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5003215.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
Hi, markt wrote Had you not cut all the context, it would be clear that Ron's question was: Does the Tomcat community support the inclusion of the Servlet profile of JSR 196 in the EE web Profile? Hence my response. I don't think the Tomcat developers are in a position to pass judgement on what should or should not be in the web profile as we have little to no visibility into what users want from the web profile. I see, thanks for the clarification, it's clear to me now. markt wrote The only folks talking about JSR 196 have been either EG members like Ron or David, or Tomcat committers mentioning that JSR 196 support was being considered or might be a possible implementation solution for something. Not a single user has asked for JSR 196 support. Well, I'm a user asking for it ;) Personally I know of 2 users who were busy trying to implement a kind of bridge between JASPIC and Tomcat so that they could use their company's in-house developed SAM with Tomcat. I don't know why they didn't approach the Tomcat mailing list or created an issue. I address JASPIC on my blog, and from the traffic I can see there's some demand for JASPIC indeed. People do search for things like portable login module, universal realm Java EE, jaspic, jaspic api etc. Granted, it's not a very large amount of traffic (currently sits at ~1% of the JSF traffic, which is a topic I also cover), but it's still there. As opposed to WebSocket; I think WebSocket addresses a need for which there wasn't a real solution yet. It's a new feature that got a lot of attention. JASPIC doesn't really add any new feature, it just standardizes existing things. People are obviously already building authentication modules, but seem to have grudgingly accepted that those things are just container specific. For some reason JASPIC hasn't been given that much attention. From a user's point it was almost silently added to the spec. Even the well known Java EE tutorial from Oracle doesn't mention it. On StackOverflow I mentioned the existence of JASPIC a couple of times in relevant questions, and even very experienced Java programmers (judging by their SO rep) were genuinely surprised that this existed and seemed to be very enthusiastic about the idea of portable authentication modules. A recent example: http://stackoverflow.com/questions/5030924/user-group-implementation-compatible-with-jaas/15873533#comment26696282_15873533 markt wrote No-one said it would be difficult. TomEE has already done it. We'd just need to lift the code. Difficulty really doesn't come into it. If there is a demand for it, it will get implemented. If there isn't, it won't. Thanks, that's clear! Btw, didn't you mean Geronimo there, or really TomEE? Last time I checked TomEE didn't have JASPIC implemented yet, but Geronimo of course has. markt wrote At the moment the main driver for this, in my view, is to provide an API for folks that want to do things like this: https://issues.apache.org/bugzilla/show_bug.cgi?id=54503 Yes, I see. That's a very good example. Thanks a lot for your detailed response. Kind regards, Arjan Tijms -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5003179.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x
markt wrote we are contacting standalone and EE web profile Servlet containers [...] The has been very little demand from the Apache Tomcat user community to support the Java EE web profile. I guess Ron meant Tomcat with the standalone Servlet container and didn't ask for Tomcat to implement the EE web profile ;) markt wrote JASPIC was on the TODO list for Tomcat 7 for a while but it dropped off because a) it wasn't a mandatory requirement for Servlet containers and b) there was very little (no references at all on the users list) for it. Maybe the last point is because of the classic chicken egg problem? People are not writing portable authentication modules, since they know Tomcat doesn't support them. Because of that few of them are being written and thus other people do not ask for it. As Ron already demonstrated a bit, the Servlet Profile of JASPIC should be relatively easy to support. It's not a complete new feature with a lot of code that has to be build into Tomcat (like e.g. supporting CDI would require). Instead, it's doing something that Tomcat already does, but (more or less) layering some standardized interfaces on top of that. In fact Tomcat's JAASRealm (http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#JAASRealm) is not that far away from a JASPIC implementation. markt wrote You'd obviously get a very different reaction if the Servlet spec was going to require JSR 196 support. Just out of curiosity, but what would you think the reaction might be if that was going to happen? Kind regards, Arjan Tijms -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5003167.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat supporting PHP
Joe Nathan wrote: You should realize that PHP world is lot bigger than Java world! I'm not really sure about that. For instance, even PHP web sites 'admit' that Java is a great deal larger: http://www.phpmag.net/magphpde/magphpde_news/psecom,id,27191,nodeid,5.html Typically book stores (at least in Europe) carry more book about Java than about PHP. On top of that, job websites offer more jobs relating to Java than to PHP. A lot depends on your point of view of course. If you're into affiliate marketing, you might think the entire world is PHP. Most of the small affiliate websites are indeed using PHP. On the other hand, if you look at financial systems (banking, travel, etc) you would think the entire world is nothing but Java EE. Having both will have many merits. I think there are some usecases for running PHP on a Java AS. Sun itself is putting lots of efforts in getting various scripting languages to be able to execute on the Java VM. I'm suprized though nobody mentioned Quercus yet. This seems to do exactly what this topic is about: implementing a PHP interpreter and a good deal of PHP's libraries in Java. See: http://www.caucho.com/resin-3.0/quercus/index.xtp Here's a blog about using it on something other than Resin (Glassfish): http://weblogs.java.net/blog/ludo/archive/2007/03/100_java_quercu.html A while back I read a blog about one guy who benchmarked some PHP applications running in this setup (I think he used Tomcat), and found the performance was a great deal better than pure PHP. I can't find this blog anymore, but in the mean time this one may be interesting to read: http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=javalang2=php Grtz -- It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Escaping EL doesn't work in Tomcat 6?
We're using a number of custom tags that accept JSF (deferred) EL
through dynamic attributes. In JSP 2.1 this is illegal. I therefore
tried to deactivate expression evaluation by escaping the #{ pattern,
but it seems that Tomcat 6.0.7 ignores this?
E.g.
x:myTag id=someID someDynamicAttribute=\#{someBean.someProp} /
Where myTag would be declared like this:
tag
description.../description
namemyTag/name
tag-classcom.someClass/tag-class
body-contentempty/body-content
attribute
description.../description
nameid/name
requiredfalse/required
rtexprvaluefalse/rtexprvalue
/attribute
dynamic-attributestrue/dynamic-attributes
/tag
This results in a:
org.apache.jasper.JasperException: Unable to compile class for JSP
where the deepest nested stack trace starts with:
java.lang.NullPointerException
at
org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:2777)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:2988)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2169)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1689)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
at
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1705)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
In a simple outputText escaping is ignored too.
Something like:
h:outputText value=\#{someBean.someProp} /
would render a literal \ before the value of someProp.
Escaping EL is mentioned here:
http://java.sun.com/javaee/5/docs/tutorial/doc/JSPIntro7.html
e.g.
Escape the #{ or ${characters as follows:
|some text \#{ some more\${ text
| and
|my:tag someAttribute=sometext\#{more\${text /
|
--
It's a cult. If you've coded for any length of time, you've run across someone
from this warped brotherhood. Their creed: if you can write complicated code,
you must be good.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
EL in dynamic attribute causes NPE in Tomcat 6
Whenever I try to use any EL (either $ or # syntax) in a taglib tag's dynamic attribute in Tomcat 6.0.7, I get the following exception: java.lang.NullPointerException at org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:2777) at org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:2988) at org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2169) at org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1689) at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386) at org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1705) at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1507) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336) I traced into the source code of Tomcat 6.0.7 with a debugger and found out the exception is caused by the code at the mentioned line 2777 of Generator.java, which is trying to request a TagAttributeInfo from the current attribute, but for a dynamic attribute the JspAttribute.tai field is always null. When I debug the evaluateAttribute method in question, I see that for Node.JspAttribute attr, the dynamic field (attr.dynamic) is correctly set to true and attr.getLocalName() returns the correct name of the dynamic attribute. At line 2771 attr.isELInterpreterInput() returns true, since attr.el != null. When I inspect attr.el, I see the EL expresion is correctly parsed. Only, a few lines below that the code fails with the NPE upon accessing the TagAttributeInfo object tai (which is, as said always null for dynamic attributes). -- It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
