felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Updated: (FELIX-338) Framework FilterImpl is not thread safe on execution
Date Wed, 15 Aug 2007 14:57:30 GMT

     [ https://issues.apache.org/jira/browse/FELIX-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Felix Meschberger updated FELIX-338:

    Attachment: FilterImpl_rewrite.patch

Here is a patch with what I had in mind. It expectes the following changes in the ldap package:

   Parser.getProgram returns Operator[] to not use a cast on each access. I assume the parser
   a "pure" list anyway, so the getProgram might as well create the proper array

   The Unknown class must be public for the FilterImpl.evaluate (copied from Evaluator) to
see it

Finally, the evaluate and toStringInfix method are copied from the Evaluator to FilterImpl.

I just saw after finishing the patch, that in fact the FilterImpl class is the only LDAP related
class not in the ldap package - so the separation of FilterImpl and Evaluator might make sense....
Don't know for sure.

> Framework FilterImpl is not thread safe on execution
> ----------------------------------------------------
>                 Key: FELIX-338
>                 URL: https://issues.apache.org/jira/browse/FELIX-338
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 0.8.0, 1.0.0
>            Reporter: Felix Meschberger
>         Attachments: filter.patch, FilterImpl_rewrite.patch
> Executing a Filter implemented by the Felix Framework FilterImpl class is not thread
safe, as the Filter.Implmatch() methods are not synchronized but use a Mapper and Evaluator
instance fields which are modified while matching the filter.
> Two options seem to exist:
>    1. Make the match() methods synchronized
>    2. Create Mapper and Evaluator instances on each match() call
> My assumption is that the second method tends to be better because of the synchronization
needed with the first approach.
> Reported by Tom Remoleur, thanks. The full mail thread leading to this issue may be found
at [1].
> [1] http://www.mail-archive.com/users@felix.apache.org/msg00145.html

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message