Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
It's not a case of an unknown reference causing the not serializable exception. I know which object is not serializable and it is the concrete proxy object created by WebLogic for my remote EJB. I ended up checking if I was in development mode and then using a transient variable and then using a another variable which is not transient when the app is running in a production environment. I was hesitant to simply mark the EJB as transient in case it caused issues in the production environment. Thanks all for your replies, they helped confirm that there wasn't a workaround other than marking it transient. Regards Johan Compagner wrote: cant you make the non serializable object transient? and make sure that you can relookup the object when it is null? johan On 6/4/07, Saad, Salma [EMAIL PROTECTED] wrote: I have a wicket page (java class) which uses a service locater to execute messages on a remote EJB. Though there is no direct reference to the EJB from my wicket page there is a reference to the service locater which uses JNDI to get a reference to the remote EJB. I get the following error (FYI, This error does not happen in wicket 1.2 but happens in wicket 1.2.6). WicketMessage: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.abc.wicket.LoginPage Root cause: java.io.NotSerializableException: com. abc.ejb. AFacadeBean. AFacadeBean_7gl30w_EOImpl The EJB implements javax.ejb.SessionBean which extends the serializable interface but the EJB proxy object returned by the WebLogic server does NOT implement serialzable. Below is the class hierarchy of the object located through JNDI. (I printed this using reflectiion) com. abc.ejb. AFacadeBean. AFacadeBean _7gl30w_HomeImpl -weblogic.ejb20.internal.StatelessEJBHome --weblogic.ejb20.internal.BaseEJBHome ---java.lang.Object So it seems that I cannot use EJB's in wicket pages, (I am doing this indirectly through service locaters to decouple the pages from the back end). Any advice about what to do in this situation would be appreciated. Currently I am running in deployment mode since this avoids the checking. I have given some thought to marking the EJB transient in my service locator but would like to hear any insights/design suggestions/advice -- CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. It is neither an offer to buy or sell, nor a solicitation of an offer to buy or sell, any securities or any related financial instruments mentioned in it. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Unless otherwise indicated, copyright and any other intellectual property rights in its contents are the sole property of Mizuho Securities USA Inc. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/Wicket-1.2.6-Development-mode-serialization-checks-and-remote-EJB%27s-tf3866878.html#a11008736 Sent from the Wicket - User mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version
Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
so the end result is that in production you have now a none serializeable object in the session? that is not really the right solution if you ask me. also going to wicket1.3 (with SecondLevelCache) is not an option then johan On 6/7/07, salmas [EMAIL PROTECTED] wrote: It's not a case of an unknown reference causing the not serializable exception. I know which object is not serializable and it is the concrete proxy object created by WebLogic for my remote EJB. I ended up checking if I was in development mode and then using a transient variable and then using a another variable which is not transient when the app is running in a production environment. I was hesitant to simply mark the EJB as transient in case it caused issues in the production environment. Thanks all for your replies, they helped confirm that there wasn't a workaround other than marking it transient. Regards Johan Compagner wrote: cant you make the non serializable object transient? and make sure that you can relookup the object when it is null? johan On 6/4/07, Saad, Salma [EMAIL PROTECTED] wrote: I have a wicket page (java class) which uses a service locater to execute messages on a remote EJB. Though there is no direct reference to the EJB from my wicket page there is a reference to the service locater which uses JNDI to get a reference to the remote EJB. I get the following error (FYI, This error does not happen in wicket 1.2 but happens in wicket 1.2.6). WicketMessage: Internal error cloning object. Make sure all dependent objects implement Serializable. Class: com.abc.wicket.LoginPage Root cause: java.io.NotSerializableException: com. abc.ejb. AFacadeBean. AFacadeBean_7gl30w_EOImpl The EJB implements javax.ejb.SessionBean which extends the serializable interface but the EJB proxy object returned by the WebLogic server does NOT implement serialzable. Below is the class hierarchy of the object located through JNDI. (I printed this using reflectiion) com. abc.ejb. AFacadeBean. AFacadeBean _7gl30w_HomeImpl -weblogic.ejb20.internal.StatelessEJBHome --weblogic.ejb20.internal.BaseEJBHome ---java.lang.Object So it seems that I cannot use EJB's in wicket pages, (I am doing this indirectly through service locaters to decouple the pages from the back end). Any advice about what to do in this situation would be appreciated. Currently I am running in deployment mode since this avoids the checking. I have given some thought to marking the EJB transient in my service locator but would like to hear any insights/design suggestions/advice -- CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. It is neither an offer to buy or sell, nor a solicitation of an offer to buy or sell, any securities or any related financial instruments mentioned in it. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Unless otherwise indicated, copyright and any other intellectual property rights in its contents are the sole property of Mizuho Securities USA Inc. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context:
Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
Eelco, I realized that you are recommending using Spring or looking up the bean on the fly some other way but I am working for a place where Spring is not part of the approved stack and they have an established way that access to EJB's is coded. I am a contracter here and I have to do things exactly how it has been established by the architecture team. I will forward your comments to them so that they can see the advantage of your approach,I am sure they will be interested in the suggestion. Eelco Hillenius wrote: It's not a case of an unknown reference causing the not serializable exception. I know which object is not serializable and it is the concrete proxy object created by WebLogic for my remote EJB. I ended up checking if I was in development mode and then using a transient variable and then using a another variable which is not transient when the app is running in a production environment. I was hesitant to simply mark the EJB as transient in case it caused issues in the production environment. Thanks all for your replies, they helped confirm that there wasn't a workaround other than marking it transient. But there is. You can turn the check off, even for development mode. See IDebugSettings#setSerializeSessionAttributes[1] What you probably want in the end though, is a construct like @SpringBean or just look the bean up right at the moment you need it without holding the reference. Eelco [1] http://wicket.sourceforge.net/apidocs/wicket/settings/IDebugSettings.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/Wicket-1.2.6-Development-mode-serialization-checks-and-remote-EJB%27s-tf3866878.html#a11010404 Sent from the Wicket - User mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
Eelco, I realized that you are recommending using Spring or looking up the bean on the fly some other way but I am working for a place where Spring is not part of the approved stack and they have an established way that access to EJB's is coded. Not really. I mean a @SpringBean *construct*, like you can find in the Spring integration project. That project generates proxies for every @SpringBean annot found. These proxies are light and serializable, and internally hold a transient reference to the actual spring bean. When serialized, the spring bean instance is discarded; the proxy will locate it again when it is called. You said you can't use annotations, so that trick wouldn't go here for you. There used to be a project[1] (now only for 1.2.x) that used commons attributes[2] for the same purpose, but we're not maintaining it for 1.3 anymore (though it is stored as a wicket-stuff project now[3]). Alternatively, you can just locate the bean just in time. Are you sure you need to keep a reference to it in your component(s)? And consider that *if* you need a reference, it's probably per-request (so you'll want a new one when a new request starts). If that is true, you can just set the reference lazily (get it when you actually access it), and null it in the components onDetach method (override that method; it will be called when a request is handled) so that it won't be serialized. Eelco [1] http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-1.2.x/wicket-spring-annot [2] http://jakarta.apache.org/commons/attributes/ [3] https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-spring-cattr - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
has this already been mentioned? http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee -igor On 6/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Eelco, I realized that you are recommending using Spring or looking up the bean on the fly some other way but I am working for a place where Spring is not part of the approved stack and they have an established way that access to EJB's is coded. Not really. I mean a @SpringBean *construct*, like you can find in the Spring integration project. That project generates proxies for every @SpringBean annot found. These proxies are light and serializable, and internally hold a transient reference to the actual spring bean. When serialized, the spring bean instance is discarded; the proxy will locate it again when it is called. You said you can't use annotations, so that trick wouldn't go here for you. There used to be a project[1] (now only for 1.2.x) that used commons attributes[2] for the same purpose, but we're not maintaining it for 1.3 anymore (though it is stored as a wicket-stuff project now[3]). Alternatively, you can just locate the bean just in time. Are you sure you need to keep a reference to it in your component(s)? And consider that *if* you need a reference, it's probably per-request (so you'll want a new one when a new request starts). If that is true, you can just set the reference lazily (get it when you actually access it), and null it in the components onDetach method (override that method; it will be called when a request is handled) so that it won't be serialized. Eelco [1] http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-1.2.x/wicket-spring-annot [2] http://jakarta.apache.org/commons/attributes/ [3] https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-spring-cattr - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
It would be a simple thing to look up the bean in each method in the service locater as versus keeping a reference. However, this is not how the existing service locaters here have been coded and they've been clear about wanting the new stuff to mimic the old stuff. The best way to solve the issue would be to get rid of EJB altogather since the usage requirements of the project are pretty light but I'm not here to change the world (none of these arguments would be easy), just to get their project coded for them as per their requirements. They are going to be maintaining it so I suppose it's fair to code it exactly like the existing code. Eelco Hillenius wrote: Eelco, I realized that you are recommending using Spring or looking up the bean on the fly some other way but I am working for a place where Spring is not part of the approved stack and they have an established way that access to EJB's is coded. Not really. I mean a @SpringBean *construct*, like you can find in the Spring integration project. That project generates proxies for every @SpringBean annot found. These proxies are light and serializable, and internally hold a transient reference to the actual spring bean. When serialized, the spring bean instance is discarded; the proxy will locate it again when it is called. You said you can't use annotations, so that trick wouldn't go here for you. There used to be a project[1] (now only for 1.2.x) that used commons attributes[2] for the same purpose, but we're not maintaining it for 1.3 anymore (though it is stored as a wicket-stuff project now[3]). Alternatively, you can just locate the bean just in time. Are you sure you need to keep a reference to it in your component(s)? And consider that *if* you need a reference, it's probably per-request (so you'll want a new one when a new request starts). If that is true, you can just set the reference lazily (get it when you actually access it), and null it in the components onDetach method (override that method; it will be called when a request is handled) so that it won't be serialized. Eelco [1] http://svn.apache.org/repos/asf/incubator/wicket/branches/wicket-1.2.x/wicket-spring-annot [2] http://jakarta.apache.org/commons/attributes/ [3] https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-spring-cattr - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/Wicket-1.2.6-Development-mode-serialization-checks-and-remote-EJB%27s-tf3866878.html#a11011221 Sent from the Wicket - User mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Wicket 1.2.6 Development mode serialization checks and remote EJB's
i did understand you, if you can't do anything to the object that is generated is fine by me. But i still say, don't have it as a serializeable field in your pages that you can handle. Just lookup the EJB when you need it and cache it in a transient variable johan On 6/7/07, salmas [EMAIL PROTECTED] wrote: Thanks so much Eelco! Your reply is exactly what i was looking for! We are using JDK 1.4 so I cannot use annotations but the other thing would work. Johan, I don't think you understand what the unserializable object is. My remote EJB is serializable by definition. However, the object I am having issues is an internally generated rmi stub created by WebLogic. This object was not created by me, I have no control over it and should not even be aware of what the exact implementation of this stub is since this is all handled behind the scenes by WebLogic is but it became an issue because in debug mode wicket tries to serialize it. Eelco Hillenius wrote: It's not a case of an unknown reference causing the not serializable exception. I know which object is not serializable and it is the concrete proxy object created by WebLogic for my remote EJB. I ended up checking if I was in development mode and then using a transient variable and then using a another variable which is not transient when the app is running in a production environment. I was hesitant to simply mark the EJB as transient in case it caused issues in the production environment. Thanks all for your replies, they helped confirm that there wasn't a workaround other than marking it transient. But there is. You can turn the check off, even for development mode. See IDebugSettings#setSerializeSessionAttributes[1] What you probably want in the end though, is a construct like @SpringBean or just look the bean up right at the moment you need it without holding the reference. Eelco [1] http://wicket.sourceforge.net/apidocs/wicket/settings/IDebugSettings.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/Wicket-1.2.6-Development-mode-serialization-checks-and-remote-EJB%27s-tf3866878.html#a11010152 Sent from the Wicket - User mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
