[jboss-dev] Changing meta data runtime

[Adrian Brock]

No. This has nothing to do with annotations, it might be
in Carlo's use case, but that is only because he uses an
annotation for his specific piece of metadata.

It's about how to change metadata at runtime without redeploying.
Of course if the metadata is a deployment time only config then a
redeploy is required. 

Requiring the profile service to understand "pushing to the interceptor"
is not going to work, while putting it in one standard place (the mdr)
doesn't become an n^2 problem, i.e. the profile service having to
understand the internals of each subsystem that wants to
be able to do runtime changes to metadata.

But since nothing is really designed to use the MDR in this way, its not
really an issue. 

This feature was one of Bill's and Scott's ideas, e.g. being able to
have a default tx timeout at cluster, system, deployment, bean,
method level, but it was never really followed through.
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=58523
(I know there were earlier threads elsewhere in the forums or
the dev-list - just from Scott's first comment :-)

I don't know whether Scott (or Bill) still think this is a useful idea,
since the profile service currently uses "ManagedOperations" to
do things like changing cache sizes, etc. at runtime. 

P.S. I don't see why the EJB3 layer should be involved in MDR caching.
The MDR already has a variant that does caching and understands
how to invalidate a piece of metadata in that cache when somebody
modifies it at an abitrary level.

It's not enabled by default because (at least currently)
most metadata is only read once at deployment 
time making the caching part redundant and 
therefore extra needless work (not to mention a waste of memory).

On Thu, 2009-09-17 at 11:06 -0500, Jason T. Greene wrote:
> Carlo de Wolf wrote:
> > Do we want to keep the functionality of changing meta data runtime?
> > 
> > http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255672
> 
> While interesting, I don't think this feature is all that useful with 
> annotations. If an annotation refers to a programmatic concept (as most 
> annotations in EJB), then the deployment has to be redeployed anyway. 
> Also, the user still has to update the source to make it a long term 
> change. If the annotation refers to an actual administration 
> configuration concept (say security domain like in the test), then 
> specifying it by annotation is sketchy to begin with, and should just be 
> a default. The configuration for such a thing, being a capability an 
> admin controls, should have a very loose association (if at all) with an 
> annotation. They should not need to specify an annotation name to 
> control this, and it doesn't make a lot of sense for the code to read 
> such a config value via an annotation name either, as that interface is 
> overly constrained.
> 
> It seems a better way to support this would be to just provide a profile 
> service management method to change the domain, which is responsible for 
> pushing it to the security interceptor.
> 
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx