Re: [Ejbca-develop] Latest changeset related to xdoclet

[Stephane B. <ste...@be...>]

I fixed the problem that was in LocalUserAdminSessionBean.

It was due to a bug in the implementation that surfaced because of the 
xdoclet generated primary keys that redefines a clean toString method.
The original code was strangely doing this:

UserData pk = new UserDataPK(username)
UserDataLocal data1 = home.create(pk.toString(), newpassword, dn, caid);

instead of this:

UserDataLocal data1 = home.create(username, newpassword, dn, caid);

This is now fixed in CVS, I also fixed a bug in the key recovery dd and 
the AdminEntity is fixed as described below, even though I absolutely 
hate it the way it's done.

Unit tests seems to run ok except 
se.anatom.ejbca.ca.store.TestCertificateData that has 3 failures related 
to wrong reason code.
I'm looking into it.

Stephane Bailliez wrote:

>
> There is currently a problem with the authorization EJBs, do not sync 
> this module to head, get the previous revision.
> (the easiest way is to update with a date before july 22)
>
> The problem I have is related to the AdminEntity ctor with the special 
> user code. matchValue and caid are not initialized (matchValue being 
> null is the main problem for the db)
> I can either change the constraint to allow null but the problem is 
> also in the object itself as this special case is obviously a small hack.
> For my own test, I changed it to while I'm investigating other 
> problems (with the changes below it looks like it cannot find the end 
> entity profile when setting the clear text password):
>
> public AdminEntity(int specialadmin) {
>        this(WITH_SERIALNUMBER, specialadmin, "NOT USED", 0);
> }
>
> I hope it would be solved on monday otherwise I will rollback the 
> changes while I will be working on it.
>
> Sorry again for the inconvenience.
>
> Stephane
>
> Stephane Bailliez wrote:
>
>>
>> I committed a large number of changes related to xdoclet in cvs. We 
>> should be close to switch to it.
>>
>> But I would not be surprised it it breaks something. I'm right now in 
>> the process of running tests to see if I broke everything. (which 
>> should not be surprising)
>> Summary of change is:
>>
>> - xdoclet is now in lib/xdoclet-1.2.1 it will be picked up by your 
>> build file.
>>
>> - The build file is generating interfaces and homes INSIDE the source 
>> tree, this is still temporary but I used this scheme to easily diff 
>> generated files vs previous manual one. In all cases (I hope), 
>> Xdoclet generated java files are under CVS
>>
>> - DDs are generated but are not yet picked up for deployement as it 
>> may requires more xdoclet tweaking in particular for transaction so 
>> old DDs are still used for now.
>>
>> - HardTokenEntityBean has been changed (see the changedlog) to be EJB 
>> compliant. It means basically that you won't be able to get your old 
>> data as the model has changed !
>> There is no migration script for now. But I will try to work on it. 
>> (The hardtoken DD has of course been changed too)
>>
>> - I plugged the JBoss EJB verifier in the build sequence so that each 
>> ejb jar is checked for compliance. I will see later if I can plug the 
>> Sun verifier.
>>
>> Sorry for any inconvenience.
>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
>