3

I have a Session-Scope Bean LoginPlaintext that must not be serializable.

I have a Session-Scope Bean LoginMD5Salted that must be serializable.

Both share the interface Login that is not Serializable (because LoginPlaintext must be not serializable)!

My AppConfig.java looks like this:

public class AppConfig 
   ...
   Login loginData(ServletRequest request){
      if(request.getParameter('useMD5')!=null){
         return new LoginMD5Salted();
      }
      return new LoginPlaintext();
   }
}

My PermissionBean .java looks like this:

public class PermissionBean implements Serializable{
    @Autowired
    Login loginData;
}

My LoginPlaintext looks like this:

public class LoginPlaintext implements Login{
    String plainTextPassword;
    ....
}

My LoginMD5Salted looks like this:

public class LoginMD5Salted implements Login, Serializable{
    private static final long serialVersionUID = 2742674005972067910L;
    // not sure Upcase/Lowcase
    String MD5PasswordSalted;
}

If the session is serialized: the bean LoginPlaintext will not be persisted. If the Session is deserialized, all the other values are deserialized well but the deserializer for LoginPlaintext throws a NotSerializableException, ok.

If the session is serialized: the bean LoginMD5Salted will be persisted well. If the Session is deserialized, all values are deserialized well even the LoginMD5Salted without any trouble. Questions:

  1. How can i prevent a Log-Message for the class LoginPlaintext only?
  2. If the LoginPlaintext could not be deserialized via reactivation, is the AppConfig's loginData() method is invoked again?
Grim
  • 1,938
  • 10
  • 56
  • 123
  • would you please expalin it more about How can i prevent a Log-Message for the class FooImpl1 only? If the FooImpl1 could not be deserialized via reactivation, is the AppConfig's foo() method is invoked again? – abishkar bhattarai May 02 '13 at 15:42
  • 1. On server startup and first request with an old Session-ID-Cookie appears to the server: FooImpl1 cant be deserialized and a Exception is logged although its not a bug! How to prevent the logging of the not-bug-exception. 2. Therefore `@Autowire` should invoke foo() to produce new FooImpl2/FooImpl1. – Grim May 03 '13 at 07:45
  • Could you provide more info on your components? Like class declarations for Foo objects (members forcing it to stay non-serializable), whether Foo is part of a session attribute or is being bound directly (where are you using @Autowired), when and where Foo gets initialised (your calls to AppConfig.foo()) etc. – Ravi K Thapliyal May 06 '13 at 08:57
  • FWIW: *Foo* has been changed to Login .... – Grim May 06 '13 at 10:23
  • Ah, I missed checking your question back again. The problem's been explained quite nicely now. Please put the bounty again!! :) – Ravi K Thapliyal May 14 '13 at 19:12

3 Answers3

1

If it's not imperative to not implement serializable, you could just make it serializable and override the serialization/deserialization methods of LoginPlaintext to always serialize/deserialize null. Never done that, but shouldn't be too hard to do. See http://docs.oracle.com/javase/6/docs/api/java/io/Serializable.html

Another workaround can be to compose a scope session bean with both login flavors and mark the one you don't want to serialize with transient.

mamuso
  • 3,117
  • 3
  • 30
  • 32
  • Hm. Well, i guess i'd like to have the result of loginData() instead of null. Your way may work even if its looks like a Workaround. Seriously, am i the only one with this problem? Dont be sad, i'll wait for another answer. – Grim May 09 '13 at 19:55
  • I suppose that having non-serializable session scope beans is not a good practice. If you have to, having a custom serialization is not so rare. BTW, I've added a new workaraound to the answer. – mamuso May 10 '13 at 08:29
  • Can you specify the second in a new Answer? I guess you can use the `@Autowired(required=false) Serializable loginData; //MD5Salten` and `@Autowired transient Login loginData; //Plaintext` together. – Grim May 10 '13 at 08:44
0

Instead of having two beans with session scope, you could define a bean with session scope composed of the two flavours, the serializable and the non-serializable one.

This could be your PermissionBean.

Add the java keyword transient to the LoginPlaintext attribute. If I'm not wrong, this will be treated as if you implemented the first answer I gave you, i.e., it will not serialize your sensitive data and will return null on deserialization.

As with the previous one, I've not actually done it, so take it with a grain of salt

mamuso
  • 3,117
  • 3
  • 30
  • 32
0

I'd say why are you storing LoginPlaintext in the Session to begin with? It doesn't make sense to have loginData() returning a value to be stored in the Session that is only maybe serializable. Anything stored in the Session should be serializable if you are going to store the Session. So either do not store Login in the Session, make Login transient, or do not allow LoginPlaintext to implement Login.

Old Pro
  • 24,624
  • 7
  • 58
  • 106
  • Neither `LoginPlaintext` nor `LoginMD5Salted` are **direclty** stored in the Session but `PermissionBean` is stored in the Session. What 'bout `transient` fields in Sessions-Objects like `PermissionBean`? They are a part of the Session-Object but not Serializable. _Anything stored in the Session should be serializable_ - You mean a transient field in a Session-Object is bad practice? Hm... – Grim May 15 '13 at 09:00
  • The idea of making a Session storable is that it can be resumed on a different server or picked up a long time later as well as just surviving a restart of the server. In any case, the application has to be able to continue without any transient or non-serializable objects. So you either can, in which case you don't need to serialize `Login`, or you can't, in which case you do not need to save `LoginMD5Salted`. Your problem is that you have stored `Login` in the Session and it is only _sometimes_ serializable. – Old Pro May 15 '13 at 09:09