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

[Design of JBossXB] - Mixing wildcards and elements

by kabir.khan＠jboss.com

Alex, Can you please take a quick look at the XmlLoadableAopTestCase in the aop-mc-int project? Basically we have | @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED) | @XmlRootElement(name="aspect") | public class AspectBeanMetaDataFactory extends AspectManagerAwareBeanMetaDataFactory | implements BeanMetaDataFactory | { | ... | private List<Element> elements; | | | public List<Element> getElements() | { | return elements; | } | | @XmlAnyElement(lax=true) | public void setElements(List<Element> elements) | { | this.elements = elements; | } | | @Override | public List<BeanMetaData> getBeans() | { | ArrayList<BeanMetaData> result = new ArrayList<BeanMetaData>(); | this.name = super.getBean(); | } | | } | | @XmlRootElement(name="beanfactory") | @XmlType(name="beanfactoryType", propOrder={"aliases", "annotations", "classLoader", "constructor", "properties", "create", "start", "depends", "demands", "supplies", "installs", "uninstalls", "installCallbacks", "uninstallCallbacks"}) | public class GenericBeanFactoryMetaData extends JBossObject implements BeanMetaDataFactory, Serializable | { | ... | protected Set<PropertyMetaData> properties; | | public Set<PropertyMetaData> getProperties() | { | return properties; | } | | @XmlElement(name="property", type=AbstractPropertyMetaData.class) | public void setProperties(Set<PropertyMetaData> properties) | { | this.properties = properties; | } | | public List<BeanMetaData> getBeans() | { | ... | if (properties != null && properties.size() > 0) | { | PropertyMap propertyMap = new PropertyMap(); | for (PropertyMetaData property : properties) //CCE as explained below | { | propertyMap.put(property.getName(), property.getValue()); | } | builder.addPropertyMetaData("properties", propertyMap); | } | ... | } | } | In XmlLoadableAopTestCase.xml I have the following defined: | <aspect class="org.jboss.test.microcontainer.beans.XmlLoadableAspect"> | <somexml>hello</somexml> | <attribute name="IntAttr">12</attribute> |  | </aspect> | "attribute" and "somexml" are wildcards, while "property" is declared on GBFMD. As it is the test is fine. If I remove somexml and attribute, and uncomment property it also parses fine. If I enable all three elements, I get a CCE at the point shown in GBFMD.getBEans(), since the properties map now contains one element of type org.apache.xerces.dom.ElementNSImpl instead of PropertyMetaData. I tried to reproduce this in the jbossxb project, but it worked as expected there, so I have probably missed some minor detail? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147322#4147322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147322

16 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Classloading problems with ClassProxyFactory

by kabir.khan＠jboss.com

Brian, If the anonymous wrote : | MethodHashesByClass.methodHashesByClass | + WeakHashMap.table | ++ WeakHashMap$Entry.value | +++ HashMap.table | ++++ HashMap$Entry.value | +++++ MethodPersistentReference.referencedObject | ++++++ SoftReference.referent | +++++++ java.lang.reflect.Method.clazz | ++++++++ class Person.classloader | +++++++++ "http-scoped-field.war" classloader classes | ++++++++++ proxy to ArrayList | If MethodHashesByClass refers to org.jboss.aop.util.MethodHashing. Changing the underlying SoftReference to a WeakReference should fix the problem you are seeing? Please confirm and we'll make the change for you View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147311#4147311 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147311

16 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Scoping of FIELD granularity session pojos

by galder.zamarreno＠jboss.com

Brian, "bstansberry(a)jboss.com" wrote : 1) Store pojos under the session that first passes them to setAttribute. Looks fine as long as you do it starting with JBoss 5. It's a major release, so you could get away with breaking as long as it's noted somewhere clearly and we've got easy access to it. "bstansberry(a)jboss.com" wrote : 2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session. I don't think we should try to leave something in that we don't wanna be supporting for JBoss 5. I like this solution for a potential future 4.x release. "bstansberry(a)jboss.com" wrote : Logically, if you want to share objects between sessions, the place to put them is in the ServletContext. There's a JIRA to make that clustered. A clustered ServletContext cache wouldn't use buddy replication. Interesting. Bearing in mind that my web development knowledge is a bit vague (side note: just to give you an idea: I was banging my head the other day because I was trying to access a servlet I deployed but kept getting a 404. I had forgotten the servlet mapping, doh!), seems like sharing objects between sessions via HTTPSession is a bad idea anyway, so this is an extra motivation to go for 1. IOW, if someone says it breaks, we can say it's a bad practice anyway. So, my opinion would be to go with 1 and implement sharing of pojos properly via the servlet context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147299#4147299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147299

16 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: UsernameToken authentication and authorization for POJO

by anil.saldhana＠jboss.com

Something along the lines of: | | Object obj = ctx.lookup("java:comp/env/security/securityMgr"); | AuthenticationManager am = (AM)obj; | am.isValid(Principal,Object); | | //Do generic authz | RealmMapping rm = (RM)obj; | rm.doesUserHaveRole(.....) | should work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147295#4147295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147295

16 years, 3 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: [jboss-profiler] needs hours to analyze/display heap sna

by clebert.suconic＠jboss.com

That's something we need to improve. We will have another version about July this year where we plan to improve this. Sorry for the trouble. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147251#4147251 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147251

16 years, 3 months

1
0
0 / 0

[Design of JBoss Profiler] - [jboss-profiler] needs hours to analyze/display heap snapsho

by mreis

After making a heap snapschot via the JVMTIClass MBean, I try to analyze/display the created files via jboss-profiler -> Memory Profiler. This creates "endless" log messages (e.g. "3580001 swaps") ... after 1 hour of monitoring the log I gave up. My heap snapshot created one file around 250MB - How long should it normally take to view the analyzed results via jboss-profiler -> Memory Profiler? Is there a better application to render/analyze the snapshot data? many thanks & kind regards, Markus View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147232#4147232 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147232

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Overhead of remoting filters

by jmesnil

"timfox" wrote : I'd be interesting in knowing what's the overhead of the keep alive and the request-response filters on non request-response traffic. | I've used MinaSessionTest.testWriteMany() and sent 50K messages to get some figures on these filters. There is some variation on these figures so they're to be taken with a grain of salt: with reqres & keepalive filters =============================== duration: 6242 ms without reqres filter ===================== duration: 6057 ms => duration decreases by 3% without keepalive filter ======================== duration: 5802 ms => duration decreases by 7% without reqres & keepalive filters ================================== duration: 5507 ms => duration decreases by 11% View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147199#4147199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147199

16 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Publish ESB services to web services

by mark.little＠jboss.com

Yes, +1 to Kev: I'd prefer to not override Message either. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147171#4147171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147171

16 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Filters in ESB

by mark.little＠jboss.com

BTW, I have implemented per-service filters but this won't be available until after ESB 4.3 goes out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147168#4147168 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147168

16 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: UsernameToken authentication and authorization for POJO

by darran.lofthouse＠jboss.com

"alessio.soldano(a)jboss.com" wrote : | I think it would be better to leave the configuration of the allowed roles to the login module configuration. May be I'm missing something, but I think we could simply let the user configure the security domain as usual and then the login module(s) configured for that security domain will have the roles configuration. | The reason that we need the additional role check is because the login modules do not actually verify the roles that the user is a member of, the login modules just load the list of roles. The list of roles is then checked against the required roles in the servlet container or in the EJB container. "anil.saldhana(a)jboss.com" wrote : | Why not just design a generic solution around invoking the JBoss Security Managers by doing a JNDI lookup (works both in web and ejb2 containers) | If the code you show is the better way to do it then there is no problem doing it that way as well, however we do not have a need for the actual code to be portable across the containers as the WS-Security handlers are always called within a web application. Even if you deploy an EJB endpoint a web application is automatically deployed to handle the actual WS requests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147136#4147136 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147136

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008