Hi Ralf
I saw your comments on the JIRA. If it's not default behaviour, I guess you
would need some nice way of making it obvious that if the user encounters a
certain exception, they would need to change the config to ignore the proxies.
I'm not sure if the exception thrown is always going to be the same though, in
fact I doubt you'd be able to rely on it to be honest. My Exception was
UnsupportedOperation, because I was trying to do a keyset on IdentityMap in my
proxied object. But the proxied object could have anything in it I think, so
you might just have to look for a generic exception.
What might be worse if if you successfully marshall a proxied object without
getting any exception (which could be possible). It might just result in
unexpected XML which could go unnoticed for a long time.
Also, in my case, it's possible that I could have put my code into production
without realising Castor needed the config change. This is because the query
bringing back the proxied object could be based on some other condition in the
Java. If this condition was never satisfied until after the code was released,
at some point after it went live I would see it stop working, then have to
change the config (to ignore proxies) and do a server restart.
So from my point of view I guess I would like to have it as default behaviour -
but I realise this isn't going to be the same for everyone.
Regarding performance, I did some very crude testing. First I did
----------------------------------------------------
for(int i=0; i<1000000; i++) {
System.out.println("Doing something that takes a finite amount of
time");
}
This took about 114 seconds
----------------------------------------------------
Then I did
----------------------------------------------------
for(int i=0; i<1000000; i++) {
if(!(o.getClass().getName("java.lang.String"))) {
System.out.println("Doing something that takes a finite amount
of time");
}
}
This also took 114 seconds
----------------------------------------------------
Then I did
----------------------------------------------------
for(int i=0; i<1000000; i++) {
if(!(o instanceof java.lang.String)) {
System.out.println("Doing something that takes a finite amount
of time");
}
}
This took 105 seconds
----------------------------------------------------
Not very scientific I know, but it shows that instanceof is faster - although
not by as much as I had expected.
Richard Gundersen
Java Developer
Email: [EMAIL PROTECTED]
Phone: 01618302398
Fax: 01618342536
London Scottish Bank plc
24 Mount Street
Manchester
M2 3LS
-----Original Message-----
From: Ralf Joachim [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 9:32 AM
To: dev@castor.codehaus.org
Subject: Re: [castor-dev] CASTOR-1342 (Marshalling Proxy Classes)
Hi Richard,
can you please test the new patch I attached to CASTOR-1342. I'm quite
confident that this one will fix the problem.
Regards
Ralf
Gundersen, Richard schrieb:
> Hi Ralf
>
> No problemo. For Hibernate there's the isUninitialized() method as described
> in the links below. This is Hibernate-specific of course, so taking care of
> all other APIs that use proxied objects could potentially be a bit messy. I
> think the CGLIB API might be the place to look for a common solution. I don't
> know anything about CGLIB but I'll try to spend some time today to do a bit
> of digging. If I find anything useful I will let you know.
>
> http://www.nabble.com/HibernateProxy-causes-class-type-mismatch-t4031421.html
> https://jaxb.dev.java.net/issues/show_bug.cgi?id=280
>
> Richard Gundersen
> Java Developer
>
> Email: [EMAIL PROTECTED]
> Phone: 01618302398
> Fax: 01618342536
> London Scottish Bank plc
> 24 Mount Street
> Manchester
> M2 3LS
>
> -----Original Message-----
> From: Ralf Joachim [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 17, 2007 5:33 PM
> To: dev@castor.codehaus.org
> Subject: Re: [castor-dev] CASTOR-1342 (Marshalling Proxy Classes)
>
> Sorry Richard,
>
> I've also been busy with other things.
>
> When I updated the patch for you and others to test I also got the
> feeling that the approach taken to detect proxies is not what we need.
> I'll try to find some spare time to look at this in more details soon.
>
> Regards
> Ralf
>
>
> Gundersen, Richard schrieb:
>> Hi Ralf
>>
>> Sorry for not getting back to you on this for several weeks on this -
>> very slack of me!
>>
>> I've been trying to apply your patch with varying degrees of success.
>> With the changes in place, Castor still seems to marshall an object that
>> comes back to me as an 'EnhancerByCGLIB' object.
>>
>> I don't know too much about this, but I think it's because Hibernate is
>> returning a class of type:
>>
>> com.lsb.uk.mqs.value.GeneralRefLabelValue$$EnhancerByCGLIB$$51aebe8f
>>
>> I've tried using the isProxyClass() method in both the
>> java.lang.reflect.Proxy and net.sf.cglib.proxy.Proxy classes. Neither
>> recognises my class as a proxy class, so my guess is that Castor will
>> try and parse it.
>>
>> Does this sound like I could be on the right track? I think we may need
>> another way to detect what kinds of classes should be marshalled. What
>> do you think?
>>
>> If I can be of any help let me know.
>>
>> Richard Gundersen
>>
>>
>> *** Disclaimer ***
>>
>> This electronic communication is confidential and for the exclusive use of
>> the addressee. It may contain private and confidential information. The
>> information, attachments and opinions contained in this E-mail are those of
>> its author only and do not necessarily represent those of London Scottish
>> Bank PLC or any other members of the London Scottish Group.
>>
>> If you are not the intended addressee, you are prohibited from any
>> disclosure, distribution or further copying or use of this communication or
>> the information in it or taking any action in reliance on it. If you have
>> received this communication in error please notify the Information Security
>> Manager at [EMAIL PROTECTED] as soon as possible and delete the message from
>> all places in your computer where it is stored.
>>
>> We utilise virus scanning software but we cannot guarantee the security of
>> electronic communications and you are advised to check any attachments for
>> viruses. We do not accept liability for any loss resulting from any
>> corruption or alteration of data or importation of any virus as a result of
>> receiving this electronic communication.
>>
>> Replies to this E-mail may be monitored for operational or business reasons.
>> London Scottish Bank PLC is regulated by the Financial Services Authority.
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>
--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. +49 7071 3690 52
Mobil: +49 173 9630135
Fax +49 7071 3690 98
Internet: www.syscon.eu
E-Mail: [EMAIL PROTECTED]
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
*** Disclaimer ***
This electronic communication is confidential and for the exclusive use of the
addressee. It may contain private and confidential information. The
information, attachments and opinions contained in this E-mail are those of its
author only and do not necessarily represent those of London Scottish Bank PLC
or any other members of the London Scottish Group.
If you are not the intended addressee, you are prohibited from any disclosure,
distribution or further copying or use of this communication or the information
in it or taking any action in reliance on it. If you have received this
communication in error please notify the Information Security Manager at [EMAIL
PROTECTED] as soon as possible and delete the message from all places in your
computer where it is stored.
We utilise virus scanning software but we cannot guarantee the security of
electronic communications and you are advised to check any attachments for
viruses. We do not accept liability for any loss resulting from any corruption
or alteration of data or importation of any virus as a result of receiving this
electronic communication.
Replies to this E-mail may be monitored for operational or business reasons.
London Scottish Bank PLC is regulated by the Financial Services Authority.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
