[Soot-list] Handling conflicting class definitions?

[Marc-André Laverdière-Papineau]

Hello,

I realize that this is, in many ways, the right behavior.
I am trying to put many components together as one, which makes them 
step on each others' toes a bit. The problem is that I can't really 
detect this situation unless it is 'too late'. I can try having some 
kind of heuristic for the ordering of the jar files, but that won't be 
foolproof. :(

Any suggestions on how to implement what you are mentioning?

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 05/02/2013 12:00 AM, Patrick Lam wrote:
> On 05/01/13 17:56, Marc-André Laverdière-Papineau wrote:
>> Hello,
>>
>> I have a bit of code I am trying to test that is using web services.
>> Suppose that the WS implementation (non-abstract) class is pkg.Abc.
>> The stub generated by wsgen is pkg.Abc too, but it is an interface.
>>
>> What happens in Soot is that only one SootClass is possible for any
>> fully-qualified name. I sort of agree with that.
>>
>> The problem I get is that sometimes, the interface is returned by
>> Soot.getSootClass when I want the implementation class.
>>
>> I wanted to know if there was a way to define an override to handle this
>> kind of case, or if there was any way I could unload the interface and
>> force resolving the implementation instead.
>>
>> I am guessing that there is no easy way to do that, but I'd like a few
>> hints :)
>
> There's the whole class loader thing where it is possible to have
> multiple classes with the same fully-qualified name. Soot probably ought
> to support some static approximation of a class loader, but it hasn't
> really come up as a problem for anyone. This might introduce quite a bit
> of additional complexity though.
>
> pat
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>