November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Portal Development] - Re: setting up portlet user attributes for hosted portlets i

by apemberton

Hi chenwang: not sure I understand your question exactly, but user attributes are built into both the JSR168/286 portlet specifications and supported by JBoss Portal. See the "User Identity" section in this post: http://blog.jboss-portal.org/2007/05/portlet-best-practices-1.html View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266593#4266593 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266593

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: New features in classloading

by alesj

"adrian(a)jboss.org" wrote : | In all three routines. | I only found two - found and not-found. Where's the third? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266590#4266590 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266590

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : I | As you can see I am not using MDR at all yet at this stage. Where do you see MDR fitting in? Is the idea to add all contexts that have a qualifier to somewhere in MDR and to be able to query that to avoid iterating over all contexts, or do you have something else in mind? I think I am missing what you guys mean by filtering in that other thread Aha :-) I found page 2&3 of the discussion. I guess you mean something similar to ServiceTracker? To clarify, do you have any examples of what OSGi needs? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266588#4266588 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266588

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: New features in classloading

by adrian＠jboss.org

No, actually there's an else missing :-) In all three pieces routines. | if (parentLoader instanceof ClassNotFoundHandler) | parent = (ClassNotFoundHandler) parentLoader; | + else | + { | ClassLoaderPolicy parentPolicy = getClassLoaderPolicy(parentLoader); | if (parentPolicy != null) | parent = parentPolicy; | + } | If we know the parent implements Class*Handler then the second part is redundant. The second part is there for if you put a ClassLoaderToLoaderAdapter as the parent rather than a Domain, like it does for web-apps. Then you've got to do a bit of a dance to get the parent's ClassNotFoundHandler. adapter -> BaseClassLoader -> ClassLoaderPolicy In practice it will always return null into the parentPolicy for a ClassLoaderDomain which is why I didn't spot it in the testing. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266586#4266586 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266586

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC

by kabir.khan＠jboss.com

I have something working for qualifiers now. The demanded qualifiers are currently only on bean-level (coarse-grained). I've added these methods to BeanMetaData: | /** | * Get the qualifers exposed by this bean | * | * @return a set of the qualifiers | */ | Set<QualifierMetaData> getQualifiers(); | | /** | * Get the qualifiers that will be used by default for properties and parameters | * that don't have explicit qualifiers on their value dependency metadata | * | * @return a set of the qualifiers | */ | Set<QualifierMetaData> getDefaultQualifiers(); | QuailifierMetaData: | /** | * MetaData describing the qualifiers | * | * @author <a href="kabir.khan(a)jboss.com">Kabir Khan</a> | * @version $Revision: 1.1 $ | */ | public interface QualifierMetaData extends JBossInterface, MetaDataVisitorNode | { | /** | * Get the qualifier | * @return the qualifier | */ | Object getQualifier(); | } | If a bean uses autowiring for it's injection and has "default qualifiers" a ClassAndQualifierKey is used to do the lookups from AbstractInjectionValue and SearchQualifiedClassDependencyItem (similar to SearchClassDependencyItem, but takes the ClassAndQualifierKey instead of the plain class. The calls from AIV and SQCPI end up here in AbstractKernelController | public KernelRegistryEntry getEntry(Object name) | { | List<KernelControllerContext> list; | | + if (name instanceof ClassAndQualifierKey) | + return ((ClassAndQualifierKey)name).search(this); | if (name instanceof Matcher) | list = matchSupplies((Matcher)name); | else | list = suppliers.get(name); | | if (list != null && list.isEmpty() == false) | return list.get(0); | else if (name instanceof Class) | return getContextByClass((Class<?>) name); | else | return null; | } | The ClassAndQualifierKey contains the logic to find the context with the qualifiers, and here briefly is what it does | class ClassAndQualifierKey | { | Class<?> type; | ControllerState dependentState; | Set<Object> qualifiers; | | public KernelControllerContext search(KernelController controller) | { | Set<KernelControllerContext> contexts = controller.getContexts(type, dependentState); | for (KernelControllerContext context : contexts) | { | for (Object myqualifier : qualifiers) | { | for (QualifierMetaData qualifier : context.getQualifierMetaData()) | { | //check myqualifier vs qualifier.getQualifier() | } | } | } | } | } | As you can see I am not using MDR at all yet at this stage. Where do you see MDR fitting in? Is the idea to add all contexts that have a qualifier to somewhere in MDR and to be able to query that to avoid iterating over all contexts, or do you have something else in mind? I think I am missing what you guys mean by filtering in that other thread View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266584#4266584 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266584

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: New features in classloading

by alesj

"adrian(a)jboss.org" wrote : I should also note that the ClassFoundHandler is only invoked when it does | defineClass() Is the "// Missing?" piece intentional? Or is this trying to get best match? ClassLoaderDomain | public void classFound(ClassFoundEvent event) | { | ClassFoundHandler parent = null; | Loader parentLoader = getParent(); | if (parentLoader instanceof ClassFoundHandler) | parent = (ClassFoundHandler) parentLoader; | | // Missing? Should there be some call to parent's classFound method? | | ClassLoaderPolicy parentPolicy = getClassLoaderPolicy(parentLoader); | if (parentPolicy != null) | parent = parentPolicy; | | if (parent != null) | parent.classFound(event); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266581#4266581 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266581

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"flavia.rainone(a)jboss.com" wrote : Is there an easy way of filtering out those scenarios? If not, I'm going to use the recursive structure of JBossClDelegatingCPFactory.registerBootstrapLoaders itself to abort the creation of a CP when its domain corresponds to a CP that is being created in an outer scope of the recursion. I meant filtering out those modules, and not scenarios. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266570#4266570 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266570

16 years, 4 months

1
0
0 / 0

[JBoss AOP Development] - Re: ClassPool Refactoring

by kabir.khan＠jboss.com

"flavia.rainone(a)jboss.com" 3. Should ClassPoolRepository.callback be a list instead? I've made it a reference to a single callback for performance reasons. I can change it if Kabir or Ales prefer.[/quote wrote : | It should definitely be a list. Other systems apart from AOP might want to do some cleanup as well and so should have the option to install a callback. Performance isn't really an issue in this case, dropping classloaders will normally happen on undeploy which involves a lot more work than creating an extra iterator :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266568#4266568 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266568

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"flavia.rainone(a)jboss.com" wrote : "flavia.rainone(a)jboss.com" wrote : I was wondering is there is any way of identifying that specific type of scenario. If I could do that, I would generate the "bootstrap" CP only for "non-deployment" modules. This would avoid the problem in the scenario I described above without breaking testNonDeploymentModule. | | Actually, this is not what I want to do. This kind of fix would be useless, because, AFAIK, I could create the same ear scenario I described before using an beans.xml file. In that case, the "war" corresponding modules wouldn't be filtered out of JBossClDelegatingCPFactory.registerBootstrapLoaders, and the bug would occur again. I want to filter out the "bootstrap" modules that correspond to a submodule of the module whose CP is currently being created. In other words, in the scenario I described, where the war classLoader has the ear class loader as its domain (using an adapter), if the ear module is the one that was originally requested to JBossClDelegatingCPFactory, the war module is going to be skipped as a bootscrap cp. I think that that solves the bug. Is there an easy way of filtering out those scenarios? If not, I'm going to use the recursive structure of JBossClDelegatingCPFactory.registerBootstrapLoaders itself to abort the creation of a CP when its domain corresponds to a CP that is being created in an outer scope of the recursion. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266566#4266566 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266566

16 years, 4 months

1
0
0 / 0

[JBoss AS Development] - Re: JBAS-7469, move bootstrap class loading into profile

by jaikiran

"emuckenhuber" wrote : It looks like the same is true for the common.lib folders as well. Most of the .jars would actually rather belong to a deployer or profile. | I agree with this point. For example, the EJB3 jars would make sense only for a profile which has EJB3 capabilities. Right now most of the EJB3 jars are put in common/lib. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266564#4266564 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266564

16 years, 4 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 November 2009