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 PROT
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 iss
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 workin
> 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 *construc
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
exa
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
> 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 us
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
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
> 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
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 d
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, Th
12 matches
Mail list logo
