Ok got it,
you want to test the passivation reactivation server bit in jboss, the job
of the bean will be to validate teh state upon ejbActivate (:)
hum... you will need a specific plugin. Granted you will not test the cache
stuff since you will put your specific one in there.
There is another problem is that on the way out we would need to passivate,
I mean synchronously (stay in the thread to make sure it works) Right now
they will be different threads working on the passivation.
One way around this is to have the "test" thread wait and make sure the
server passivates. The way I did it in jboss1.0 was a LRU cache with 3
seconds delay and the client would wait 5 seconds.
Again you need a hardcoded plugin for cache to test the other parts of the
server on that behaviour (like the serialization de-serialization as you
say). The caches structures in jboss 2.0 are part of Project Game Over
todos.
The random passivation won't really help you there. Focus on something else
for now, I will try to make sure we do have a "hook" in the forthcoming
caches (like passivate upon release() or something like that... actually
that could be pretty simple.. hummmm)
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Braswell
> Sent: Thursday, June 29, 2000 10:10 AM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] EJB passivation/activation
>
>
> Jeremiah,
> You are correct. Passivation and Activation should
> not be directly influenced by bean people, nor am I
> proposing it should be.
>
> However from a testing standpoint I would like to be
> able to *persuade* beans to be passivated and then
> activated so I can verify that things such as their
> state, context and such are properly resurrected...
> all mandated by the spec. I also want to verify that
> the callbacks are being called properly... I'm sure
> they are :-)
>
> To do this, I would ideally want to state a minimum
> and maximum threshold in the xml file... "I want a
> minimum of 10 beans and a maximum of 100". In this
> scenario when the 101st client asks for a session
> bean, somebody gets passivated, usually this is the
> LRU guy but doesn't have to be, I don't really care
> who it is, just as long as somebody gets the bullet
> :-)
>
> So my question then, is there any threshold to the
> number of session beans a container will create or
> will the container happily create beans ad infinitum
> until system resources are depleted?
>
> I'm hesitant to put any hooks into the server that
> will make jboss behave in a "special way" just to
> facilitate testing. I'd prefer to test the system as
> though I was simply "Joe bean developer".
>
> cheers,
> peter
>
> --- Jeremiah Johnson <[EMAIL PROTECTED]> wrote:
> > I disagree that such is a missing feature. Could
> > you please elaborate - maybe I haven't come across a
> > scenario where it would be useful... I consider
> > activation and when to do it to be a specific
> > feature of the container and I don't want to think
> > about it as a bean developer, but that may be a bit
> > naive :)
> >
> > Peter, let me know if I understand correctly: you
> > are looking for a way to incorporate test hooks so
> > that you can verify adherence to the spec for
> > re-establishing the bean state when activated; as
> > opposed to a more general desire to be able to
> > programmatically activate or passivate a bean at any
> > time. If you are looking for the former, would it
> > be valid to create a specific InstanceCache
> > specifically for testing that would just passivate
> > after a certain condition (i.e. 10 seconds after
> > activated, immediately after activated...)?
> >
> > I spent a little time looking
> > org.jboss.ejb.plugins.RandomEntityInstanceCache to
> > see how it works. I think that my idea above would
> > be easy to implement if it is what you are looking
> > for.
> >
> > If anyone has worked on the bean caches before -
> > please correct if I am off-course...
> >
> > - jeremiah
> >
> > ------Original Message------
> > From: Adi Lev <[EMAIL PROTECTED]>
> > To: jBoss Developer
> > <[EMAIL PROTECTED]>
> > Sent: June 29, 2000 5:05:49 AM GMT
> > Subject: RE: [jBoss-Dev] EJB passivation/activation
> >
> >
> > I agree, This is a missing feature.
> >
> > There should be passivate and activate (or pause
> > resume) for the container
> > (the server)
> > You can now only do it by shuting down the server.
> >
> > This is an Admin request type and not a statndard
> > user client. In
> > implenation our Servers
> > we use pause resume which is similar in concept.
> >
> >
> > > -----Original Message-----
> > > From: Peter Braswell
> > [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, June 29, 2000 6:16 AM
> > > To: jBoss Developer
> > > Subject: RE: [jBoss-Dev] EJB
> > passivation/activation
> > >
> > > Marc,
> > > Not really concerned about passivating a
> > particular
> > > bean, I just want to set up a situation that will
> > > passivate ANY bean as opposed to a PARTICULAR
> > bean.
> > >
> > > I would imagine most containers use a LRU
> > approach, I
> > > just want to force passivation/activation and
> > verify
> > > the callbacks from the container. Each bean will
> > keep
> > > a rolling history of its own
> > activation/passivation
> > > which will become part of its state. The client
> > can
> > > then extract this history and verify that all the
> > > correct callbacks are being invoked by the
> > container
> > > on the bean in the correct order.
> > >
> > > cheers,
> > > peter
> > >
> > >
> > > --- marc fleury <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED]]On
> > Behalf
> > > > Of Peter Braswell
> > > > > Sent: Wednesday, June 28, 2000 2:43 PM
> > > > > To: jBoss Developer
> > > > > Subject: [jBoss-Dev] EJB
> > passivation/activation
> > > > >
> > > > >
> > > > > All,
> > > > > Whats the best way to force these to occur
> > give
> > > > the
> > > > > current construct of jboss?
> > > > >
> > > > > I suspect its to monkey around with the jboss
> > xml
> > > > file
> > > > > to specify minimum and maximum instances and
> > in
> > > > the
> > > > > client create a number of connections greater
> > than
> > > > the
> > > > > minimum specified in the xml. Am I on the
> > right
> > > > > track?
> > > > >
> > > > > Essentially I want a scheme to force
> > activation
> > > > and
> > > > > passivation.... :-)
> > > >
> > > > The plugin we have with AC is the random
> > passivation
> > > > one. I am not sure it
> > > > is controllable.
> > > >
> > > > marc
> > > >
> > > > >
> > > > > cheers,
> > > > > the JCTS guy (aka Peter)
> > > > >
> > > > >
> > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Get Yahoo! Mail - Free email you can access
> > from
> > > > anywhere!
> > > > > http://mail.yahoo.com/
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get Yahoo! Mail - Free email you can access from
> > anywhere!
> > > http://mail.yahoo.com/
> >
> > ______________________________________________
> > FREE Personalized Email at Mail.com
> > Sign up at http://www.mail.com/?sr=signup
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
>
>
