reeshu patel about LDAP password policies and JavaEE
Tue, 08.04.2014 12:54
i am using opends. i want to get warnig msg. but i am not getting.all policy is working . pass [...]
ricky about OpenDNIe integrated into OpenSC
Sun, 23.03.2014 17:27
Hi David, I have written a quick entry about installing opensc/opendnie in chrome/chromium: [...]
David about OpenDNIe integrated into OpenSC
Sun, 23.03.2014 11:12
Hi Ricky, nice post, very helpful. I was also wondering if you know how to configure Chr [...]
Aitor about OpenDNIe integrated into OpenSC
Fri, 14.03.2014 08:54
Hi Ricky, I'd like just to add some advice, in my case executing bootstrap script I get thi [...]
ricky about Weaving Problem in EclipseLink
Fri, 14.02.2014 22:59
I've just seen that Pablo (a developer of the customer) has commented the solution in the Ming [...]
Noman about The WebRTC Demo in Glassfish 4
Sun, 09.02.2014 10:19
Hi, This is really awesome example. I was looking something like that to use WeBRTC in java b [...]
ricky about OpenDNIe integrated into OpenSC
Tue, 10.12.2013 17:23
Good job Pere! Let's see if it's accepted.
Pere about OpenDNIe integrated into OpenSC
Mon, 09.12.2013 18:33
Based on a big commit that included OpenDNIe changes into OpenSC I am created a patch for de [...]
Sunday, November 10. 2013
Yesterday the version 0.3 of the couchbase-manager was released. As you know it is a little project to manage glassfish sessions inside a couchbase cluster on which I usually spend some time. This version is the first one I feel more or less confortable with it, I think it is starting to be in a mature state. There are mainly two new features in this version: glassfish 4.0 support and, finally, non-sticky configuration is reliable.
As soon as the 0.2 version of my couchbase manager was released the glassfish Oracle group announced the new and bright version 4.0 which, as all of us know, is the reference implementation for JavaEE 7. The couchbase-manager 0.3 works also with glassfish 4.0. I have to admit that the integration was easier than I expected, only some little changes were necessary:
The second big change is that couchbase server version 2.2.0 fixes the problem about deleting a locked object. That issue forced me to first unlock and then delete the session in previous versions of the manager, and, in a heavy concurrency situation, the two operation technique reported errors. If you check the following bug I opened the issue some time ago and, because couchbase guys did not say anything, I decided to try to fix it by myself. After some hours compiling, checking code, detecting the affected part and fixing it, I realized that the same piece of code had been already patched two months ago. It was a complete waste of time because it was already fixed. I suppose that someone else detected the problem knowing nothing about my bug. I usually work with the community version of couchbase which is one version behind the commercial one. That habit made me fall into that messy situation.
But the result is that finally the manager can delete a session which is locked (passing the cas value). I have tested for a long time the non-sticky configuration and now no concurrency problems are detected. It can be said that now non-sticky solution is reliable.
Nevertheless the new couchbase version has also fixed the touch method. Now when a session is locked touch method results into an error (previously a locked object can be touched without problem). Because there are no unlockAndTouch or similar method in the API I decided to always save the session (cas in non-sticky, set in sticky). It is not a problem cos, after I realized that an attribute can be modified without being put again in the session, the cases when a session was not dirty, and can be touched instead of saved, were really a very little percentage. As a result the previous manager property maxTimeNotSaving has been removed (that property controlled when to save a session which has been only touched for a long time).
Finally I am going to show some times (in ms) of the manager for both configurations. As in the previous entries the configuration is two glassfish v3 in a KVM cluster against a single couchbase installed in my physical laptop. The manager is tested with different session sizes (50, 200, 2000 and 4000 bytes). More or less the numbers are stable and similar to the previous versions except the delete operation, which is slightly slower.
So the summary is that the new version 0.3 of the couchbase-manager is the first one without known problems (I am lying, there is still the LDAP realm problem because of a glassfish bug, but it is a very specific problem). I have more ideas to improve the solution (mainly dealing with attributes as separate objects in order to not save the whole session all the time) but I do not really know when I have the time and the mood to start with such a big change. Just one more comment, in my tests (performance tests mainly) I see that the couchbase server is highly intensive in disk writing (my laptop disk, which is also encrypted, was at 95-100% of utilization rate during tests). As I said several times, in my specific solution persistence to disk is not completely necessary, I think that replicas are enough security for a cache system. But couchbase buckets cannot disable disk persistence (see this forum entry or this another one). I hope that someday this feature was configurable exactly as the replica behavior.
Enjoy version 0.3!
Friday, June 14. 2013
Going back with my couchbase-manager this week the new version 0.2 has been released. That was long ago when the first version of the manager was made public but I have been waited how several issues evolved. I have to admit that there has not been a lot of movement but I think it is a good time for the second version.
Let's start with the new features in the version:
In the period between the versions there was an attempt to use a different serializer technique. The manager now uses common Java Serializer and it is known that other implementations like Kryo give more performance. Some little tests in order to add Kryo were done but I finally gave up because a lot of internal classes of glassfish require special treatment (objects from cdi/weld, EJBs and so on). Objects of those types need to use the Java Serializer again and I simply thought that the change was not worthy.
The bug about the LDAP realm (the couchbase-manager cannot recover a principal which is stored inside an LDAP realm) was at least updated. Another guy experienced the same problem (but in a completely another way) and the bug was marked to be fixed in version 4.0.1. So I know this is a bug and I will not change the way the manager recovers the principal user from the store when logged.
And finally an annoying behavior still persists when using the non-sticky configuration in the manager. As I have commented several times the deletion of the session cannot be done if the session object had been previously locked (it returns an error). For that reason the only way to delete a session is performing an unlock first and then sending the deletion. Obviously if the session is unlocked weird things could happen and, in my tests, they really happen. I will try to insist on this to the couchbase guys, it should be a way to delete a locked object.
So now you already know, the version 0.2 of the couchbase-manager is out. I encourage all of you to test this new version and comment me or fill a bug in github. I need your comments to check if the manager is minimally usable.
EDIT: I have just discovered that the new glassfish maven repo can be found here. Nice! It is a pity the version 2.0 is just released.
Saturday, September 29. 2012
After the announce for the couchbase-manager-0.1 this post is going to show how it deals with some JavaEE sample applications. Before the releasing I made it work with some of them in order to make the manager compatible with part of the typical JavaEE elements (EJB, CDI, JSF Managed Beans, JavaEE security and so on). As it is said in the release notes for 0.1 version the manager is still not fully tested but, at least, some applications work.
JSF Beans, CDI and EJBs.
JSF and EJB are two important technologies in the JavaEE world and I recovered the old CertSecurityCustom project for the occasion. If you remember that project lets us login using a certificate or a typical username/password form and checks the user against an LDAP repository. The project mainly consists in a EJB and a session JSF bean. After making all the objects to implement the Serializable interface and fixing some issues with the manager (mainly the memcached transcoder must use a special glassfish Input/Output object stream) it worked like a champ.
Here I realized another thing, an application can get and attribute from the session, change it and not set it back (it is supposed that it is the same object and no set is necessary). So in 0.1 version the manager marks as dirty any session when any attribute is got (that means mainly all sessions are always set or cas, for the moment touch is only used when the attribute retrieved is a simple object -Integer, String and some other classes that cannot be changed internally-).
Besides I inject the JSF bean using CDI (@Named) and typical bean (@ManagedBean), and same with the ldap ejb (@EJB and @Inject). The four combinations worked after the commented changes.
JavaEE security is another hard issue I wanted to be functional in the first realease. The application that I chose was the CertSecurityJavaEE project (the second example in the certificate login series which uses again an LDAP server but doing standard JavaEE security).
More problems here were found. Glassfish declares the principal property of the session as transient (keyword that means the property has to not be serialized and therefore saved). Looking at the replicated glassfish implementation, I saw that only the username property is kept replicated. If the session is used in another server (in which the user did not logged in), the replicated implementation logs the used silently using a special method in the realm (createFailOveredPrincipal). I did the same trick. Now the manager session has a username property that is saved in couchbase with the other data, when the session is filled that property is checked and if it is different from the principal in the session (null mainly) the principal is recovered from the realm calling the same method.
That was very nice but it didn't work with the LDAP realm. I opened a bug with the issue but silence is the only answer til the moment (some collaboration please!). Changing the realm from ldap implementation to file (users and groups are stored in a plain file) my solution works as expected. The user logins to one application server and if it changes (non-sticky load balancing or a failure in sticky configuration) the user is logged in the background. Take in mind that this happens the first time the user access a new server (the manager sees the principal is null but the username is filled and it uses the realm to reassemble the principals of the logged user).
With all those changes my little application started working using the couchbase manager.
Java Pet Store 2.0EA
Finally I tested the typical Pet Store application. This application was for along time a kind of a reference application for JavaEE, now it is abandoned and its last version 2.0EA is only JavaEE4 compliant (not 5). Nevertheless I think it is a good test cos it mixes several technologies of the JavaEE specification.
With the pet store application I faced with a glassfish issue when using mod_jk and mod_deflate in the apache. But after fixing that issue the manager started to work smoothly. All the session beans were transformed into serializable objects (in version 0.1 the manager uses standard java serialization to convert the session into a byte array, that means all the objects that are going to be saved inside the session should implement the Serializable interface).
And here it is the video. First the custom ldap login application is shown (the application refused to change me from one server to the other but finally it did), you can see how the couchbase console shows one session and, as soon as I log out, the session disappeared. Then the standard JavaEE security application is accessed. Both servers maintain my logged session using the file realm. Finally I enter Pet Store application and click over some of the pages which work smoothly.
Well, the couchbase-manager-0.1 is working with some (more or less) complicated JavaEE applications. I am conscious that there are more tests to do, and that is the reason to release the first version, let more people testing it. If anyone of you is interested in the manager please install it and test it with your applications (use github or this blog to report issues). Of course I guarantee nothing about the fix.
(Page 1 of 3, totaling 8 entries) » next page