Re: [jboss-dev] Changing meta data runtime
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