CP2JavaWS : GWT like Cappuccino/Java bridge

Posted: January 5, 2009 in IT/Dev
Tags: , , , , , ,

CP2JavaWS is a bridge between Cappuccino applications and Java services deployed on a webapp. It consists of a client proxy (CP class based on CPInvocation forwarding) and servlet filters,  and provides these features :

– support for encoding/decoding of complex objects graphs (including nested collections with heterogeneous elements), with references/cycles management (using paths and a CPPropertyUtils class that provides exactly the same features as BeanUtils 1.8). Also supports CPCoding protocol if specific CP/JSON mapping is required (usefull when attributes names for remote Java classes are different from CP ones).

– support for arguments types check, nil arguments, generic arguments types (CPObject/Object) by specifying a service protocol (CP class) when retreiving a proxy.

– automatic switch to JSONP mode when calling a remote service on another endpoint (except when working locally with Safari – not required).

– full digest authentication management (native browser authentication dialog or custom CP view – a default implementation is provided). The original request is sent automatically after authentication success. The server-side authentication filter allows many settings.

– habilitation filter (for finer service’s methods access control once user is authenticated).

– full jsession id tracking (sent along subsequent requests to a endpoint we authenticated to), that also allows composite applications (made from parts using remote services from different endpoints). That is close to the principle of Apple’s OpenDoc and recent Google’s wavelets.

– provided CPTableView delegate (datasource) that allows automatic browsing of large remote service’s collection result, without page break and without pause (thanks to an asynchronous read-ahead mechanism). It manages sorting (headers however not displayed yet – waiting for the new CPTableView implementation) and custom selection criterias, through a generic DAO component on the server-side (based on Hibernate).

– Direct2CP feature : it provides automatic generation of master (table) and detail views, and edit/insert/delete management, by just setting the elements CP class (that mode uses internally the previous CPTableView delegate and generic Java remote DAO service). A custom detail view can be used instead the generic/generated one (has then to implement some delegate methods to benefit from the provided detail view controller and remote DAO service). A custom service can also be used instead of the generic DAO service (if using a non relational datastore or connector).

Demo : the distribution includes a working example that features custom objects and nested collections arguments with cycle, default CP authentication dialog, demo authentication and habilitation services, and Direct2CP mode. It is also available online at Google AppEngine :

CP2JavaWS online demo

This framework is provided under the GNU LGPL license.


On the client-side :

var endPoint = [CP2JavaWSEndPoint
var remoteService = [endPoint
IDemoService1" delegate:self];
[remoteService method1:"arg1StringValue"
andArg2:2 andArg3:myCustomObject delegateRespHandler:@selector(successHandler1:) delegateFailHandler:@selector(failHandler1:)];

There isn’t any limitation in types and count of passed arguments. By default the first selector part when calling remote service’s method is the method’s name (Java name), and following selector parts can be named as we want (don’t have any equivalent on the Java server side method’s signature). We can however use setUsesFullSelectorName method on the proxy service to use the full selector parts as the remote service’s method name (default mode when specifying a protocol – see below).
Supported collections for call arguments and return objects graphs are CPArray (List) and CPDictionary (Map), and they can be nested at any depth. Moreover heterogeneous collection elements are allowed (can also be custom objects or other collections…).

We can pass a protocol (CP class with methods signatures) when retreiving the proxy, in order to allow arguments check, nil arguments values, and generic arguments types (CPObject/Object) :

var remoteService = [endPoint1 proxyForJavaServiceInterface:@"com.cp2javaws.demo.services.IDemoService1" objjProtocol:"Service1Protocol" delegate:self];

Service protocol example :
@implementation Service1Protocol : CPObject {}
-(CPArray) readForAa:(MyCustomClass)aCustom Bb:(CPArray)aArray Cc:(CPDictionary)aDictionary Dd:(CPInteger)aInt Ee:(CPString)aStr Ff:(BOOL)aBool Gg:(CPDecimal)aDEC Hh:(CPDate)aDate Ii:(CPObject)aGeneric {}


On the server-side :

Just add the cp2javaws-filter.jar and the service factory support jar (for example cp2javaws-springsupport.jar) in the application’s WEB-INF/lib (along with json-lib-2.2.3-jdk13.jar, Jakarta commons-lang 2.4, commons-beanutils 1.8.0, commons-collections 3.2, commons-logging 1.1.1, ezmorph 1.0.6, and base spring.jar – 2.8 Mo – if Spring factory). The cp2javaws-filter.jar and cp2javaws-springsupport.jar have been compiled using JDK 1.5 (recompile with provided source if needed).

For custom service factory/framework, a listener example is provided (see server source code, DummyContextWrapperListener.java and DummyContextWrapper.java). Just modify these classes to get you service factory injected, and then export these two classes into a support.jar (the same as with cp2javaws-springsupport.jar).

Add the following config to the web.xml (this example uses Spring factory) :


Add the factory config file in the web application (for example applicationContext.xml in WEB-INF if Spring, with configured services beans).

A mapping file (see provided example) has to be put on the server-side for custom Objective-J objects to Java custom objects class names mapping.

Digest authentication filter configuration

See included example webapp web.xml.

Authorization filter configuration

See included example webapp web.xml.

Why using JSON / namespace consideration / CP2JavaWS comparison with GWT / Spring 3 REST servlet

JSON is intended to be used as a simple serialization format for REST exchanges, so it doesn’t manage namespace problematics. We can read a useful article about its limitations and read a thread that explores possible extensions for JSON to be namespace aware :

A more robust solution would have been to use a format such as XStream one (that I have used extensively on other projects from Java dynamic proxies), but it would have required an Objective-J implementation of that framework. Like Ojbective-C, Objective-J still provides its own object serialiazation format through coders (objects data are available as CPData). However on the other side (Java server) an implementation would have also been required.

GWT doesn’t face this problem as the client code (generated into javascript) is written in Java, so the generation tool can use the same serialization Java APIs (furthermore each service parameter object is defined only once. With CP2JavaWS it has to be defined both in Java and in Objective-J). However the powerful (and fully tested since NeXT era) AppKit/FoundationKit frameworks and Interface Builder/Atlas tools available in Cappuccino overcome that little overhead.
Moreover Cappuccino allows mixing Objective-J code and javascript code (in a completely transparent manner, as Objective-C with C/C++ code), that allows to reuse existing js libraries and easily include accessibility features (are being introduced in modern browsers).
GWT uses a generation step to allow client-side javascript<–>JSON serializers/deserializers generation, as they have to be static (are javascript code). Objective-J runtime dynamic feature doesn’t require any manual generation step, as the end javascript is produced at execution time.

The Spring project also plans to provide such of REST bridge servlet for Spring 3 version, and the namespace problematics are widely discussed. We can find an example of JSON to Spring beans request parameters mapping servlet here : http://weblogs.java.net/blog/rexyoung/archive/2008/11/how_to_bind_fro.html.

Why not a Java to Objective-J generation tool for Cappuccino, like with GWT ?

Such tool allows far more easier development of the solution, it can lead to more optimized code (faster because of static code produced, no dynamic feature) and it allows writing code in Java (and business objects used as services’s parameters and return are declared only one time). However it breaks the development cycle and isn’t elegant.

After all, what would we say if object-relationnal mapping frameworks required to use a tool to generate some DAO from the mapping files ? Instead they use reflection APIs to dynamically generate objects from mapping description files. I know some implementations (based on the JDO specification) are based on a bytecode enhancement step (to compare with GWT generation step), that allows datastore type abstraction (database, but also filesystem, CICS, etc.) and better performance. But the result is that most people stayed with standard reflection based solutions (notably Hibernate, a defacto standard – not even based initially on any specification…)

Google had no other way to make GWT work than to use a generation step, because their end client code is pure javascript (so no way to implement such remote service proxy). Thanks to Cappuccino Objective-C runtime (converts Objective-J code into javascript at runtime using a JIT pre-interpreter), the proxy could be implemented without requiring a generation step.

  1. […] : see also the CP2JavaWS Cappuccino client to Java remote services bridge, that allows easy call of remote business services, […]

  2. A new version – 0.2-beta – is available :

    – remote services methods calls using JSONP (sameDomain setted to
    false) now work properly (the data passed to the javascript callback
    function is a javascript object contrary to sameDomain
    XMLHTTPRequest.response-text, as for cross-domain the application/
    javascript content-type is managed by the browser – execution occurs
    inside a element). The
    CP2JavaWSJSONDecoder decodes the javascript object return into the
    expected Objective-J class.

    – the java remote service result can now be a collection, either a
    List (converted into a CPArray) or a Map (converted into a
    CPDictionnary). Collection cannot be used as services methods’s
    arguments however for now (rare case hopefully).

    – Custom Java (and CP equivalent on the client-side) classes can also
    be used as remote services methods’s results, or as calls’s arguments.
    However their attributes must be simple for now : string, integer,
    double. Date type isn’t managed for now as it is considered as a
    “object” javascript type, and the CP2JavaWSJSONDecoder iterates
    through javascript objects keys -(we lacks ivar.type for now,
    undefined). In the next version the namespace will be added for each
    attribute in the returned JSON string, and we will iterate from the
    class definition ivars instead of javascript keys (the provided
    namespace for each JSON string node will circumvent the lack of

    – services results of collection type can also use custom objects as
    their elements class, besides simple types. All elements are supposed
    to be of the same class.

    – collections used for services results must be at the root level for
    now. For example a List (or Map) of Strings objects (or custom class)
    is allowed, but if using a custom class as the result, it cannot
    contains a collection as an attribute (you will have to use an
    additional call to another service to retrieve that nested

    – added examples are included for new use cases in the provided client-
    side demo AppController and service-side demo service implementation.

    – next 0.3 version will allow full objects graphs to be passed as
    methods arguments and/or return, without any limitation on their type
    and depth (it will also allow nested collections).

  3. Version 0.3 details :
    – major refactoring and code cleaning, completely rewritten encoding and decoding on the client-side and server-side.
    – that version now uses Objective-J categories to encode/decode full objects graphs, and allows to customize encoding/decoding (if needed) for custom objects
    – encoding and decoding now manages any depth, including nested collections
    – collections (CPArray/List and CPDictionary/Map) elements can be heterogeneous
    – method’s arguments (JSON encoded parameters) and return now provide the objjClassName for each node (including collections’s elements),
    so the client-side is independant from server-side technology (language).
    Besides the CP2JavaJSONServlet, a PHP implementation could then be added for example, keeping the same client-side CP proxy classes.
    – the custom Objective-J classes to Java custom classes mapping has now to be done using a properties file on the server-side.

  4. Version 0.31 details :
    – CP2JavaWSJSONServlet has been replaced by a filter. Then no need anymore for a servlet.
    If a servlet is still present, your application could then manage both JSON requests
    (originated from Cappuccino client applications using CP2JavaWSRemoteService proxy), through the CPJSONFilter,
    and classic web requests (managed by your servlet, Struts or Spring MVC servlet for example).

    – the CPJSONFilter can work with any service factory (custom framework and/or IOC container).
    A listener is provided for integration with spring container (see the provided demo).
    You have then to add cp2javaws-springsupport.jar in web-inf/lib besides cp2javaws-filter.jar (and spring.jar obviously).
    If not using Spring, spring.jar (and cp2javaws-springsupport.jar) can be removed, avoiding any dependency.

    – for custom service factory/framework, a listener example is provided (see server source code, DummyContextWrapperListener.java and DummyContextWrapper.java).
    Just modify these classes to get you service factory injected, and then export these two classes into a support.jar (the same as with cp2javaws-springsupport.jar).

    – fixed date timezone management.

  5. New features in version 0.32 :

    Encoding and decoding of client objects now also supports CPCoding, through new CP2JSEncoder/CP2JSDecoder.
    These coder provide transparent backward compatibility with previous versions of CP2JavaWS that were based on the CPJSONAware protocol :

    – if no CPCoding implementation is found on custom objects, it uses instead the old toJSObject/objectWithJSObject methods from CPJSONAware categories.

    – Furthermore it does the switch at each node level ! That is for custom objects we can etiher implement CPCoding protocol’s methods (if the serialization requires particular work, for example to exclude some attributes or choose arbitrary JSON keys – different from ivar names), or benefit from the automatic encoding of objects provided by the CPJSONAware categories (then custom objects have to import CPObject_CPJSONAware.j, and JSON keys will match exactly ivar names).

  6. – 0.4 version : support for cycles/references (use of a path in JSON strings, $ref:). Paths support full EL/BeanUtils syntax (see provided CPPropertyUtils class).

    CPJSONAware categories aren’t required anymore. Automatic decoding/encoding of ivars is used when custom objects do not implement CPCoding. Implementing CPCoding allows to set different JSON keys than ivars name (can then match Java’s objects attributes names if they differ from CP objects’s ones).

  7. – 0.5 version : full digest authentication support (with many parameters on the server-side authentication filter), and automatic retrigger of original request once authenticated. Tested on Firefox and Safari (uses native browser authentication dialog and authorization request triggering).

    Session tracking management (jsessionid cookie stored in the client endpoint and sent along subsequent requests – once authenticated).

    Habilitation filter for services access (once user is authenticated).

  8. – 0.6 version :
    – added a mode for custom (Cappuccino based) digest authentication dialog (previous version client-side digest authentication and dialog were managed by the browser only). The mode is setted on the server-side authentication filter configuration ( parameter in the web.xml – set it to false for custom dialog).

    – a default Cappuccino authentication dialog is provided (CP2JavaWS client code also manages transparently digest authorization request creation, cnonce and and nonce counter, and sending of original request when authentication successes).
    That dialog also shows the endpoint url’s (we could use a composite app that makes calls to various enpoints/different webapps on the same domain – same protocol, host and port -, and then have multiple authentication challenges).

    – a custom CPWindowsController can be set when creating an endpoint to use another window. It has to implement the initWithTarget:(id) okAction:(SEL) cancelAction:(SEL) method (see the provided CP2JavaWSLoginWindowController).

    – passing sameDomain information isn’t required anymore when creating an endpoint. CP2JavaWS compares the passed endpoint url with the index.html document.location (protocol, host and port) to determine the proper mode. However the sameDomain parameter can still be passed if needed (required if the index.html is local – for dev configuration).

  9. – 0.7 version :
    – New component, CP2JavaWSTableViewDelegate, that manages retrieving of rows objects values automatically : triggers requests to the server through CP2JavaWS bridge classes when needed. It allows fast browsing of large table selection results without stressing the application server nor database server, and without requiring any pagination ! No GWT component, JSF or other provides that feature yet : they all use pagination (data splitted into multiple pages), that is less practical, less intuitive and slower to reach the desired element (if you have hundreds of elements you can’t have all pages number displayed, so you have to use many times forward/fast forward buttons).

    Requests are sent ahead asynchronously when we reach near cache’s end, so the application user interface remains responsive.

    The requested rows count (next or previous cache size) adapts automatically to the current visible rows (that depends from the enclosing scrollview size – could be resized then).

    Use of fast scroll using the scrollbar or scroll area is allowed (generates a cache fault and then a synchronous – that time only – call to reset all caches from the next requested position).

    Ready for column sorting (infos are passed to the remote service’s read method) once the datasource delegate method is managed in CPTableView.

    Can pass selection criteria (SQL, HQL, or any other WHERE clause part string) to the remote service’s read method if selection must be restricted (pass null to browse the whole table).

    Use (see included example) :
    – create the CPTableView and columns as usual but pass the corresponding attribute of the remote collection’s elements class as the column id (you can pass any nested property using EL type path, as CPPropertyUtils is used here).
    – create the table datasource (and set it as the tableView datasource) passing the endPoint, remote Java service interface name, read method and get size (whole table size) method names, index/primary key attribute name, additional criterias string :

    tableViewDelegate = [CP2JavaWSTableViewDelegate createForEndPoint:endPoint1 javaServiceInterface:@”com.cp2javaws.demo.services.IDemoService2″ readMethod:@”readCustomersForIndexCriteriaAndCountIsForward” sizeMethod:@”customersCount” idAttName:@”customerId” criterias:nil];

    The read method on the server must follow this signature :
    (Integer indexCriteriaValue, Integer count, Boolean isForward, String criterias, List sortDescriptors).

    Fixes :
    – fixed a problem with CP2JavaWSURLConnection’s instance authDelegate scope, that lead to the application not working if using index.html (uses Press and then all global vars appear in the same file – same scope) instead of index-debug.html.
    – fixed a problem when encoding/decoding null attributes values (if using custom CPCoding implementation and not checking for null attributes – ok when relying on automatic mode). These fields are now ignored (not included in JSON string).
    – now follows correct rules when checking for sameDomain setting at endPoint creation (allows use of a local file for the client CP application if the server is local and Safari is used).

    – Added preliminary support for synchronous calls (do not manage digest authentication yet). Then asynchronous mode remains the default (should also be preferred as it allows more responsive user interface).

  10. – 0.71 version :
    Note : now uses json2lib stringify and parse methods from latest Cappuccino main branch (and future 0.71 version). Then it does not work for version 0.7 (or you should replace these methods manually by these from CPValue).
    These two new methods should lead to general better performance.

    – fixed a cache problem : now if an asynchronous request was pending before a cache fault, its return is ignored (as the state isn’t the same as originally expected after a cache fault).

    – the sorting code now works properly (as soon as headers and CPSortDescriptors are added to CPTableView). It can still be tested by modifying the init value for currentSortDescriptorsStr in CP2JavaWSTableViewDelegate (see commented code). The reference is now the position in the table, and limit(first, length) requests are used.

    – added a new generic service, GenericMasterDetailDAOService, that manages retrieving of elements for any CP class, using Hibernate. It then avoids having to define a DAO service (the previous mode is still available, for custom management or non-database datastores).
    To use the new mode, pass the table elements CP class name when creating the CP2JavaWSTableViewDelegate, instead size and read method names (that are then generic).

  11. – 0.72 version :
    – Modified server-side demo HabilitationServiceImpl to return true for the 
genericDAOService methods.

    – CP2JavaWSEndpoint init had a bug with testing presence of sameDomain 
argument : replaced if(aSameDomain) with if (aSameDomain!=nil).

    – CP2JavaWSTableViewDelegate : in sendSynchRequest, added the test for 
sameDomain (was ok for sendAsynchRequest) to use JSONP mode if not same 

    – Modified hibernate config .hbm file to use assigned generator for the id, as AppEngine does not provides the InetAddress class.
    However Hibernate’s SessionFactoryImpl still owns a static field of type UUIDHexGenerator that is always initialized, and that extends AbstractUUIDGenerator, whose uses InetAddress in its static init part.
    Then had to redefine AbstractUUIDGenerator (included in same original package name in the demo project’s src folder) : when deploying to AppEngine we have to comment the line that uses InetAddress and uncomment the line that uses a random generated address (based on JUG project, also licenced under LGPL).

    A working demo is now available on AppEngine (same code as the included webapp example except the endpoint’s url and use of the random generated address in the redefined AbstractUUIDGenerator class) :


    (tested on Safari 4, Firefox 3.0.x and IE. Is ways faster on Safari, however performance should be improved with upcoming Firefox 3.5 release).

  12. – 0.8 version :
    – refactored the request management (mode switch, CPURLConnection/CPJSONP creation, delegate and auth. delegate creation, encoding and decoding) in a new class, CP2JavaWSHttpSender, as it is used by both CPRemoteService and CP2JavaWSTableViewDelegate.
    – the CP2JavaWSHttpSender allows to specify if call arguments have to be encoded (CP to js conversion before js to JSON), and if result has to be decoded (js to CP after JSON to js).
    – For remote service methods that have generic argument types (Object), we can now pass to the CP2JavaWSHttpSender an array of generic parameters indexes (required as on the Java server side we then cannot discover the generic Object type from the passed parameter value).
    – reponses with error code didn’t trigger anymore the failHandler since CPURConnection doesn’t check anymore for error codes (in order to allow to perform action depending on the error code).
    – fixed a problem in Decoder, where empty Date on JS object was setted as undefined on the CP object instead of null,
    and where JS boolean fields with false value where treated as unset.

    – CP2JavaWSTableViewDelegate can now be used in two modes : in the first mode the full CP objects are returned for each requested row (slower but we then still have the full object if we select it for editing in the detail view – then no need for additional read request).
    In the second mode the return (for a row) is a tab of values (each value is the final attribute corresponding to the specified attribute path – setted as the column’s id), that is faster (attributes paths are passed to the select HQL request – faster than a select *, and no decoding occurs on the client side – result encoding to JSON on the server side is also faster) but requires an additional read for editing. In both cases the displayed values correspond to the columns’ ids, and can be nested attributes paths.

    – a new object, CP2JavaWSMasterDetailView allows to display and manage automatically a Master/Detail view for a specified CP business class (sort of a Direct2CP, that uses CP2JavaWSTableViewDelegate). We can specify specific attributes paths to display in the master view (tableView), as we may want to display only a few of those (and the whole attributes values in the detail view). If not precised, the master view will display a column for each attribute (the elements CP class ivars are introspected recursively – so we get a column for each nested CP object’s attributes).
    Depending on the attribute type (string/integer, boolean, date) the detail view adds a CPTextField, CPCheckBox, etc. To use combo lists for some attributes values editing, a later update will allow to specify RemoteValuesListDescriptors, that will store the endpoint (if different) and remote services (if many) that return the corresponding combo lists values.
    By clicking on a row in the master view (tableView), the detail view fields are automatically filled. The detail view contains a Modify button, that automatically calls the generic RemoteDAOService to update the object.
    We can pass a custom detail view if needed (that will have to implement some delegate methods to fill the editing fields, and use the provided DetailViewDelegate for changes submission).

    Note : the Objective-J/preprocess.js (or Frameworks/Objective-J/Objective-J.js) has to be modified using the provided file changes in order to manage ivar types (required for the new MasterDetail view).

  13. Jose says:

    What is the format of the download file (.7z??). Is there an installation guide?

  14. This is sevenZip common format (free and efficient), available on both Windows and OSX (download 7zX utility). Instruction files are provided in the archive.

  15. DimiT says:

    We are trying to use CP2JavaWS 0.9 in a high profile project but we are really stuck, is there any more documentation available apart from this article: http://sourceforge.net/docman/display_doc.php?docid=137096&group_id=249667 ??

    There is no Spring or Hibernate in our configuration, the application design is as follows:
    – The persistence layer is EJB3 entity beans
    – The service layer is EJB3 session beans
    – Clients send JSON requests, which are handled by servlets
    – Clients are Cappuccino on web browsers

    Q1: Can we use CP2JavaWS in this scenario, and if so, which features would be available?

    Q2: Which classes exactly would be required (or not required) from the CP2JavaWS src distribution? What other classes would we have to provide?

    Q3: What configuration would be required in order to support EJB3/JPA, without Spring / Hibernate?

    Q4: Is there any step by step documentation that we can follow, in order to understand how to make this work? The documentation that we have found so far has proven really poor, and assumes a good level of understanding of the CP2JavaWS framework. We have none. Any help would be greatly appreciated.

    Many thanks!

    • Hi,

      A1 :
      CP2JavaWS offers many features (Java services bridge through a JSON filter, an authentication filter, an habilitation filter, master and detail view generation with handling of data persistance through Hibernate for now). However you don’t have to use all of these.

      You don’t have to bother with JSON nor servlets, CP2JavaWS takes care of all (through its JSON filter). You work on object level both on client side (ObjJ) and server-side (Java), and just have to provide a file for mapping ObjJ classesnames to jave ones (only names, for custom attributes mapping you have to rely on CPCoding protocol).
      You access directly to your Java application/business services (hosted by string container or your custom container, see below).

      A2 :
      As explained in the documentation you pointed, you can use another container than Spring. There is a provided example (dummy context wrapper).
      The documentation lists all the required jars, and there is also a readme.txt file in the distribution that lists all these jars (is more up to date).
      The “framework” part of the distribution provides both compiled classes (jars) for spring integration (cp2javaws-springsupport.jar) and core cp2javaWS (cp2javaws-filter.jar), and source code in case of. You don’t need anything else except the listed external libraries (the other code, applicative, will be yours).

      The “demo” part of the distribution provides a full working app, that is the application code you will normally write. It is provided as source only (as I’m not allowed to distribute a war that contains all the required libraries dependencies).

      A3 :
      If you are just using ObjJ to Java services bridge, that is up to your Java services implementation to use/choose you persistance framework (and coding use of it).
      If your are using the provided CP2JavaWSTableViewDelegate or Direct2CP mode (master/detail view generation), then you can either rely on the generic DAO service (based on Hibernate for now – I would have to provide another one for EJB3/JPA), or you can specify you own CRUD DAO service (then you will implement it using what you want, EJB3/JPA, etc).
      This is stated in the online documentation, and a custom CRUD service (service2) is provided in the demo.

      A4 :
      Besides the provided documentation you can find a full working demo application (its source code) in the distribution.
      For now, the only details that aren’t in the online documentation are authentication and habilitation filters config, but I mentioned you can refer to the demo’s web.xml. I plan to add these also in the online documentation.

      Hope this helps, and I’m really looking forward to your project ! You can count on my support.

      Note : I will release soon an update, as there is a problem in “sessionUserKey” information (for now passed from the authentication filter’s init to the habilitation filter’s init). As the order of filters’s init won’t always be the same in a servlet container, I will have to modify the code and pass the info also in the habilitation filter’s config and get it in the same way). The error didn’t show in my server Tomcat configuration but happened in another older version (it leads to a nullpointer in some old Tomact 5.5.x versions due to a Tomcat bug).

  16. RADUREAU Matthieu says:

    Thx a lot Jérôme for your framework!

    Very good work!

  17. Thanks a lot Matthieu (I missed the comment :-)) !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s