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

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting unmarshalling vs. class loaders

by scott.stark＠jboss.org

"david.lloyd(a)jboss.com" wrote : | You mean so that the client can pick the right classloader to unmarshal the response? I think that clients should also be associated with a CL as well (anyway we need to do that to allow us to specify a RemoteClassLoader on the client side). I doubt there is likely to be a 1:1 correspondence between classloaders on the client and server side, so I don't really see the benefit of annotating the response with classloader information. | No, I mean if the response object container the unmarshalled object that is going to be streamed by the transport layer after the handler has cleared the TCL, possibly in another thread. "david.lloyd(a)jboss.com" wrote : | Setting the TCL for the duration of any task that handles a request is doable though. There are currently no plans to implement any form of lazy unmarshalling. We will need to ensure that the streaming facility can have access to the marshaller as well as the classloader. The TCL only works for class loading that occurs in the scope of a request dispatch. The concern is for marshalling that occurs after the handler has returned, and cleared the TCL. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169311#4169311 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169311

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

"prabhat.jha(a)jboss.com" wrote : Galder, can you please also mention what changed you ended up doing on portal side? It's just configuration changes to use the new provider and a bit of cleanup in the jboss-service.xml. I'll attach the patch and jar to the JIRA once we're happy with the code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169309#4169309 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169309

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Which is the best place to write a test case for ejb3-te

by jaikiran

https://jira.jboss.org/jira/browse/EJBTHREE-1453 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169307#4169307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169307

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

"manik.surtani(a)jboss.com" wrote : Scott is right, this does apply to JBC as well. Currently what I do is I have a concept of cache regions, and users register class loaders per region. Any calls that are then sent over the wire contain the following: | | [version id: short][region id: serialized Fqn][payload] | | my unmarshalling code currently: | | 1. reads the version id and delegates to the appropriate unmarshaller | 2. unmarshaller reads the region id and sets the TCL appropriate to that region | 3. continues unmarshalling payload, etc | I would continue to do it exactly this way personally. The stream header mechanism should not be used to solve this problem (as designed today) - its purpose is just for verifying e.g. the stream's magic number (if there is one) and version number (if any). Assuming your region ID is a string, you can just use DataInput.readUTF to read it in (and DataOutput.writeUTF to write it out); should be fairly straightforward. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169301#4169301 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169301

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder

by alex.loubyansky＠jboss.com

Finally, fixed. I used @JBossXmlAdaptedType for this (it had already had type as a target). Here is an example from the testsuite @XmlType() | @JBossXmlAdaptedType(valueAdapter=CardinalityValueAdapter.class) | public class Cardinality extends JBossObject implements Serializable View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169299#4169299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169299

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting unmarshalling vs. class loaders

by david.lloyd＠jboss.com

"scott.stark(a)jboss.org" wrote : "david.lloyd(a)jboss.com" wrote : So as long as you keep your requests confined to a single classloader (on the receiving side) then things should work out. I think that associating a service with its appropriate classloader would be the right thing to do there (the protocol handler would then choose the classloader based on the service being invoked). Given the R3 design, which makes requests and client instances much more lightweight, mixing classloaders in requests would be an indication of improper service design - if you're doing that, you probably need multiple services (one for each aspect that lives in its own classloader). | | | Agreed, the target of the remoting invocation should have a distinct class loader that would be set as the request TCL. However, if there is a lazy or streaming facility that allows the marshalling to occur at the remoting layer and there is object replacement via replaceObject, proxy replacement, etc., the marshaller needs the handler TCL saved for the duration of the response. Is there a way the handler can associate that with the response object? | You mean so that the client can pick the right classloader to unmarshal the response? I think that clients should also be associated with a CL as well (anyway we need to do that to allow us to specify a RemoteClassLoader on the client side). I doubt there is likely to be a 1:1 correspondence between classloaders on the client and server side, so I don't really see the benefit of annotating the response with classloader information.ju Setting the TCL for the duration of any task that handles a request is doable though. There are currently no plans to implement any form of lazy unmarshalling. We will need to ensure that the streaming facility can have access to the marshaller as well as the classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169298#4169298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169298

17 years, 8 months

1
0
0 / 0

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

by kabir.khan＠jboss.com

"alesj" wrote : | No, they should get the same one. | See ScopedKernelInitializer. OK, I see it now View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169288#4169288 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169288

17 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - JBossESB Filters - Using Spring context on Filters

by pcraveiro

I want to use a federated enterprise component that offers some security services (like auditing, for example). This component can be easy plugged using a Spring ApplicationContext to load all beans and required configurations. I would like to know if there is a way using the JBossESB Filters, to load this component without create the application context by hand, something like the AbstractSpringAction for creation of Spring aware Actions. Thanks, Pedro Igor View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169287#4169287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169287

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: eclipse build problems

by wolfc

My commit 76526 was actually bad, it disabled m2eclipse. Recommitted the real thing again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169285#4169285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169285

17 years, 8 months

1
0
0 / 0

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

by alesj

"kabir.khan(a)jboss.com" wrote : Beans deployed to the scoped controller get a different MDR from the main one, and there is no link between the two. | No, they should get the same one. See ScopedKernelInitializer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169284#4169284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169284

17 years, 8 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