geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish Jain <ashja...@gmail.com>
Subject Re: Discussion: Possible fixes for GERONIMO-5180
Date Tue, 16 Mar 2010 12:48:48 GMT
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 <greensight@gmail.com> 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 <ashjain2@gmail.com> 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 <greensight@gmail.com> 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 <ashjain2@gmail.com> 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 <joe.bohn@earthlink.net>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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message