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

[Design of JBoss Portal] - Re: Coordination work

by julien＠jboss.com

it means that in the explicit case if you do not wire a public render parameter then it is never possible to set it with a value which means that the portlet will not work as expected. "bdaw" wrote : "julien(a)jboss.com" wrote : one glitch I noticed is that in the explicit case, if a parameter is not explicit declared in a binding then it will simply never retain its state. | | | | It is visible in the explicit sample if you update PublicParametersPortletWindow1 juu1 parameter. The value is lost. | | | | I think it should rather remain private rather than being discarded, which would mean that in the explicit case this parameter is considered like a private parameters and is stored in the per window navigational state. Which would mean to add a Map<String, String[]> in the WindowNavigationalState to store such state. | | | | What do you think ? | | I remember we discussed it some time ago a bit. The thing is what behaviour would be expected. This would be the difference between FALLBACK and EXPLICIT strategy. In EXPLICIT param not wired is lost while in FALLBACK not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166089#4166089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166089

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: Coordination work

by bdaw

"julien(a)jboss.com" wrote : one glitch I noticed is that in the explicit case, if a parameter is not explicit declared in a binding then it will simply never retain its state. | | It is visible in the explicit sample if you update PublicParametersPortletWindow1 juu1 parameter. The value is lost. | | I think it should rather remain private rather than being discarded, which would mean that in the explicit case this parameter is considered like a private parameters and is stored in the per window navigational state. Which would mean to add a Map<String, String[]> in the WindowNavigationalState to store such state. | | What do you think ? I remember we discussed it some time ago a bit. The thing is what behaviour would be expected. This would be the difference between FALLBACK and EXPLICIT strategy. In EXPLICIT param not wired is lost while in FALLBACK not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166083#4166083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166083

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: Coordination work

by bdaw

"julien(a)jboss.com" wrote : Is the alias implementation started (Map<QName, Set>) ? I haven't seen sample yet. Yes. its in CoordinationConfigurator: | /** | * Set alias binding for a given page. If alias with given name already exists it will be overwritten | * | * @param page | * @param aliasName | * @param qnames | * @throws IllegalCoordinationException | */ | void setAliasBinding(Page page, String aliasName, Set<QName> qnames) throws IllegalCoordinationException; | | /** | * Removes alias binding | * | * @param aliasInfo | * @throws IllegalCoordinationException | */ | void removeAliasBinding(AliasBindingInfo aliasInfo) throws IllegalCoordinationException; | | /** | * @param page | * @return collection of alias bindings connected to the given page | */ | Collection<AliasBindingInfo> getAliasBindings(Page page); So at the moment the alias String name maps Set in scope of page. Should the alias name be QName rather? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166080#4166080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166080

18 years

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by scott.stark＠jboss.org

Ok, the problem is that there is an inconsistency with the standard metadata class processors and the jboss extensions. The org.jboss.metadata.annotation.creator.jboss.AbstractComponentProcessor.process is calling processClass with the JBossEnvironmentRefsGroupMetaData.class as the processorType: | public void process(RemoteEnvironmentRefsGroupMetaData metaData, Class<?> type) | { | // @Resources/@Resource | processClass(metaData, type, JBossEnvironmentRefsGroupMetaData.class); | ... | but the Resource*Processors are only registered for the standard metadata as most of the envionrment metadata is simply standard descriptor stuff. If this is changed to the RemoteEnvironmentRefsGroupMetaData: | public void process(RemoteEnvironmentRefsGroupMetaData metaData, Class<?> type) | { | // @Resources/@Resource | processClass(metaData, type, RemoteEnvironmentRefsGroupMetaData.class); | ... | Then the session context shows up under ResourceEnvironmentReferenceMetaData as expected: 22:57:44,333 INFO [SessionContextAddedToMetadataUnitTestCase] org.jboss.metadata.javaee.spec.ResourceEnvironmentReferenceMetaData@38b735af{context} Assign the issue to Emanuel or Alexy as there are issues with registering jboss specific type processors to deal with this correctly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166068#4166068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166068

18 years

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by ALRubinger

Sorry for leading you down the wrong road, then. At least I'm not crazy. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166065#4166065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166065

18 years

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by scott.stark＠jboss.org

Ok, let me take a look. Just glancing at the bean/test it should be showing up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166064#4166064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166064

18 years

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by ALRubinger

Clearly this isn't my domain. :) Added a quick unit test in JBMETA-80 to show what I'm talking about. This is tangential to a test I'm trying to create in EJB3 Core which requires @Resource injection on SessionContext. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166063#4166063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166063

18 years

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] No ResourceProcessor for JBoss50Creator

by scott.stark＠jboss.org

I don't know what your looking at as there are process methods on both: | package org.jboss.metadata.annotation.creator.jboss; | | * @version $Revision: 72364 $ | public abstract class AbstractComponentProcessor<MD> | extends AbstractProcessor<MD> | { | public void process(RemoteEnvironmentRefsGroupMetaData metaData, Class<?> type) | { | ... | } | public void process(EnvironmentRefsGroupMetaData metaData, Class<?> type) | { | ... | | package org.jboss.metadata.annotation.creator; | | * @version $Revision: 76002 $ | public abstract class AbstractComponentProcessor<MD> | extends AbstractProcessor<MD> | { | public void process(RemoteEnvironmentRefsGroupMetaData metaData, Class<?> type) | { | } | | public void process(EnvironmentRefsGroupMetaData metaData, Class<?> type) | { | ... | } | } | | ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166060#4166060 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166060

18 years

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by scott.stark＠jboss.org

BasicJndiBindingPolicy is for both ejb3/2. The MappedReferenceMetaDataResolverDeployer needs the metadata to provide the jndi name for both types of reference targets. Whether its a decorator or policy does not matter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166059#4166059 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166059

18 years

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by ALRubinger

I see. An EJB3 Deployment, but EJB2.x Remote Homes Views. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166054#4166054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166054

18 years

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 July 2008