10:07 a.m.
Do we want to keep the functionality of changing meta data runtime?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255672
Carlo
6:06 p.m.
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.
--
Jason T. Greene
JBoss, a division of Red Hat
7 p.m.
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
7:12 p.m.
On Thu, 2009-09-17 at 19:00 +0200, Adrian Brock wrote:
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.
I also found this old link on the wiki:
http://www.jboss.org/community/wiki/JBossKernelMetaData
which I think dates back to his original prototype?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:52 p.m.
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
11:04 p.m.
Jason T. Greene wrote:
> 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
Sorry, for the truncated sentence. This should read:
However it could still be useful to allow developers to define some
global base defaults via annotations for the purpose of quick testing.
However the embedded project might end up offering a better solution to
this, since you will be able to programmatically define this all via a
DSL style API.
--
Jason T. Greene
JBoss, a division of Red Hat
9:23 a.m.
On 09/17/2009 11:04 PM, Jason T. Greene wrote:
Jason T. Greene wrote:
>> 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
>
Sorry, for the truncated sentence. This should read:
However it could still be useful to allow developers to define some
global base defaults via annotations for the purpose of quick testing.
However the embedded project might end up offering a better solution to
this, since you will be able to programmatically define this all via a
DSL style API.
Been there, done that. :-)
The jboss-metadata project was designed to be the unified domain model.
In the end it can't keep up, because we want to do hybrid models: throw
JPA2 into the mix for example.
The same goes for the DSL style API. Embedded can never keep up with the
different technologies. It would be more sensible to have the DSL style
API come from jboss-jpa project. There already lies the intersection of
JPA & VDF. It's matter of adding an intersection point there with the
Embedded DSL SPI.
Carlo
10:04 p.m.
Carlo de Wolf wrote:
On 09/17/2009 11:04 PM, Jason T. Greene wrote:
> Jason T. Greene wrote:
>
>>> 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
>>
> Sorry, for the truncated sentence. This should read:
>
> However it could still be useful to allow developers to define some
> global base defaults via annotations for the purpose of quick testing.
> However the embedded project might end up offering a better solution to
> this, since you will be able to programmatically define this all via a
> DSL style API.
>
>
Been there, done that. :-)
The jboss-metadata project was designed to be the unified domain model.
In the end it can't keep up, because we want to do hybrid models: throw
JPA2 into the mix for example.
The same goes for the DSL style API. Embedded can never keep up with the
different technologies. It would be more sensible to have the DSL style
API come from jboss-jpa project. There already lies the intersection of
JPA & VDF. It's matter of adding an intersection point there with the
Embedded DSL SPI.
The metadata project is really a collection of deployment metadata, it
is not a unified domain model like we have been planning, which is
focused on global server environmental elements.
In both cases the modularity of metadata is orthogonal to test specific
annocations vs DSL api. We can break it up however we like, but at the
end of the day we still have to ship 1 combination.
--
Jason T. Greene
JBoss, a division of Red Hat
5334
days inactive
5339
days old
jboss-development@lists.jboss.org
7 comments
3 participants
participants (3)
-
Adrian Brock -
Carlo de Wolf -
Jason T. Greene