Thanks Jack and Joe for your choices. I will go ahead and implement the option #1.
On Mon, Mar 15, 2010 at 9:17 PM, Jack Cai <[email protected]> wrote: > Interesting... Since the problem is really that FileKeystoreInstance is not > seriazable, I don't see why changing the getter return type would help if > the received objects are still instances of FileKeystoreInstance. Anyway, I > agree with Joe - Option 1 looks more elegant. > > -Jack > > > On Mon, Mar 15, 2010 at 1:25 PM, Ashish Jain <[email protected]> wrote: > >> The serialization problem is popping up due to the return type associated >> with getKeystores(). But in the case of getKeystores1() there is no return >> variable. So it helps in overcoming this problem. >> >> >> On Mon, Mar 15, 2010 at 8:18 AM, Jack Cai <[email protected]> wrote: >> >>> I still don't quite understand Option 2. So what would be stored in this >>> new attribute "keystores1"? If it still contains an instance of >>> FileKeystoreInstance, then there is still a serialization problem. >>> >>> -Jack >>> >>> >>> On Sat, Mar 13, 2010 at 5:20 PM, Ashish Jain <[email protected]> wrote: >>> >>>> Hi Joe, >>>> >>>> Thanks for your comments. The intent of using option #2 was to make use >>>> of getAttribute and also since modifying the KeystoreManager interface will >>>> not have any effect on any existing functionalities. However as you pointed >>>> out a get method w/o any return types may be misleading. >>>> >>>> Thanks >>>> Ashish >>>> >>>> >>>> On Fri, Mar 12, 2010 at 8:46 PM, Joe Bohn <[email protected]>wrote: >>>> >>>>> I don't know much about the details of the problem but it seems to me >>>>> that you would either make the class serializable (option #1) or exclude >>>>> it >>>>> from serialization if it is not necessary. I don't see how this would >>>>> impact any existing functions. So I guess I would vote for #1. >>>>> >>>>> I don't understand why you would want to have a "get*" method that >>>>> doesn't return anything - but perhaps I'm missing the point of option #2. >>>>> >>>>> Joe >>>>> >>>>> >>>>> >>>>> Ashish Jain wrote: >>>>> >>>>>> Hi ALL, >>>>>> >>>>>> I have opened up a JIRA GERONIMO-5180 on the unlockKeystore command >>>>>> failure if keystore is created with keytool.exe. I was trying to fix this >>>>>> issue >>>>>> which requires some changes in the class declaration or interface. >>>>>> Following code is being utilized to fix up the issue >>>>>> KeystoreInstance[] >>>>>> keystores=(KeystoreInstance[])kernel.getAttribute(abstractName,"keystores"); >>>>>> where abstractName is obtained through >>>>>> "org.apache.geronimo.management.geronimo.KeystoreManager". However I >>>>>> hit the following exception: >>>>>> >>>>>> java.rmi.UnmarshalException: error unmarshalling return; nested >>>>>> exception is: >>>>>> java.io.WriteAbortedException: writing aborted; >>>>>> java.io.NotSerializableE >>>>>> xception: org.apache.geronimo.security.keystore.FileKeystoreInstance >>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:172) >>>>>> at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) >>>>>> at >>>>>> javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(RMIConnecti >>>>>> onImpl_Stub.java:400) >>>>>> at >>>>>> javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection. >>>>>> invoke(RMIConnector.java:984) >>>>>> >>>>>> There are 2 ways to fix this up. >>>>>> >>>>>> 1) Make the class >>>>>> org.apache.geronimo.security.keystore.FileKeystoreInstance serializable. >>>>>> 2) add a new variable in FileKeystoreManager and add a new method in >>>>>> KeystoreManager which does not return anything and just gives a call >>>>>> to getKeystores(). For example getKeystores1() as the new method in >>>>>> KeystoreManager and a new variable as keystores1. >>>>>> >>>>>> I shall prefer #2 over #1 as it should not have any effect on existing >>>>>> functionalities. >>>>>> >>>>>> Suggestions/advice/comments?? >>>>>> >>>>>> Thanks >>>>>> Ashish >>>>>> >>>>> >>>>> >>>> >>> >> >
