From: Scott M S. <sco...@jb...> - 2005-11-19 19:19:41
|
So I have an update to the java:comp/env implementation that: 1. Replaces the thread context class loader based ENCFactory with the ThreadLocalENCFactory from ejb3 (moved to naming module). 2. Updates the ejb2.x and web containers to use this for the java:comp/env context. 3. Updates the ejb2.x and web containers to expose the java:comp/env context ad read-only using the org.jboss.util.naming.ReadOnlyContext util. 4. Updates the JndiView service to be able to list both war and ejb java:comp/env contexts. Issues: 1. The read-only contexts may break existing apps/integration code trying to augment the component contexts. 2. ejb3 has its own implementation. Probably not a huge deal as the enc is a component local notion, but it needs to be accessible from management tools such as JndiView. 3. This is only a subset of the runtime component metadata that should be available to aspects. Another example is the deployment local property editors. We need a cohesive view in the new mc/jboss5. The issue is thinking about how we evolve jboss-4.0.x to allow for the newer stacks without breaking legacy uses. The real question/point of this message is, what is the next step in runtime metadata abstraction that allows us to move both 4.0.x and 5.0.x forward with support for these features such that is not a support and maintence nightmare as the mc comes online. A solid, hierarchical metadata framework is needed. It needs to merge the disperate legacy view, aop, ejb3, mc and webservices usecases. |
From: Adrian B. <adr...@jb...> - 2005-11-19 19:46:14
|
On Sat, 2005-11-19 at 14:17, Scott M Stark wrote: > The real question/point of this message is, what is the next step in > runtime metadata abstraction that allows us to move both 4.0.x and 5.0.x > forward with support for these features such that is not a support and > maintence nightmare as the mc comes online. My question would be where does the old model leak into the public api/spi such that it is difficult to change? I think my feelings are well known? With people exposing all sorts of implementation and integration details making things less easy to change. Even across modules in the same release, let alone modules across different versions. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-19 20:13:19
|
Adrian Brock wrote: > On Sat, 2005-11-19 at 14:17, Scott M Stark wrote: >> The real question/point of this message is, what is the next step in >> runtime metadata abstraction that allows us to move both 4.0.x and 5.0.x >> forward with support for these features such that is not a support and >> maintence nightmare as the mc comes online. > > My question would be where does the old model leak into the > public api/spi such that it is difficult to change? > > I think my feelings are well known? > With people exposing all sorts of implementation and integration details > making things less easy to change. Even across modules in the > same release, let alone modules across different versions. This is the point. First, what basis for a unified view of the metadata and management exists today such that an abstraction can be put in place for aspects and other services that should be separable from implementation details. Given that, how can this be introduced into the legacy server. |
From: Adrian B. <adr...@jb...> - 2005-11-19 20:50:29
|
On Sat, 2005-11-19 at 15:11, Scott M Stark wrote: > This is the point. First, what basis for a unified view of the metadata > and management exists today It only really exists in aop land. The final solution is largely based on Bill's aop metadata, except with improved deployment and type safety (mentioned on a different thread). The improved deployment is to have a repository where deployers can establish component/application/server level metadata and assign pojos/services to those levels such that * invocations on these components have the correct metadata context * decorators like management can retrieve the context/metadata I would prototype it, but I only have so many cycles. :-) -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-19 21:05:35
|
Adrian Brock wrote: > On Sat, 2005-11-19 at 15:11, Scott M Stark wrote: >> This is the point. First, what basis for a unified view of the metadata >> and management exists today > > It only really exists in aop land. > > The final solution is largely based on Bill's aop metadata, except with > improved deployment and type safety (mentioned on a different thread). > > The improved deployment is to have a repository where deployers > can establish component/application/server level metadata > and assign pojos/services to those levels such that > * invocations on these components have the correct metadata context > * decorators like management can retrieve the context/metadata > > I would prototype it, but I only have so many cycles. :-) I want to push these integration issues forward, so I'll do it. This is why brought it up and added the enc as yet another runtime state that needs to be better handled as a means for prioritizing what gets done for jboss5/mc. |
From: Scott M S. <sco...@jb...> - 2005-11-20 19:29:41
|
In looking at the org.jboss.ws.metadata and org.jboss.aop.metadata: Good ws abstractions: - A MetaDataBuilder notion that abstracts out the source of the data. - Well typed pojo view of the metadata - An ability to export the pojo model to a "source". Bad ws abstractions: - No interfaces to help decouple implementation. - Usage of a URLClassLoader which may not exist. This is introducing an implementation dependency that we already have plans to get rid of. - Coupled to webservice data types. It looks like another MetaDataBuilder layered on top of the more generic abstraction could be used to incorporate overrides and non-deployment sources of metadata. - Use of the DeploymentInfo even at the AbstractMetaDataBuilder level. Good aop abstractions: - A MetaDataLoader notion that abstracts out the source of the data. - A simple metadata resolution/lookup notion. Bad aop abstractions: - The only loader interface class is coupled to class level metadata with xml overrides. Other sources of data only have class definitions and still have an aop specific interface for describing the metadata (fields, classes, methods). - The metadata resolution notion is coupled to an org.jboss.aop.joinpoint.Invocation as a required key. Having to start resolution at a thread/request level is too low of a scope, and the Where is the "improved deployment and type safety" thread? The abstractions that need to exist are: - A pojo metadata model with a loader abstraction that isolates the source of the metadata from the pojo model. The loader needs a notion of scope. - A metadata resolution service that supports a hierarchical linking of the pojo metadata model from the various scopes (thread, request, session, app/deployment, server, cluster/domain). Aspects should be able to interact with thread/request level metadata to introduce/override this. - A mapping to the profile service abstraction that allows for management tools, installers to introduce metdata via deployment level and higher loader abstractions. Adrian Brock wrote: > On Sat, 2005-11-19 at 15:11, Scott M Stark wrote: >> This is the point. First, what basis for a unified view of the metadata >> and management exists today > > It only really exists in aop land. > > The final solution is largely based on Bill's aop metadata, except with > improved deployment and type safety (mentioned on a different thread). > > The improved deployment is to have a repository where deployers > can establish component/application/server level metadata > and assign pojos/services to those levels such that > * invocations on these components have the correct metadata context > * decorators like management can retrieve the context/metadata > > I would prototype it, but I only have so many cycles. :-) |
From: Scott M S. <sco...@jb...> - 2005-11-20 21:30:04
|
A whiteboardish description of the metadata service. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelMetaData |
From: Scott M S. <sco...@jb...> - 2005-11-21 00:30:15
|
Another usecase that requires a query capability in the metadata service is reimplementing the JNDIView utility service. Today JNDIView uses implementation detail level knowledge that is a combination of the jmx ObjectName pattern + understanding what the ObjectName points to in order to obtain the component java:comp jndi context. With the web thread local enc exercise, another coupling between the JNDIView service and web container was needed. This was another ObjectName query and mbean type. To generalize this to avoid the implementation details showing up in the JNDIView service, there has to be some query capability in the metadata naming service along with some normalization of the containers registering the enc Context with the metadata service. Scott M Stark wrote: > A whiteboardish description of the metadata service. > > http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelMetaData |
From: Adrian B. <adr...@jb...> - 2005-11-21 15:20:01
|
On Sun, 2005-11-20 at 14:29, Scott M Stark wrote: > Where is the "improved deployment and type safety" thread? >From last Thursday on the "retroweaver" thread: (link to the JBoss Cache "Options" development: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71609) "On Thu, 2005-11-17 at 10:30, Bill Burke wrote: > > The annotations work requires some form of mapping, e.g. > > clazz.getAnnotations() -> AnnotationRepository.getAnnotations(clazz); > > and generation of annotation implementation classes from the > > "interface". > > > > Bill has also already done some work on annotations (based off javadoc > > tags). But I don't believe it is compatible with java5 annotations > > (e.g. serialization) > > > > Serialization? Anonotations are not serialized. AnnotationC is the > same exact format as JDK 5.0 annotations except it doesn't support > default values. If you remember, we talked in Boston about allowing people to provide invocation overrides using annotations, or more specifically the requirement was to use typed metadata. Annotations are the obvious way to do this. Whether this actually transports an annotation object over the network is a different issue, which you said you would investigate. :-) http://www.jboss.org/index.html?module=bb&op=viewtopic&t=59860 e.g. Psuedo code: client side TransactionTimeout timeout = MetaData.createMetaData(TransactionTimeout.class); timeout.setTimeout(100); MetaData.setThreadMetaData(timeout); // do stuff server side TransactionDemaractionAspect::invoke(Invocation invocation) { TransactionTimeout timeout = invocation.getMetaData(TransactionTimeout.class); // use it } " -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Adrian B. <adr...@jb...> - 2005-11-21 15:42:51
|
On Sun, 2005-11-20 at 14:29, Scott M Stark wrote: > - A pojo metadata model with a loader abstraction that isolates the > source of the metadata from the pojo model. The loader needs a notion of > scope. > - A metadata resolution service that supports a hierarchical linking of > the pojo metadata model from the various scopes (thread, request, > session, app/deployment, server, cluster/domain). Aspects should be able > to interact with thread/request level metadata to introduce/override this. > - A mapping to the profile service abstraction that allows for > management tools, installers to introduce metdata via deployment level > and higher loader abstractions. Can you explain this what you mean by a loader abstraction and a mapping to the profiler service? The way I envisaged it is was that the "metadata repository" is a very simple service that would have configuration pushed to it IOC style. Each pojo/service would then be linked to a point in the repository's tree (maybe creating an empty node if it does not already exist). Any other processing would be built upon these simple primitives, mostly using decorators. e.g. This POJO needs an ENC so enhance the POJO with the ENC decorator which has a link to its instance point in the metadata repository tree, containing information about how to construct that ENC. The implementation of the ENC decorator can then choose to do what what it likes (based on native environment) including registering itself with JNDIView or whatever at "POJO start". NOTE: This is not quite the same thing as the deployment aspects but it is related. What the deployment aspect does to "load" the repository is irrelevant to the repository itself. Metadata Repository: effectively a database Deployment aspect: responsbile for populating the database and linking components to relevant points. The simplest deployment aspect is to "handcode" it using MC config alongside the bean deployment. Pseudo config: <bean name="Metadata"> <install bean="Repository" method="installApplicationMetaData"> <parameter>MyApplication</parameter> </install> <bean> <bean name="MyBean"> <annotation name="org.jboss.Application">MyApplication</annotation> </bean> NOTE: This metadata link not only provides a reference into the metadata repository but it can also be used to place the pojo/service in the jsr77 tree (if it has that decorator :-). -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Adrian B. <adr...@jb...> - 2005-11-21 16:02:52
|
On Mon, 2005-11-21 at 10:42, Adrian Brock wrote: > Any other processing would be built upon these simple primitives, > mostly using decorators. For those that are not following the discussions in the MC forum, a "decorator" (named after the GOF pattern) http://c2.com/cgi/wiki?DecoratorPattern is an "aop introduction" that acts during the object's MC lifecyle with access to the contextual metadata to provide additional cross cutting behaviour. Phew! :-) I quote "introduction" because unlike an introduction, it can also act on the main pojo methods, e.g. setting the context classloader during invocations on that pojo. More concrete examples: JNDI binding: <bean name="Whatever"> <annotation name="org.jboss.jndi.Binding">java:/whatever</annotation> </bean> JMX: <bean name="Whatever"> <annotation name="org.jboss.jmx.MBean"> <attribute name="managementInterface">com.acme.WhateverMBean</attribute> </annotation> </bean> -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-21 19:14:52
|
> Can you explain this what you mean by a loader abstraction and > a mapping to the profiler service? > > The way I envisaged it is was that the "metadata repository" is a very > simple service that would have configuration pushed to it IOC style. > Its the metadata producer interface spi for the "metadata repository" service. I have a disconnect on how this can be done via simply pushing config data into it as there are too many constraints on the pushed data in order for there to be a consistent consumer view. I'll revisit this below after your ENC example. > Each pojo/service would then be linked to a point in the repository's > tree (maybe creating an empty node if it does not already exist). > Yes, but this is the consumer side, not the producer. > Any other processing would be built upon these simple primitives, > mostly using decorators. > > e.g. This POJO needs an ENC so enhance the POJO with the ENC decorator > which has a link to its instance point in the metadata repository > tree, containing information about how to construct that ENC. > > The implementation of the ENC decorator can then choose to do what > what it likes (based on native environment) including registering itself > with JNDIView or whatever at "POJO start". > > NOTE: This is not quite the same thing as the deployment aspects > but it is related. What the deployment aspect does to "load" the > repository is irrelevant to the repository itself. > > Metadata Repository: effectively a database > Deployment aspect: responsbile for populating the database and linking > components to relevant points. > > The simplest deployment aspect is to "handcode" it using MC config > alongside the bean deployment. > > Pseudo config: > > <bean name="Metadata"> > <install bean="Repository" method="installApplicationMetaData"> > <parameter>MyApplication</parameter> > </install> > <bean> > > <bean name="MyBean"> > <annotation name="org.jboss.Application">MyApplication</annotation> > </bean> > > NOTE: This metadata link not only provides a reference into the metadata > repository but it can also be used to place the pojo/service > in the jsr77 tree (if it has that decorator :-). So while I agree that this is a valid abstraction, its too abstract. Looking at the configuration I have no idea that there is an "ENC pattern" for which I can write a decorator to build a service like JNDIView. In the absence of any pattern which categorizes like metadata, the JNDIView decorator will simply be the externalization of the implementation details that happen today be hardcoded into the JNDIView. That is an improvement, but I think we need to go further in terms of being able to "discover" which common metadata patterns like an ENC exist so that for M patterns there are not M decorates that internally have N bindings to the N services that somehow conform to the pattern. My minimal view of a simple metadata repository service is a hierarchical attributed namespace (JNDI, XML, ObjectName somewhat) that has a query capability (XQuery I guess is the natural match, provided it can be implemented without a DOM implementation), so that there is a mechanism for classifying metadata such that similar patterns can be discovered. So back to the metadata loader abstraction, the two things I'm looking to impose on pushing data into the repository are the namespace, and a scope. For a given piece of metadata identified by a name, there are multiple values (the scopes). |
From: Adrian B. <adr...@jb...> - 2005-11-21 19:40:52
|
On Mon, 2005-11-21 at 14:14, Scott M Stark wrote: > > Can you explain this what you mean by a loader abstraction and > > a mapping to the profiler service? > > > > The way I envisaged it is was that the "metadata repository" is a very > > simple service that would have configuration pushed to it IOC style. > > > Its the metadata producer interface spi for the "metadata repository" > service. I have a disconnect on how this can be done via simply pushing > config data into it as there are too many constraints on the pushed data > in order for there to be a consistent consumer view. I'll revisit this > below after your ENC example. Are you talking about the invocation/thread/transaction override metadata on top of the repository? -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Adrian B. <adr...@jb...> - 2005-11-21 19:48:31
|
On Mon, 2005-11-21 at 14:14, Scott M Stark wrote: > So while I agree that this is a valid abstraction, its too abstract. > Looking at the configuration I have no idea that there is an "ENC > pattern" for which I can write a decorator to build a service like > JNDIView. In the absence of any pattern which categorizes like metadata, > the JNDIView decorator will simply be the externalization of the > implementation details that happen today be hardcoded into the JNDIView. > That is an improvement, but I think we need to go further in terms of > being able to "discover" which common metadata patterns like an ENC > exist so that for M patterns there are not M decorates that internally > have N bindings to the N services that somehow conform to the pattern. > I think you need to use concrete examples. *Your comment* is too abstract :-) What you said is not correct. There is no like metadata or multiple patterns. The pattern is in the decorator and it injects a standard piece of metadata into JNDIView. There is no pulling or discovery here. The only thing that requires any mutliples (short of the user actually requesting different behaviour in different places :-) is the mapping of deployment type specific metadata to our own model. ejb-jar.xml -> ENCMetaData web.xml -> ENCMetaData > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > JBoss-Development mailing list > JBo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-development -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Adrian B. <adr...@jb...> - 2005-11-21 19:58:05
|
On Mon, 2005-11-21 at 14:14, Scott M Stark wrote: > My minimal view of a simple metadata repository service is a > hierarchical attributed namespace (JNDI, XML, ObjectName somewhat) Ok. But it should be component/application/server, etc. > that > has a query capability (XQuery I guess is the natural match, provided it > can be implemented without a DOM implementation), so that there is a > mechanism for classifying metadata such that similar patterns can be > discovered. No. The mapping is done at deployment. I don't want some something like the current JSR77 implementation i.e. some monolithic piece of code trying to deal with all the services and heavily tied to implementation details. It would be a bit like trying to build the MBeanServer based on what we know about the current JBoss MBeans and writing the MBeanInfos in the JBossMX codebase. The service needs to be self describing using a standard format. Only something close to the service itself can know how it should be exposed in particular ways with the metadata of the service itself controlling whether it actually happens/makes sense. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Adrian B. <adr...@jb...> - 2005-11-21 20:09:02
|
On Mon, 2005-11-21 at 14:57, Adrian Brock wrote: > On Mon, 2005-11-21 at 14:14, Scott M Stark wrote: > > My minimal view of a simple metadata repository service is a > > hierarchical attributed namespace (JNDI, XML, ObjectName somewhat) > > Ok. But it should be component/application/server, etc. > > > that > > has a query capability (XQuery I guess is the natural match, provided it > > can be implemented without a DOM implementation), so that there is a > > mechanism for classifying metadata such that similar patterns can be > > discovered. > > No. The mapping is done at deployment. > > I don't want some something like the current JSR77 implementation > i.e. some monolithic piece of code trying to deal with all the services > and heavily tied to implementation details. > > It would be a bit like trying to build the MBeanServer based on > what we know about the current JBoss MBeans and writing the MBeanInfos > in the JBossMX codebase. > > The service needs to be self describing using a standard format. > > Only something close to the service itself can know how it should > be exposed in particular ways with the metadata of the service > itself controlling whether it actually happens/makes sense. By this last comment I don't mean a decorator per type of service I mean the deployer choosing whether the deployment has an ENC and what it is from its own deployment descriptor. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-21 21:04:21
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Ok, this is getting to the common ground of how do I avoid writing the JNDIView decorator multiple times, the main thing I'm looking for. So your saying that something like this is needed, not a namespace convention?<br> <br> <bean name="JNDIViewDecorator" ... /><br> <br> <bean name="container1"><br> <export source="ENCProperty" target="JNDIViewDecorator">... detail on how a multi-valued property is injected to the JNDIViewDecorator</export><br> </bean><br> <br> <bean name="container2"><br> <export source="MyENC" target="JNDIViewDecorator">... detail on how a multi-valued property is injected to the JNDIViewDecorator</export><br> </bean><br> ...<br> <br> Adrian Brock wrote: <blockquote cite="mid1132603701.3254.94.camel@htimes2" type="cite"> <pre wrap="">On Mon, 2005-11-21 at 14:57, Adrian Brock wrote: </pre> <blockquote type="cite"> <pre wrap=""> Only something close to the service itself can know how it should be exposed in particular ways with the metadata of the service itself controlling whether it actually happens/makes sense. </pre> </blockquote> <pre wrap=""><!----> By this last comment I don't mean a decorator per type of service I mean the deployer choosing whether the deployment has an ENC and what it is from its own deployment descriptor. </pre> </blockquote> <br> </body> </html> |
From: Adrian B. <adr...@jb...> - 2005-11-21 21:27:18
|
On Mon, 2005-11-21 at 16:04, Scott M Stark wrote: > Ok, this is getting to the common ground of how do I avoid writing the > JNDIView decorator multiple times, the main thing I'm looking for. So > your saying that something like this is needed, not a namespace > convention? > Not quite I would have it like this (who, where, what, why, when): <!-- What to do and when --> <bean name="JNDIViewDecorator" ... /> <!-- Where the decorator applies - cross cutting binding --> <bean name="JNDIViewDecoratorBinding" ... > <!-- AOP binding based on annotation --> </bean> <!-- What it is and where it goes --> <bean name="Container1ENC"> <!-- Definition of ENC --> <!-- Where it goes in the repository --> </bean> <!-- Who uses it --> <bean name="Container1"> <!-- ENC annotation --> <!-- Link to context in the repository (used by many decorators) --> </bean> Also, don't forget that these can apply to the old MBeans when I've integrated the KernelController and the ServiceController. I called it "install" rather than "export". There are other notions of installation that need to be driven from the service. e.g. adding a queue to the destintation manager -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-21 22:53:07
|
Ok, let's keep drilling. First, I view the configuration you show as too much of an inside out view of the container. Maybe its just an irrelevant composition choice in terms of the real point of this discussion, but I don't want the actual Container1ENC bean in either the kernel registry or metadata registry. I only want the ReadOnlyContext facade available for injection: <!-- Who uses it --> <bean name="Container1"> <!-- What it is --> <property name="Container1ENC"> <bean> <!-- Definition of ENC --> </bean> </property> <!-- ENC annotation --> <!-- Link to context in the repository (used by many decorators)--> </bean> How would I express "Where the ReadOnlyContext view of Container1ENC go in the repository" concern? This is also more in line with how existing MBeans would have to be dealt with in terms of mapping an attribute to the JNDIViewDecorator. In terms of the metadata registry point of this discussion, the form/features of the namespace are irrelevant from this perspective as the JNDIViewDecorator is just told the name to use. I was looking at the JNDIViewDecorator from the perspective that its a single component that would be configured in the JNDIView deployment. It would either have every ENC registry name specified, or a pattern that allowed for these names to be queried. The pattern usecase is not relevant to this discussion any longer, but I do think its a useful capability to consider as a requirement for some abstraction of the metadata repository. Adrian Brock wrote: > On Mon, 2005-11-21 at 16:04, Scott M Stark wrote: >> Ok, this is getting to the common ground of how do I avoid writing the >> JNDIView decorator multiple times, the main thing I'm looking for. So >> your saying that something like this is needed, not a namespace >> convention? >> > > Not quite I would have it like this (who, where, what, why, when): > > <!-- What to do and when --> > <bean name="JNDIViewDecorator" ... /> > > <!-- Where the decorator applies - cross cutting binding --> > <bean name="JNDIViewDecoratorBinding" ... > > <!-- AOP binding based on annotation --> > </bean> > > <!-- What it is and where it goes --> > <bean name="Container1ENC"> > <!-- Definition of ENC --> > <!-- Where it goes in the repository --> > </bean> > > <!-- Who uses it --> > <bean name="Container1"> > <!-- ENC annotation --> > <!-- Link to context in the repository (used by many decorators) --> > </bean> > > Also, don't forget that these can apply to the old MBeans > when I've integrated the KernelController and the ServiceController. > > I called it "install" rather than "export". > There are other notions of installation that need to be driven > from the service. e.g. adding a queue to the destintation manager > |
From: Adrian B. <adr...@jb...> - 2005-11-21 23:08:35
|
On Mon, 2005-11-21 at 17:52, Scott M Stark wrote: > Ok, let's keep drilling. First, I view the configuration you show as too > much of an inside out view of the container. Maybe its just an > irrelevant composition choice in terms of the real point of this > discussion, but I don't want the actual Container1ENC bean in either the > kernel registry or metadata registry. I only want the ReadOnlyContext > facade available for injection: > > <!-- Who uses it --> > <bean name="Container1"> > <!-- What it is --> > <property name="Container1ENC"> > <bean> > <!-- Definition of ENC --> > </bean> > </property> > > <!-- ENC annotation --> > <!-- Link to context in the repository (used by many decorators)--> > </bean> > > How would I express "Where the ReadOnlyContext view of Container1ENC go > in the repository" concern? I don't support anonymous beans yet and/or beans as values. :-( This just means all your beans are top level with an explicit name, there is no loss of functionality. In anycase, you are correct. I had anticipated your question with this usecase. For ejbs there is one per component. For wars there is one per application (shared across servlets). This is why you need a separate notion of ENC. I'd view anything that is truly a cross cutting concern to be a separate concept. Why restrict ourselves to the "compositional" choices made by the J2EE spec? e.g. Why not allow an ENC shared across all ejbs in a deployment? Or maybe you construct the ENC and ejb containers "programatically" with whatever topology you want. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-21 23:14:56
|
Sure, just as long as composition is a choice one can make. > > I don't support anonymous beans yet and/or beans as values. :-( > This just means all your beans are top level with an explicit name, > there is no loss of functionality. > > In anycase, you are correct. I had anticipated your question > with this usecase. > > For ejbs there is one per component. > For wars there is one per application (shared across servlets). > This is why you need a separate notion of ENC. > > I'd view anything that is truly a cross cutting concern to be > a separate concept. Why restrict ourselves to the > "compositional" choices made by the J2EE spec? > > e.g. Why not allow an ENC shared across all ejbs in a deployment? > Or maybe you construct the ENC and ejb containers "programatically" > with whatever topology you want. > |
From: Adrian B. <adr...@jb...> - 2005-11-21 23:13:26
|
On Mon, 2005-11-21 at 17:52, Scott M Stark wrote: > I was looking at the JNDIViewDecorator from the perspective that its a > single component that would be configured in the JNDIView deployment. It > would either have every ENC registry name specified, or a pattern that > allowed for these names to be queried. You can do that. The decorator and the cross cutting binding go in the same deployment as JNDIView. If that deployment isn't done then nothing happens. There is nothing to process the annotation on the services. There is still the problem we talked about in the forums about what happens if you deploy JNDIView with its binding *after* a service with the annotation. Currently AOP keeps track of this for class level bindings and will "hot deploy". But it doesn't keep track of instance level bindings. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Bill B. <bi...@jb...> - 2005-11-22 13:20:17
|
Adrian Brock wrote: > On Mon, 2005-11-21 at 17:52, Scott M Stark wrote: > >>I was looking at the JNDIViewDecorator from the perspective that its a >>single component that would be configured in the JNDIView deployment. It >>would either have every ENC registry name specified, or a pattern that >>allowed for these names to be queried. > > > You can do that. The decorator and the cross cutting binding go > in the same deployment as JNDIView. > > If that deployment isn't done then nothing happens. There is nothing > to process the annotation on the services. > > There is still the problem we talked about in the forums about > what happens if you deploy JNDIView with its binding *after* > a service with the annotation. > > Currently AOP keeps track of this for class level bindings > and will "hot deploy". > But it doesn't keep track of instance level bindings. FYI, Kabir has implemented in 2.0 the same "rich" set of metadata that you have for classes for instances as well. So, you just need the MC to populate it. -- Bill Burke Chief Architect JBoss Inc. |
From: Adrian B. <adr...@jb...> - 2005-11-21 23:29:12
|
On Mon, 2005-11-21 at 17:52, Scott M Stark wrote: > The pattern usecase is not relevant to this discussion any longer, but I do think its a useful > capability to consider as a requirement for some abstraction of the > metadata repository. Obviously there needs to be some query mechanism, even if it just for management/diagnostic purposes. But, I have a feeling that such a pull mechanism would be abused. :-) "I'll just do this quick and dirty and fix it properly later...". But I can think of some use cases (which I want to support in the MC directly as well) where you have monomorphic behaviour without requiring people to be explicit. e.g. When I deploy a JMS MDB, it should know which rar provides the jca 1.5 inflow - there is only one. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
From: Scott M S. <sco...@jb...> - 2005-11-21 20:58:41
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> So explain what the self-describing standard format is? I'm not advocating that the metadata service actually care about how its used, only that its abstraction is something more than a HashMap.<br> <br> In terms of a concrete example, let's stick with the ENC because it illustrates where I see an ambiguity in terms of how this is expressed as metadata available for other decorators.<br> <br> 1. A j2ee component container has a notion of an ENC. <br> 2. Abstraction level 1 is that a container chooses to make the ENC available for use by aspects. The container has to conform to some minimum requirement for the mc to view the container for being a bean source.<br> 3. Abstraction level 2 is related to the question, can there be a reusable JNDIView decorator that makes the ENC available. This is where I am disconnecting from you.<br> <br> You seem to be arguing that the JNDIView decorator is necessarily a bridge between the service and the JNDIView, and has to be rewritten for every service. I am arguing that step 2 is done with this decorator usecase in mind such that I can write the JNDIView decorator once. The coupling between these is the a sufficiently consistent usage of the namespace used to register the metadata. This cannot be a requirement as it is today for the jsr77 hacking, that much I agree on. Really what I'm arguing for is that its possible to have some support for this naming convention usecase at some level of abstraction in the metadata repository. If you argree with this characterization of the problem, we can start another forum thread on what the correct abstraction of the metdata repository service is. If not, what is needed to get to that point?<br> <br> Adrian Brock wrote:<br> <blockquote cite="mid1132603056.3251.91.camel@htimes2" type="cite"> <pre wrap=""><!----> No. The mapping is done at deployment. I don't want some something like the current JSR77 implementation i.e. some monolithic piece of code trying to deal with all the services and heavily tied to implementation details. It would be a bit like trying to build the MBeanServer based on what we know about the current JBoss MBeans and writing the MBeanInfos in the JBossMX codebase. The service needs to be self describing using a standard format. Only something close to the service itself can know how it should be exposed in particular ways with the metadata of the service itself controlling whether it actually happens/makes sense. </pre> </blockquote> <br> </body> </html> |