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

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by ron.sigal＠jboss.com

"trustin" wrote : | The 'socket' transport here is the R2-compatible transport rather than the backward incompatible R3 socket transport, right? | Rignt. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167487#4167487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167487

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by trustin

"ron.sigal(a)jboss.com" wrote : 1. 1b+2ba should be our minimal goal, and | | 2. hiding everything inside Remoting proper is preferable, since it better serves standalone users. | | The latter seems to imply a "socket" transport in Remoting 3. The 'socket' transport here is the R2-compatible transport rather than the backward incompatible R3 socket transport, right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167483#4167483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167483

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-1019, RemotingClassLoader parent first behavior

by ron.sigal＠jboss.com

"scott.start*jboss.org" wrote : | asap, mid to late aug. | Will do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167478#4167478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167478

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-1019, RemotingClassLoader parent first behavior

by scott.stark＠jboss.org

The patch I just attached to the issue allows the appclient tests I have been working on to pass. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167475#4167475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167475

15 years, 9 months

1
0
0 / 0

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

by scott.stark＠jboss.org

The KernelDeploymentDeployer just exposes the KernelDeployment BeanMetaData as well as free BeanMetaData attachments to the BeanMetaDataDeployer, which deploys the beans to the kernel. In general you have to call getAllMetaData to process the multiple BeanMetaDatas, and you also have to look at KernelDeployment attachments as a container of BeanMetaDatas if your going to run at POST_PARSE. Running as a REAL deployer that consumes BeanMetaDatas allows the KernelDeploymentDeployer to do the work of unwrapping the KernelDeployment for you. The deployers are ordered by their inputs/outputs so that is why it works. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167473#4167473 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167473

15 years, 9 months

1
0
0 / 0

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

by bstansberry＠jboss.com

Just an update on this. Started off intending to ask a question, but I figured it out, so this is just an FYI to anyone interested. "scott.stark(a)jboss.org" wrote : A first pass implementation could simply have a mapping from the metadata class/property that is being bound and a deployer would update replace the component metadata before the component deployer runs. I've been experimenting with how such a deployer would work with a basic pojo deployment (e.g. a -beans.xml). Basically, get any BeanMetaData attachment and if there is a binding for it, wrap it in a new BeanMetaData that overrides the interfaces/ports: | public class ServiceBindingDeployer extends AbstractDeployer | { | public ServiceBindingDeployer() | { | setStage(DeploymentStages.POST_PARSE); | setInput(BeanMetaData.class); | setOutput(BeanMetaData.class); | setComponentsOnly(true); | } | | public void deploy(DeploymentUnit unit) throws DeploymentException | { | BeanMetaData metadata = unit.getAttachment(BeanMetaData.class); | if (metadata != null) | { | BeanMetaData alteredMetaData = applyBindings(unit, metadata); | unit.addAttachment(BeanMetaData.class, alteredMetaData); | } | } | | private BeanMetaData applyBindings(DeploymentUnit unit, BeanMetaData metadata) | { | // TODO implement me -- if a binding exists, wrap the passed in metadata | // with an alternate that changes the values for interfaces/ports | | return metadata; | } | } | This is targeted at DeploymentStages.POST_PARSE, as what it's doing seems to fit the javadoc for that stage: | /** The post parse stage - where metadata can be fixed up */ | DeploymentStage POST_PARSE = new DeploymentStage("PostParse", PARSE); | Problem is, it doesn't work because the KernelDeploymentDeployer is what creates the component DeploymentUnit(s) and their BeanMetaData. And that deployer runs at DeploymentStages.REAL, after the above ServiceBindingDeployer. I can get it to work by changing ServiceBindingDeployer to DeploymentStages.REAL. A concern is making sure it gets invoked before BeanMetaDataDeployer for any given deployment unit. But whether I deploy it after BeanMetaDataDeployer, it still gets invoked first, which is good. :) And if I deploy it before KernelDeploymentDeployer, it also works fine. :-) I figure this is because the output (BeanMetaData) from KernelDeploymentDeployer is the input to ServiceBindingDeployer. ServiceBindingDeployer outputs the same type that it inputs, and BeanMetaDataDeployer takes that as an input and has no output, so Deployers must be recognizing that ServiceBindingDeployer needs to go in the middle. Nice! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167472#4167472 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167472

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-1019, RemotingClassLoader parent first behavior

by scott.stark＠jboss.org

asap, mid to late aug. I'm working on a patch now so I can test that this really solves the problem. I'll attach the patch to the issue once it looks like its what I need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167461#4167461 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167461

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-1019, RemotingClassLoader parent first behavior

by ron.sigal＠jboss.com

I've assigned JBREM-1019 to Remoting version 2.4.0.SP1, which is intended for JBossAS-5.0.0.CR2. Do we have an expected date for JBossAS-5.0.0.CR2? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167450#4167450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167450

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-1019, RemotingClassLoader parent first behavior

by david.lloyd＠jboss.com

Yes it is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167439#4167439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167439

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: JBREM-1019, RemotingClassLoader parent first behavior

by scott.stark＠jboss.org

Is https://svn.jboss.org/repos/jbossremoting/remoting2/branches/2.x/ the current branch for the 2.4.x series? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167437#4167437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167437

15 years, 9 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 July 2008