[sip-comm-dev] Account Info Detail Replacement


#1

Hello everyone,

I've been trying to finish up the Account Information plug-in, but I've had a problem with the actual updating process. I talked with Yana about it a bit and I think we'd need to make a change to details in general, so I was hoping for some thoughts.

The way it works now, the OperationSetServerStoredAccountInfo has a replace method that takes two details: the old one and the new one that is replacing it. The problem is that both of these details need to be of the same type. The way we display all of these details takes into account certain special details that have unusual detail values, for instance, a Calendar. Besides that, regardless if it's an InterestDetail or an ObscureHobbyDetail, the detail value is just a string, so we stick it into a text area.

That level of blindness works out fine until we go to replace the details. To retrieve the available details there is the method getAllAvailableDetails, but it returns an iterator that we can only get objects from. The best we can do right now is cast to a GenericDetail, but without knowing exactly what we need, there's always an error when trying to replace because the detail types do not match.

So if anyone has any suggestions for how to get around this problem, I would very much appreciate it. Thank you very much!

Adam

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Adam,
See inline:

Hello everyone,

I've been trying to finish up the Account Information plug-in, but I've
had a problem with the actual updating process. I talked with Yana about
it a bit and I think we'd need to make a change to details in general,
so I was hoping for some thoughts.

The way it works now, the OperationSetServerStoredAccountInfo has a
replace method that takes two details: the old one and the new one that
is replacing it. The problem is that both of these details need to be of
the same type. The way we display all of these details takes into
account certain special details that have unusual detail values, for
instance, a Calendar. Besides that, regardless if it's an InterestDetail
or an ObscureHobbyDetail, the detail value is just a string, so we stick
it into a text area.

That level of blindness works out fine until we go to replace the
details. To retrieve the available details there is the method
getAllAvailableDetails, but it returns an iterator that we can only get
objects from. The best we can do right now is cast to a GenericDetail,
but without knowing exactly what we need, there's always an error when
trying to replace because the detail types do not match.

I'm no expert in the area, but I think you might hack a solution to it
by using reflection (see
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/package-summary.html
for more info). This way you could determine at runtime the class of
each detail and cast the object returned by the iterator
appropriately.
I'd like to hear more from you if you decide to go this way, or if
what i'm saying is a total mess :smiley:

So if anyone has any suggestions for how to get around this problem, I
would very much appreciate it. Thank you very much!

Adam

All the best,
Mihai

···

On 8/20/07, Adam Goldstein <abgoldstein@gmail.com> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello all,
   
  In SipRegistrarConnection.java:
      //OK
        if (response.getStatusCode() == Response.OK) {
            processOK(clientTransaction, response);
        }
        //NOT_IMPLEMENTED
        else if (response.getStatusCode() == Response.OK) {
            processNotImplemented(clientTransaction, response);
        }
   
  Which should be:
   
      //OK
        if (response.getStatusCode() == Response.OK) {
            processOK(clientTransaction, response);
        }
        //NOT_IMPLEMENTED
        else if (response.getStatusCode() == Response.NOT_IMPLEMENTED) {
            processNotImplemented(clientTransaction, response);
        }
   
  mik.


#4

Hey Mihai, everyone,

Thanks for the recommendation. I hadn't heard of the reflection class before, but it does seem like it might be able to provide a pretty good solution to the problem I've been having. Even though it would fix what's going on now, it seems like it might be worthwhile to actually change the way the details themselves work so there's a more robust solution that might prevent more hassle in the future. Your idea is definitely better than my original which was to put some really long block of conditionals and instanceof's and some sort of mess like that.

Yana and I were talking a bit about it and it would be nice if there were some sort of detail factory that could give us all of the proper types so we can use them, but I don't know how complicated that would be to actually make. I'd be happy to try to do it or to help do it if that seems like the best answer to this though. Does that seem like the way to go?

Adam

Mihai Balan wrote:

···

Hi Adam,
See inline:

On 8/20/07, Adam Goldstein <abgoldstein@gmail.com> wrote:
  

Hello everyone,

I've been trying to finish up the Account Information plug-in, but I've
had a problem with the actual updating process. I talked with Yana about
it a bit and I think we'd need to make a change to details in general,
so I was hoping for some thoughts.

The way it works now, the OperationSetServerStoredAccountInfo has a
replace method that takes two details: the old one and the new one that
is replacing it. The problem is that both of these details need to be of
the same type. The way we display all of these details takes into
account certain special details that have unusual detail values, for
instance, a Calendar. Besides that, regardless if it's an InterestDetail
or an ObscureHobbyDetail, the detail value is just a string, so we stick
it into a text area.

That level of blindness works out fine until we go to replace the
details. To retrieve the available details there is the method
getAllAvailableDetails, but it returns an iterator that we can only get
objects from. The best we can do right now is cast to a GenericDetail,
but without knowing exactly what we need, there's always an error when
trying to replace because the detail types do not match.
    
I'm no expert in the area, but I think you might hack a solution to it
by using reflection (see
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/package-summary.html
for more info). This way you could determine at runtime the class of
each detail and cast the object returned by the iterator
appropriately.
I'd like to hear more from you if you decide to go this way, or if
what i'm saying is a total mess :smiley:

So if anyone has any suggestions for how to get around this problem, I
would very much appreciate it. Thank you very much!

Adam
    
All the best,
Mihai

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Adam,

In two words: add fromString() to GenericDetail and its children (most of the functions should be trivial.. I hope:)

The rest of the mail discusses this solution and some issues related to it.

···

****************

I also agree that reflection may not be the best solution in this case. I mean it's doable, but would require some implicit conventions to be defined (like always having a constructor with some fixed parameters).
I'm not the designer of the service, so I can't tell you what was the intended usage, but I think that using a factory can be a good idea.

One (simple) solution could be to define a non-static method "GenericDetail fromString(String value)" to the parent class of all details (GenericDetail). Currently, when you don't know what to do with a given type of detail (like the ObscureHobbyDetail you mention) you do a toString() and put the result into a text field. If the user changes the contents of the text field you can simply say hobby.fromString(textField.getText()) which would return you a GenericDetail object, which you can then pass on to the replace method.

The disadvantages: such method must be added to GenericDetail and all inheriting classes that need some special parsing of the string (if the "replace" function is not clever enough this may require that ALL inheriting classes should override this function.. ouch). Another potential problem is that there might be some details that cannot be parsed easily from strings, BUT I think that they should be addressed with special controls anyway, so this is less of a problem. In order to allow some kind of general treatment of all details one may add a method like "isFromStringEnabled" which would indicate if the fromString method actually works, or just throws an exception like UnsupportedOperationException. This way, you as a GUI implementor, would know to put the given detail in a read-only text field.

Why this should work:
The nice thing is that when an object provides a toString method it does not simply generate a random string (in the common case) - instead it builds up a string representation of its data. A Calendar object may (depending on its locale) return something like "01-02-2005". It is not meaningless to suppose that in some cases it will be able to extract some information from a given string (if the user changes the date in the previous example to "10-10-2006" the calendar might be clever enough to understand the new value). This is exactly what the fromString method should do - create a new CalendarDetail object and put in the correct data. If it fails (like the user has filled in something like "I love SIP communicator, can I get a cookie?") it might just throw an exception (something like java's IllegalFormatConversionException) thus indicating you to inform the user, that they won't get a cookie unless they fill in a date in the correct format.

This is a very big subject, and one can do tons of stuff making it as flexible (and complex) as possible.

What do you think about this?
Alex

Le 21 août 07 à 08:00, Adam Goldstein a écrit :

Hey Mihai, everyone,

Thanks for the recommendation. I hadn't heard of the reflection class before, but it does seem like it might be able to provide a pretty good solution to the problem I've been having. Even though it would fix what's going on now, it seems like it might be worthwhile to actually change the way the details themselves work so there's a more robust solution that might prevent more hassle in the future. Your idea is definitely better than my original which was to put some really long block of conditionals and instanceof's and some sort of mess like that.

Yana and I were talking a bit about it and it would be nice if there were some sort of detail factory that could give us all of the proper types so we can use them, but I don't know how complicated that would be to actually make. I'd be happy to try to do it or to help do it if that seems like the best answer to this though. Does that seem like the way to go?

Adam

Mihai Balan wrote:

Hi Adam, See inline: On 8/20/07, Adam Goldstein <abgoldstein@gmail.com> wrote:

Hello everyone, I've been trying to finish up the Account Information plug-in, but I've had a problem with the actual updating process. I talked with Yana about it a bit and I think we'd need to make a change to details in general, so I was hoping for some thoughts. The way it works now, the OperationSetServerStoredAccountInfo has a replace method that takes two details: the old one and the new one that is replacing it. The problem is that both of these details need to be of the same type. The way we display all of these details takes into account certain special details that have unusual detail values, for instance, a Calendar. Besides that, regardless if it's an InterestDetail or an ObscureHobbyDetail, the detail value is just a string, so we stick it into a text area. That level of blindness works out fine until we go to replace the details. To retrieve the available details there is the method getAllAvailableDetails, but it returns an iterator that we can only get objects from. The best we can do right now is cast to a GenericDetail, but without knowing exactly what we need, there's always an error when trying to replace because the detail types do not match.

I'm no expert in the area, but I think you might hack a solution to it by using reflection (see http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/package-summary.html for more info). This way you could determine at runtime the class of each detail and cast the object returned by the iterator appropriately. I'd like to hear more from you if you decide to go this way, or if what i'm saying is a total mess :smiley:

So if anyone has any suggestions for how to get around this problem, I would very much appreciate it. Thank you very much! Adam

All the best, Mihai --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Michael,

Got it. Applied and committed.

I wanted to ack but I couldn't find you complete name or affiliation
anywhere. Could you please send them over when you have the time (if you
are interested of course.)

Emil

mik wrote:

···

Hello all,

In SipRegistrarConnection.java:
    //OK
        if (response.getStatusCode() == Response.OK) {
            processOK(clientTransaction, response);
        }
        //NOT_IMPLEMENTED
        else if (response.getStatusCode() == Response.OK) {
            processNotImplemented(clientTransaction, response);
        }

Which should be:

    //OK
        if (response.getStatusCode() == Response.OK) {
            processOK(clientTransaction, response);
        }
        //NOT_IMPLEMENTED
        else if (response.getStatusCode() == Response.NOT_IMPLEMENTED) {
            processNotImplemented(clientTransaction, response);
        }

mik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hey Alex, Emil, Everyone,

Thank you very much for the e-mail you sent. I've been thinking about it for awhile and I really appreciated the thoughts. In general, I completely agree with the idea behind the fromString method. Do you think it would be better to implement that and alter each detail class, or do you think it would be better to have some sort of dedicated class that would basically be one consolidated location for all of the detail's fromStrings?

If we choose to manage it in each detail class, rather than having some sort of boolean value like isFromStringSupported, I think it might be worth making an interface called Replaceable. All implementing classes would have to have a fromString method and we would then know that any details that are not of the type Replaceable should be read-only. I like the idea of keeping everything in one dedicated class, but it's probably better style and a little more intuitive to actually alter each detail itself.

In any case, let me know what you think. Thanks again very much for the thoughts.

Adam

Alexander Pelov wrote:

···

Hi Adam,

In two words: add fromString() to GenericDetail and its children (most of the functions should be trivial.. I hope:)

The rest of the mail discusses this solution and some issues related to it.

****************

I also agree that reflection may not be the best solution in this case. I mean it's doable, but would require some implicit conventions to be defined (like always having a constructor with some fixed parameters).
I'm not the designer of the service, so I can't tell you what was the intended usage, but I think that using a factory can be a good idea.

One (simple) solution could be to define a non-static method "GenericDetail fromString(String value)" to the parent class of all details (GenericDetail). Currently, when you don't know what to do with a given type of detail (like the ObscureHobbyDetail you mention) you do a toString() and put the result into a text field. If the user changes the contents of the text field you can simply say hobby.fromString(textField.getText()) which would return you a GenericDetail object, which you can then pass on to the replace method.

The disadvantages: such method must be added to GenericDetail and all inheriting classes that need some special parsing of the string (if the "replace" function is not clever enough this may require that ALL inheriting classes should override this function.. ouch). Another potential problem is that there might be some details that cannot be parsed easily from strings, BUT I think that they should be addressed with special controls anyway, so this is less of a problem. In order to allow some kind of general treatment of all details one may add a method like "isFromStringEnabled" which would indicate if the fromString method actually works, or just throws an exception like UnsupportedOperationException. This way, you as a GUI implementor, would know to put the given detail in a read-only text field.

Why this should work:
The nice thing is that when an object provides a toString method it does not simply generate a random string (in the common case) - instead it builds up a string representation of its data. A Calendar object may (depending on its locale) return something like "01-02-2005". It is not meaningless to suppose that in some cases it will be able to extract some information from a given string (if the user changes the date in the previous example to "10-10-2006" the calendar might be clever enough to understand the new value). This is exactly what the fromString method should do - create a new CalendarDetail object and put in the correct data. If it fails (like the user has filled in something like "I love SIP communicator, can I get a cookie?") it might just throw an exception (something like java's IllegalFormatConversionException) thus indicating you to inform the user, that they won't get a cookie unless they fill in a date in the correct format.

This is a very big subject, and one can do tons of stuff making it as flexible (and complex) as possible.

What do you think about this?
Alex

Le 21 ao�t 07 � 08:00, Adam Goldstein a �crit :

Hey Mihai, everyone,

Thanks for the recommendation. I hadn't heard of the reflection class before, but it does seem like it might be able to provide a pretty good solution to the problem I've been having. Even though it would fix what's going on now, it seems like it might be worthwhile to actually change the way the details themselves work so there's a more robust solution that might prevent more hassle in the future. Your idea is definitely better than my original which was to put some really long block of conditionals and instanceof's and some sort of mess like that.

Yana and I were talking a bit about it and it would be nice if there were some sort of detail factory that could give us all of the proper types so we can use them, but I don't know how complicated that would be to actually make. I'd be happy to try to do it or to help do it if that seems like the best answer to this though. Does that seem like the way to go?

Adam

Mihai Balan wrote:

Hi Adam, See inline: On 8/20/07, Adam Goldstein <abgoldstein@gmail.com> wrote:

Hello everyone, I've been trying to finish up the Account Information plug-in, but I've had a problem with the actual updating process. I talked with Yana about it a bit and I think we'd need to make a change to details in general, so I was hoping for some thoughts. The way it works now, the OperationSetServerStoredAccountInfo has a replace method that takes two details: the old one and the new one that is replacing it. The problem is that both of these details need to be of the same type. The way we display all of these details takes into account certain special details that have unusual detail values, for instance, a Calendar. Besides that, regardless if it's an InterestDetail or an ObscureHobbyDetail, the detail value is just a string, so we stick it into a text area. That level of blindness works out fine until we go to replace the details. To retrieve the available details there is the method getAllAvailableDetails, but it returns an iterator that we can only get objects from. The best we can do right now is cast to a GenericDetail, but without knowing exactly what we need, there's always an error when trying to replace because the detail types do not match.

I'm no expert in the area, but I think you might hack a solution to it by using reflection (see http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/package-summary.html for more info). This way you could determine at runtime the class of each detail and cast the object returned by the iterator appropriately. I'd like to hear more from you if you decide to go this way, or if what i'm saying is a total mess :smiley:

So if anyone has any suggestions for how to get around this problem, I would very much appreciate it. Thank you very much! Adam

All the best, Mihai --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Adam,

Some more thoughts on the fromString method (should we go with a dedicated factory or should every class define such method) and the isFromStringSupported method (should we use an interface to mark a class as supplying a working fromString method instead).

My opinion on this is that we should keep it simple and let each class define it's own fromString method (if necessary) and define an isFromStringSupported method.

The rest of the mail explains why.

···

********************

I'm glad you liked the "fromString()" approach :wink:
I think I like having each detail class supplying its own fromString a little better than delegating the work to an external class, but I must underline that don't know the entire framework behind the "details". In fact, you are proposing the creation of a full-blown factory, that will be able to produce all kinds of details, which also has its advantages.

I'd go with the fromString-per-class solution, because this way we're going to have a symmetry in the code (toString-fromString) and it would be less prone to errors (if someone changes one of the method, he/she is then obligated to change the other one as well - and I think that having to go and change the code in some other class would be more prone to errors). Furthermore, if at a later stage we decide that we want the factory stuff after all, we can always write a short class that uses a little bit reflection and calls the fromString method of the class it's supposed to instantiate.

On the other hand, a factory is almost always a good solution when it comes to creating objects without knowing their type in advance. Moreover it seems to be a cleaner solution, in the sense that you don't need to have an entire object to create a new instance (you need just the class, which in absolute terms is less information). However, given the current usage of the details this is not that much of an advantage (you always have an object to replicate).

So, to summarize this issue: I'd go with fromString-per-class out of aesthetics and most importantly - following the KISS rule.

The Replaceable interface seems as a good idea, but (there's always a but;) you're going to have problems if one detail is Replaceable and its child is not.. well doesn't want to be. The thing is that I don't think that it's a good idea to mix the implicit information contained in the class hierarchy (which is - what is the type of this object?) with the information about its functionality (which is explicit and is coded in its methods). In the current context, it translates to the case when the HobbyDetail is Replaceable, but its child OrderedHobbyDetail doesn't want to be, but cannot do anything about it (which is for example when the author of the latter class didn't provide appropriate parser). If you look from class point of view, the OrderedHobbyDetail is indeed a child of HobbyDetail (adding just the order to it), but requires additional functionality, which may or may not be implemented. If you have a method isFromStringSupported you can simply override it and return false. Finally, it is quite probable that one could be able to add a fromString method to GenericDetail, and if GenericDetail is marked as a Replaceable, then every class underneath it is going to be Replaceable, which effectively eliminates its utility. Finally, I think that even if you decide to go with the interface solution you should think of another name for the interface, because it should only state that you can create objects of this type out of strings (e.g. one may perfectly well be able to call fromString, but the protocol provider may be unable to replace this kind of details - it's not really Replaceable, but FromStringable sort of thing).

That's from me for now, I hope that you'll find these comments useful. Surely, there are some cases that I didn't think about, so don't hesitate to give some examples where these things don't work that well.

Regards,
Alex

Le 27 août 07 à 09:47, Adam Goldstein a écrit :

Hey Alex, Emil, Everyone,

Thank you very much for the e-mail you sent. I've been thinking about it for awhile and I really appreciated the thoughts. In general, I completely agree with the idea behind the fromString method. Do you think it would be better to implement that and alter each detail class, or do you think it would be better to have some sort of dedicated class that would basically be one consolidated location for all of the detail's fromStrings?

If we choose to manage it in each detail class, rather than having some sort of boolean value like isFromStringSupported, I think it might be worth making an interface called Replaceable. All implementing classes would have to have a fromString method and we would then know that any details that are not of the type Replaceable should be read-only. I like the idea of keeping everything in one dedicated class, but it's probably better style and a little more intuitive to actually alter each detail itself.

In any case, let me know what you think. Thanks again very much for the thoughts.

Adam

Alexander Pelov wrote:

Hi Adam,

In two words: add fromString() to GenericDetail and its children (most of the functions should be trivial.. I hope:)

The rest of the mail discusses this solution and some issues related to it.

****************

I also agree that reflection may not be the best solution in this case. I mean it's doable, but would require some implicit conventions to be defined (like always having a constructor with some fixed parameters).
I'm not the designer of the service, so I can't tell you what was the intended usage, but I think that using a factory can be a good idea.

One (simple) solution could be to define a non-static method "GenericDetail fromString(String value)" to the parent class of all details (GenericDetail). Currently, when you don't know what to do with a given type of detail (like the ObscureHobbyDetail you mention) you do a toString() and put the result into a text field. If the user changes the contents of the text field you can simply say hobby.fromString(textField.getText()) which would return you a GenericDetail object, which you can then pass on to the replace method.

The disadvantages: such method must be added to GenericDetail and all inheriting classes that need some special parsing of the string (if the "replace" function is not clever enough this may require that ALL inheriting classes should override this function.. ouch). Another potential problem is that there might be some details that cannot be parsed easily from strings, BUT I think that they should be addressed with special controls anyway, so this is less of a problem. In order to allow some kind of general treatment of all details one may add a method like "isFromStringEnabled" which would indicate if the fromString method actually works, or just throws an exception like UnsupportedOperationException. This way, you as a GUI implementor, would know to put the given detail in a read-only text field.

Why this should work:
The nice thing is that when an object provides a toString method it does not simply generate a random string (in the common case) - instead it builds up a string representation of its data. A Calendar object may (depending on its locale) return something like "01-02-2005". It is not meaningless to suppose that in some cases it will be able to extract some information from a given string (if the user changes the date in the previous example to "10-10-2006" the calendar might be clever enough to understand the new value). This is exactly what the fromString method should do - create a new CalendarDetail object and put in the correct data. If it fails (like the user has filled in something like "I love SIP communicator, can I get a cookie?") it might just throw an exception (something like java's IllegalFormatConversionException) thus indicating you to inform the user, that they won't get a cookie unless they fill in a date in the correct format.

This is a very big subject, and one can do tons of stuff making it as flexible (and complex) as possible.

What do you think about this?
Alex

Le 21 août 07 à 08:00, Adam Goldstein a écrit :

Hey Mihai, everyone,

Thanks for the recommendation. I hadn't heard of the reflection class before, but it does seem like it might be able to provide a pretty good solution to the problem I've been having. Even though it would fix what's going on now, it seems like it might be worthwhile to actually change the way the details themselves work so there's a more robust solution that might prevent more hassle in the future. Your idea is definitely better than my original which was to put some really long block of conditionals and instanceof's and some sort of mess like that.

Yana and I were talking a bit about it and it would be nice if there were some sort of detail factory that could give us all of the proper types so we can use them, but I don't know how complicated that would be to actually make. I'd be happy to try to do it or to help do it if that seems like the best answer to this though. Does that seem like the way to go?

Adam

Mihai Balan wrote:

Hi Adam, See inline: On 8/20/07, Adam Goldstein <abgoldstein@gmail.com> wrote:

Hello everyone, I've been trying to finish up the Account Information plug-in, but I've had a problem with the actual updating process. I talked with Yana about it a bit and I think we'd need to make a change to details in general, so I was hoping for some thoughts. The way it works now, the OperationSetServerStoredAccountInfo has a replace method that takes two details: the old one and the new one that is replacing it. The problem is that both of these details need to be of the same type. The way we display all of these details takes into account certain special details that have unusual detail values, for instance, a Calendar. Besides that, regardless if it's an InterestDetail or an ObscureHobbyDetail, the detail value is just a string, so we stick it into a text area. That level of blindness works out fine until we go to replace the details. To retrieve the available details there is the method getAllAvailableDetails, but it returns an iterator that we can only get objects from. The best we can do right now is cast to a GenericDetail, but without knowing exactly what we need, there's always an error when trying to replace because the detail types do not match.

I'm no expert in the area, but I think you might hack a solution to it by using reflection (see http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/package-summary.html for more info). This way you could determine at runtime the class of each detail and cast the object returned by the iterator appropriately. I'd like to hear more from you if you decide to go this way, or if what i'm saying is a total mess :smiley:

So if anyone has any suggestions for how to get around this problem, I would very much appreciate it. Thank you very much! Adam

All the best, Mihai --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net