September 2007 - jboss-dev-forums

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3 API Mockup/prototype

by david.lloyd＠jboss.com

Ah, I posted the wrong link in the first post. The anonymous link was correct, but the main repository link should be: https://svn.jboss.org/repos/sandbox/david.lloyd/remoting3/api-proto Just goes to show you how many people read these messages :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086409#4086409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086409

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS-RM Sender/Receiver Location Within JBossWS Stack

by palin

Hi Richard, I've just taken a look at both your private branch code and this post ;-) "richard_opalka" wrote : 1.) Yes, the model of the SENDER and RECEIVER should be similar. I've just draw the client side, but you can imagine similar mechanism on the server side too. Just for clear in present I'm mainly focusing on the client side. OK, as a matter of fact speaking of RM, client side and server side do a lot of things the same way. anonymous wrote : 2.) I was playing games and doing some experiments with JBossWS client side invocation framework and was looking for the most suitable place to put the RM SENDER in. I have implemented dummy sender and executed all the JBossWS tests on all JBoss AS version against this dummy sender. The result of my experiment is in SVN repository (in my branch). | You can find this dummy sender implementation in RemotingConnectionImpl.java. But there's something that is not clear to me: let's consider the server side (but this also apply on client side), shouldn't the RM subsystem process incoming messages before passing them to the core? (for example to be able to send receive acks) As far as I understand, when you do all the RM processing in the RemotingConnectionImpl, all the core/application work has already been performed (you're ready to send response message, right?) When working on ws-policy, we thought a bit about ws-rm too, since this is going to use policies. We immagined that we could have ws-rm handlers (set by the ws-policy deployer on both client and server sides) intercepting messages and passing them to RM subsystem. May be this is not the best idea... but you might consider this too ;-) anonymous wrote : I'm expecting another questions, comments, criticism and opinions from you guys ;-) Just an idea for now... this afternoon I was thinking about cluster with Stefano. Did you consider that a real reliable messaging system is most likely going to be deployed on a clustered environment? (I mean, if you're seeking for reliability... why having a single point of failure using a single host?) IMHO it might be a plus to design the RM implementation keeping this cluster-issue in mind. Bye Alessio Soldano View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086397#4086397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086397

18 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Resource adapter transaction timeout enforcement

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : What you describe is called OTS/JTS. It's already a standard and is probably a lot more complicated than you've envisoned to do correctly and efficiently. :-) It's possible. It wouldn't be the first time I've overestimated my own cleverness. "adrian(a)jboss.org" wrote : You need to speak to the transaction team and make sure you are on the same page. I intend to do so, and I hope that I will have that chance next week. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086392#4086392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086392

18 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Transport Use Cases

by david.lloyd＠jboss.com

"trustin" wrote : I agree with you that it's of dubious value to provide additional transports considering the current set of implemented transports. | | BTW, it sounds like Remoting is not for interoperability between various parties but for efficient and full-featured communication between only Remoting clients and servers. Did I understand correctly? You are correct. "trustin" wrote : and out of curiosity, is it what users want? Well, we've had a tough time getting user input thus far. Hopefully next week will shed some light. The current state of Remoting 3 is based on all the feedback I've been able to locate about earlier versions thus far. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086390#4086390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086390

18 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TxServerInterceptor hardwiring

by reverbel

Never mind, now I see there is no need for a separate jar, as the new interface is placed within jboss-integration.jar. Maven works... :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086379#4086379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086379

18 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: More then one jboss portal servers using the same portal

by shimonl97

sorry wrong forum, please delete my post View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086363#4086363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086363

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

Yes, you have to dispatch the methods as needed. Ops on the ManagedOperation can be handled by the existing remoting wiring. The wiring for invoke to the runtime component is what you need to do such that ManagementViewImpl.invoke does the dispatch. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086359#4086359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086359

18 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - More then one jboss portal servers using the same portal dB

by shimonl97

Is their a problem with working from two different jboss portal servers on the same portal dB? It looks like a must if more then one developer programmed on his local jboss portal but try to use one centric db. We tried it but run into exceptions that were solved when we generated portal db for each developr. problem can also be on production if we work with load ballancer with more then one jboss portal on one portal db View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086358#4086358 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086358

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

Hmmm ... is this stuff done wrong or I just don't get the concept: | java.lang.IllegalStateException: No target found for op: ManagedOperation(name=listFormatttedSubPoolStatistics,description=Obtain a formatted statistics report,impact=ReadOnly) | at org.jboss.profileservice.management.ManagementViewImpl.invoke(ManagementViewImpl.java:662) | at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:77) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573) | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373) | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) | at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163) | at org.jboss.remoting.Client.invoke(Client.java:1550) | at org.jboss.remoting.Client.invoke(Client.java:530) | at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at AOPProxy$12.getName(AOPProxy$12.java) | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testDefaultDSOps(ProfileServiceUnitTestCase.java:339) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:69) | at com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs(IdeaTestRunner.java:24) | at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:118) | at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) | at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) | at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) | at AOPProxy$12.getName(AOPProxy$12.java) | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testDefaultDSOps(ProfileServiceUnitTestCase.java:339) | Shouldn't be a 'ManagedOperation.getName' invocation just a simple remote call of the actual server side coresponding ManagedOperation instance's getName method. And only the 'mapping' of the ManagedOperation.invoke(org.jboss.metatype.api.values.MetaValue... metaValues) call should be actually wired onto runtime component? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086355#4086355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086355

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

For the ManagementObject that defines the ManagedOperations, the name of the associated runtime component the operations correspond to needs to be keyed to the ManagedOperation so it can be dispatched when invoked. This is not related to the ManagedObject name code you show. Its a function of the metadata attachment associated the ManagedObject with the ManagedOperations. For jmx mbeans, this should be a ServiceMetaData instance, and the objectName property is what defines the runtime component to dispatch the ops to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086353#4086353 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086353

18 years, 6 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 September 2007