[jboss-dev] Changing meta data runtime

[Jason T. Greene]

Adrian Brock wrote:
> 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.

Right, I was speaking to the ejb use-case which using annotation names 
as the index to general administration configuration.

> 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.

I should have been clearer, I didn't mean we should change the profile 
service at all for this. I mean that the EJB3 code (if it wants to 
support this) should provide a managed object that is published via the 
profile service (setSecurityDomain property).

> 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. 

Well, I think the unified domain model stuff we are moving to somewhat 
conflicts with this notion. However, it could

> 
> 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).

Right that's really the issue with caching at the MDR level, it's at too 
low of a level to determine if something should be cached. There really 
is no reason for EJB3 to continually reread the same values, but 
according to Carlo that's a side-effect of the current EJB3 design (and 
it's interaction with AOP), so it was easier to front the mdr for just 
the ejb related calls with a basic cache. Hopefully this work around can 
be eliminated in 6.

-- 
Jason T. Greene
JBoss, a division of Red Hat