Hi Keith
>-----Original Message-----
>From: Keith L. Musser [mailto:[EMAIL PROTECTED]]
>Sent: 15 December 2000 03:29
>To: jBOSS-User
>Subject: [jBoss-User] enhancing the EJB model
>
>
>I would like to be able to do some work which, to the best of my
>understanding, is not supported directly in the EJB model. If the EJB
>model supports these things, can someone point me to the right part of
>the spec. If not, does anyone else think these capabilities would be
>useful?
The danger is if you do something not in the spec then it will probably not
be portable and could quite possibly be broken by a future
version of the spec.
Anyway...
>Here is what I'd like to be able to do:
>
>(1) Periodically invoke a method on a bean. I would specify the period
>and the security context (caller principal) for the call in the
>deployment descriptor.
>
>The only way I know how to do this now is to have a client which calls
>the bean's method periodically. I can do this from outside of JBoss, or
>(cheating) by starting a thread from the bean's class when the first
You can't do this. Manipulating threads in EJB-land is specifically
forbidden.
>instance is created (presumably that would be when an instance is
>created to use for the "home" interface). Once the thread is started,
>it runs forever, calling a method periodically. I also have to shut
>?down --perhaps when the last instance of the class is finalized.
>
>This would work, but I think it's not compliant with the EJB spec.
Not only is it not compliant, most appservers I know will check for it and
your code won't run.
What I would suggest is that you start a thread on the CLIENT and invoke a
stateless session bean which goes into an infinite loop, polling the bean
you want polled at a regular interval. You *must* keep a reference to it on
the client so that you can shut it down !
To be honest though, I would review what you are trying to achieve and see
if there is a better way.
>(2) I'd also like a "super-user" security context. By a "super-user"
>security context, I mean a security context in which the bean is able to
>change it's security association ("caller principal") programmatically
>for nested calls to other beans.
>
>That is, I'd like to do something like this...
>...
>ctx.setCallerPrincipal( new_principal );
>bean.callMethod();
>ctx.resetCallerPrincipal();
>...
>
>Of course, there's no "setCallerPrincipal" method in the EJBContext
>because normally that should not be allowed.
It's expressly forbidden you mean :-)
> I would want to allow it
>only if the current context is a "super-user" (which I leave undefined
>for now).
>
>This would be useful in my application because the logic in my beans
>depends heavily on user identity. (i.e. my entity beans define access
>controls based on "owner" and "group", like files in a filesystem,
>rather than based on "roles" as in the ordinary EJB security model.)
>
>Periodically I need to do work that may be on behalf of any user.
I think you're trying to solve the wrong problem.
EJB is really setup for roles based access.
The way we are handling the same issue is we have users who are assigned
roles (normal EJB). However if we need to handle access based on user rather
than role then we programme that into the bean (it is a business rule after
all so it seems reasonable). For example say a user is only allowed to look
at their own personell records then the relevant session bean would use
getCallerPrincipal() to get the username and then directly or indirectly use
that as a part of the query against the entities.
>Currently my work-around for these issues is to create a long-lived
>"client" application which sits outside of JBoss. It invokes methods
>periodically. And when necessary it changes it's security association
>to call another method. This "client" is, therefore, essential to the
>proper operation of my server.
Can you say "OUCH" ?
>Sure, I can run the client thread in the same JVM as JBoss. But that's
>missing the point. Wouldn't it be useful for the EJB model to handle
>things like this?
It doesn't need to really.
I think you're trying to solve the wrong problem. I think the problem may be
in your design.
Edward
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
