Am Samstag, den 03.08.2013, 13:08 +0100 schrieb sebb: > On 3 August 2013 12:52, Felix Schumacher > <[email protected]> wrote: > > Am Freitag, den 02.08.2013, 23:51 +0100 schrieb sebb: > >> On 2 August 2013 23:48, Milamber <[email protected]> wrote: > >> > Hello, > >> > > >> > I'm not sure that is relevant, but with ant distribution task: > >> > > >> > [java] o.a.j.junit.JMeterTest WARN: java.io.Serializable: > >> > IllegalAccessException > >> > org.apache.jmeter.protocol.http.control.KerberosManager > >> > >> Does the KerberosManager really need to be Serializable? > > It is a member of AuthManager, which is Serializable, so I think it > > should be Serializable. > > JMeter only uses Serializable in client-server tests. > If a class does not have to be sent across to the server (e.g. it is > created by the test run) then it should be stored in a transient > field. > > The client-server test case(s) probably need to be updated to check > that the AuthManager is correctly instantiated on the server. > Not sure how easy this will be with Kerberos. > > > Is there more information about the Exception? I can not think of any > > reason, why KerberosManager should be not Serializable. > > Probably due to the way the unit tests check Serializable classes; it > may need a no-args ctor. Seems to be the private inner class LoginCallbackHandler, that is causing this error. If I change it to public, the warning disapears.
Regards Felix > > > Regards > > Felix > >> > >> > ... > >> > > >> > Milamber > >> > > >> > > >> > Le 02/08/2013 14:45, Philippe Mouawad a ecrit : > >> > > >> >> it is still work in progress. > >> >> I will commit a reset auth on iteration as it is useful for kerberos > >> >> For these docs, feel free to fill in gaps as I am not a kerberos > >> >> specialist. > >> >> Regards > >> >> > >> >> On Friday, August 2, 2013, sebb wrote: > >> >> > >> >>> The two files jaas.conf and krb5.ini are supposed to be editted by the > >> >>> end-user before use > >> >>> > >> >>> However there is no documentation in them on what might need to be > >> >>> changed or what the individual entries mean. > >> >>> > >> >>> I think the files should at least have pointers to where to find the > >> >>> documentation. > >> >>> Possibly they need some local documentation as well, for example which > >> >>> entries need to be changed, and which must not be changed (if any). > >> >>> > >> >>> Why are there references to felix and tomcat? > >> >>> And why are the tomcat path names in the two files different. > >> >>> > >> >> > >> > > > > >
