August 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by adrian＠jboss.org

anonymous wrote : | Question: Is there any benefit to the Profile Service and/or management tools from the name="xxx" attribute on the ServiceBinding beans? If they can be anonymous, configuration will be simpler. | As far as the profile service is concerned, it is upto the ServiceBindingManager to provide a ManagedObject to the profile service that allows any management console to understand how to configure it. This should include properties or ManagedObjects that let you configure the store/configuration file as well. The only reason to give a special name would be so a management console can identify it and give it some extra prominance or categorization, but that only needs to be done on the ManagedObject. The implementation details of the POJO should largely be hidden. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169053#4169053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169053

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by adrian＠jboss.org

anonymous wrote : | Design Question: This inclusion of service binding in the bootstrap isn't strictly necessary, just how I've approached it so far. I did it that way because a) the service does have to be loaded early, before stuff in conf/jboss-service.xml that needs binding configuration and b) the binding configuration file is pretty long and complex and IMHO should be in its own file. The bootstrap mechanism was a quick-and-dirty way to get that file parsed and loaded into the MC. | The issue here is that we have no conf/jboss-beans.xml equivalent other than the bootstrap files. In practice this bootstrap stage of the profile service should disappear once all the mbeans have been moved out of conf/jboss-service.xml The ServiceBindingManager would then live in deploy and automatically get deployed in order correctly based on MC dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169051#4169051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169051

17 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: JBAS-5673 - Metadata processing

by emuckenhuber

So now to the actual topic of https://jira.jboss.org/jira/browse/JBAS-5673 :) anonymous wrote : | remove the duplicate processing of annotations happening in the web container TomcatInjectionContainer. So we should be able to definitely drop those things in the TomcatInjectionContainer: | private void processServlets(JBossServletsMetaData servlets, ClassLoader webLoader) | private void processListeners(List<ListenerMetaData> listeners, ClassLoader webLoader) | private void processFilters(FiltersMetaData filters, ClassLoader webLoader) | private void processClass(String className, ClassLoader webLoader) | as those information have already been populated. Ignoring dynamic jsp beans, etc. for now it would lead to a processAnnotations like: | public void processAnnotations(Object object) | { | // Get injectors for class | Map<AccessibleObject, Injector> injectors = encInjections.get(object.getClass().getName()); | | // TODO dynamic beans, etc. | | if (injectors == null || injectors.size() == 0) return; | for (Injector injector : injectors.values()) | { | injector.inject(object); | } | } | Beside the fact that we could split the processAnnotations in doTheKnownInjection(Object) and processAnnotations(Object dynamicBean), there are still some things not really clear: | Map<AccessibleObject, Injector> injectors = encInjections.get(className); | | // instead of | | Map<AccessibleObject, Injector> injectors = resolvedClassInjections.get(object.getClass().getName()); | which would makes sense, as we don't use the resolvedClassInjections anymore (see processClass) and encInjections is actually already populated by the InjectionHandlers. But e.g. the UserTransaction is handled differently in WebResourceHandler: | public class WebResourceHandler implements InjectionHandler | { | // ... | loadXmlResourceEnvRefs(InjectionContainer container, Collection refs) | { | | else if (resType.equals(UserTransaction.class)) | { | | if(envRef.getInjectionTargets() != null) | { | createInjectors(container.getInjectors(), getClassloader(), factory, getInjectionTargets()); | continue; | } | // .... | } | | // Where the container.getInjectors() is: | | // EncInjectors/Handlers may need to add extra instance injectors | public List<Injector> getInjectors() | { | return new ArrayList<Injector>(); // no equivalent in WAR | } | Assuming that the processAnnotations should be like that, we would need to add those injectors also to the EncInjections and so smth like: | createInjectors(container.getEncInjections(), getClassloader(), factory, getInjectionTargets()); | I think adding it to a List would not make sense in this case (same for the WebServiceHandler). That should be it, so that we just process annotations once (still ignoring dynamic beans). Does that makes sense ? :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169049#4169049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169049

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: StructureContext and candidate annotations

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : I don't really understand what you are trying to do, | | but children are described by the ContextInfos of the StructureMetaData. | | | I need a place to store found annotations. | Or, a way to get additional information about deployment, | e.g. it's an EJB deployment since there is some class annotated with @Stateless. | | In the case of EAR I need to check all sub deployments that are not explicitly described in application.xml. | First they need to be recognized by some strucuture deployer, in our case currently only JARStructure can recognize it (combination of StructureContext.isCandidateAnnotationScanning() && Deployer.isSupportsCandidateAnnotations() == false). | After it is recognized, I need to add additional type information to the EarModule metadata (EJB, Client, Connector, Service, ...). | | So, I was thinking of keeping found annotation classes in the StructureContext instance. | But in EAR's case, I have access to top level structure context, where I actually need to check sub context's found annotations. | | I don't see how ContextInfo can help me there. | Unless I keep this annotation lookup info there. | Looking at the MockEARStructureDeployer, isn't the issue that you need to be able to do some extra processing once you've found the annotations? i.e. not only does the EARStructure need to setCandidateAnnotationScanning(true) it also needs to be able to pass a callback such as | public EARCandidateAnnotationsCallback implement CandidateAnnotationsCallback | { | List<EARModule> modules; | | public EARCandidateAnnotationsCallback(List<EARModule> modules) | { | this.moduleMetaData = moduleMetaData; | } | | public void annotationScanningCallback(StructureContext context, AnnotationEnvironment env) | { | EARModule module = determineModuleFromAnnotations(context, env); | modules.add(module); | } | } | Then JARStructure does something like: | if (annotationScanningEnabled && deploymentRecognised && annotationPresent) | { | addChild(); | context.runAnnotationScanningCallbacks(context, env); | } | I'm not suggesting this is the exact way you should do it, since I haven't looked at the problem domain, but this kind of "visitor pattern" is usually preferable to trying to hack some kind of state into stateless designs which always gets very messy and hacky. Especailly in cases like this where the JARStructure should not need to know anything about EARs. The EARStructure may not even be deployed in some environments! There could be other top level structures that also want this behaviour in future. P.S. In case you haven't already spotted it (its not mentioned in my original blurb), you also need some logic to avoid visiting candidates and doing annotation scannning on modules that are already known by the EARStructure from the xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169047#4169047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169047

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by alesj

"adrian(a)jboss.org" wrote : | I also imagine the IncompleteDeploymentException processing doesn't | know to look in the ScopedController when summarising failed dependencies. This can easily be added with the work I did with @Search. - http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kern... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169044#4169044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169044

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by alesj

"adrian(a)jboss.org" wrote : | I didn't even think Ales had finished the ScoppedController? | It slowly getting better. :-) The current scope usage can look like this (pretty much what Kabir is using): Since we only have explicit access to root Controller, all beans we pass to it must have unique name, so when we do uninstall we get the right bean. But alias can be duplicated name, but of course in different scope. If you add alias to scoped bean via @Alias, you then don't need care about any previous beans with the same name, since alias is applied after PreInstallAction, which pushes the bean to the right scoped controller, hence alias is applied on scoped controller. With @Search you can also specify you injection scope, e.g. only check current controller, not looking into parent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169043#4169043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169043

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: MBean Dependency not working as expected .

by adrian＠jboss.org

"vickyk" wrote : "adrian(a)jboss.org" wrote : To get what you want in JMX, you'd have to introduce | | something like the MC demand into the jmx xml. | | | | I was guessing the same behavior but wanted to clarify it without digging into code ;) And that's exactly why it is a BAD POST. Somebody who has done no research whatsover is claiming they have a bug to get attention. Complete waste of people's time. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169042#4169042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169042

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: StructureContext and candidate annotations

by alesj

"adrian(a)jboss.org" wrote : I don't really understand what you are trying to do, | but children are described by the ContextInfos of the StructureMetaData. | I need a place to store found annotations. Or, a way to get additional information about deployment, e.g. it's an EJB deployment since there is some class annotated with @Stateless. In the case of EAR I need to check all sub deployments that are not explicitly described in application.xml. First they need to be recognized by some strucuture deployer, in our case currently only JARStructure can recognize it (combination of StructureContext.isCandidateAnnotationScanning() && Deployer.isSupportsCandidateAnnotations() == false). After it is recognized, I need to add additional type information to the EarModule metadata (EJB, Client, Connector, Service, ...). So, I was thinking of keeping found annotation classes in the StructureContext instance. But in EAR's case, I have access to top level structure context, where I actually need to check sub context's found annotations. I don't see how ContextInfo can help me there. Unless I keep this annotation lookup info there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169037#4169037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169037

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by adrian＠jboss.org

I made a few more comments on the original before I noticed you'd suggested moving the discussion here. SUMMARY: Although I don't know whether it is the root of your problem, I basically don't believe the ScopedController has been tested/integrated with either MDR or deployers. NEW on this thread: Besides the conflict on the INSTANCE scope in the MDR because the default is to use the bean name mentioned on the other thread, I also imagine the IncompleteDeploymentException processing doesn't know to look in the ScopedController when summarising failed dependencies. anonymous wrote : | The mentioned alias contains the original name of the bean | The alias has to be unique within the same namespace so I don't know what that achieves? What I need to understand is where you are changing the name. Although the deployers let you change most of the deployment descriptors, changing the identity is obviously a no-no. In practice, you can do it for your case as long as you do it before the component deployers run, because that is what creates the deployment components with the bean names as the id and it is from the component that the INSTANCE scope in the MDR is generated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169035#4169035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169035

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing correct aspect manager for a deployment

by adrian＠jboss.org

You are certainly trail blazing. :-) I didn't even think Ales had finished the ScoppedController? It doesn't have much coverage with nothing related to metadata | $ cd ~/microcontainer/dependency/src/tests/org/jboss/test/dependency/controller/ | $ find . -iname *Scope* | grep -v svn | grep TestCase | | cd ~/microcontainer/kernel/src/tests/org/jboss/test/kernel/ | $ find . -iname *Scope* | grep -v svn | grep TestCase | ./annotations/test/search/ScopeKeySearchTestCase.java | ./dependency/test/ScopedDuplicateAliasAnnotationTestCase.java | ./dependency/test/ScopedDuplicateAliasXMLTestCase.java | ./dependency/test/ScopedDuplicateAliasTestCase.java | ./deployment/xml/test/ScopeTestCase.java | ./deployment/xml/test/ScopeJaxbTestCase.java | There's nothing related to ScopedControllers in the deployment framework. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169030#4169030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169030

17 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008