hi,
I think this is much much deeper.
This is the basis for proper admin.
Being a 77'er i strongly see the need for the unified framework for
monitoring and statistics. It needs to be unified, 77 compliant (when I
know what that exactly means) etc etc.
So at this point it is more of a heads up, I am very pleased to see that
some of you are already taking the steps to monitor and put metrics on your
stacks, we will put them altogether at some future point,
Now, simone, referencing a mail on the mailing list is not going to cut it
and this feature won't be used, (guaranteed).
Post on jboss-doco and we will find a way to present that correctly with
tobias, but again I even do believe this is a full sub project (jboss
admin), mad andy still interested in admin?
regards
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
|Sent: Saturday, January 20, 2001 12:37 PM
|To: 'jBoss Developer'
|Subject: RE: [jBoss-Dev] JCTS thought was, Testing bean security with
|JUn it
|
|
|Hey Peter,
|
|talking about JBoss, there are already implemented 2 mechanism that let you
|know about cache activities. One is JMS based, the other JMX based. For
|further details see my posting in the archives with title "Monitoring
|capabilities in JBoss", and under dist/bin the 2 sample clients for that.
|You can also play with cache settings (set the max bean age = 1 second, in
|the client wait for 5 seconds, then the bean has been passivated).
|
|Said that about the cache, in general the idea of monitoring what JBoss is
|doing fits well with JMS, IMHO: every interceptor (or relevant plugins such
|as the cache) can post a JMS message about what is doing. So the security
|interceptor can do the job Alexander needs (checking security at method
|level) posting JMS messages, and so on.
|
|My 0.02$
|
|Best Regards,
|
|Simon
|
|> Alexander/All,
|>
|> During my course of developing Junit conformity tests
|> for JBOSS, I too have encountered issues such as you
|> are describing.
|>
|> For example, I would like to confirm that proper
|> callbacks on the container side are being called at
|> the appropriate time, many times without the explicit
|> involvement of the client. Let's say for instance I
|> wanted a stateful session bean to hang around until it
|> is passivated by the container, then activated. It
|> would be nice to confirm that the proper callbacks are
|> invoked by the container on the target bean. This can
|> be implicitly tested (does my bean have the same state
|> it did before passivation?) via the client evaluating
|> the beans state post passivation. But the zillion
|> dollar question: How does the client know his/her bean
|> has been passivated. Obviously, the client isn't
|> suppose to but this makes for difficult verification
|> of whether the appropriate callbacks are indeed
|> invoked...
|>
|> My thought and it might be a crazy one because it may
|> carry along with too much baggage is JavaSpaces. It
|> seems to fit the bill for this particular problem:
|>
|> - I want to decouple the two entities (client/bean)
|> - I want to have time independent processing (client
|> waits until an entry was placed in the space regarding
|> his beans passivation and takes appropriate action)
|> - Bean does not know about the client and there is no
|> coupling between them.
|> - A VERY minimal amount of code needs to be written to
|> make this "decoupled callback" work.
|> - It may open the door for some interesting
|> statistical analysis with minimally invasive code...?
|>
|> Thoughts?
|>
|> happy hacking,
|> peter
|>
|>
|> --- Alexander Klyubin <[EMAIL PROTECTED]>
|> wrote:
|> > Hi!
|> >
|> > Has somebody figured out how to test bean security
|> > on the client side with
|> > JUnit? My problem is that I want to test whether
|> > security works as it should
|> > for certain beans' methods (by the business rules).
|> > In case access is denied
|> > to client with particular roles/principal how do I
|> > know (in the client code)
|> > whether RemoteException is connected to security or
|> > to other problems? Can I
|> > somehow differentiate between these two types of
|> > remote exceptions caught on
|> > the client side without parsing exception text?
|> >
|> > Alexander Klyubin
|> >
|> >
|>
|>
|> __________________________________________________
|> Do You Yahoo!?
|> Yahoo! Auctions - Buy the things you want at great prices.
|> http://auctions.yahoo.com/
|>
|
