September 2007 - jboss-dev-forums

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

by richard_opalka

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. 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. If you would like to explain something we can communicate it also e.g. via Skype. I'm expecting another questions, comments, criticism and opinions from you guys ;-) Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085894#4085894 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085894

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

The org.jboss.metadata from the metadata project, for example: https://svn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java... is not usable as a replacement for the server project version, because its abstract. Its also not a complete replacement for the existing version. How was this generated, and why is the MethodMetaData abstract? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085864#4085864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085864

18 years, 6 months

1
0
0 / 0

[QA of JBoss Portal] - JBoss Portal and JSF Application Integration

by Renju

Hi All, I am new to the JBoss portal. I want to create a JSF(Full architecture is JSF,Spring, Hibernate), Application running on JBoss Portal. The situation is like that 1.The entire application is running on single portal, and no portlets needed(My concept is running JSP's on portal without portlets). 2. I want only the Theam managemant and user management features of JBoss portal. 3. Is it possible to integrate an old JSF application to JBoss portal without much changes(Application running on portal no portlets needed). It will be very helpful for me if you comment on this issues. Thanks, Renju View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085851#4085851 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085851

18 years, 6 months

1
0
0 / 0

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

by trustin

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? and out of curiosity, is it what users want? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085843#4085843 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085843

18 years, 6 months

1
0
0 / 0

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

by trustin

I got 404. Is it moved somewhere? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085842#4085842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085842

18 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Why bother with APR?

by trustin

"timfox" wrote : I believe the RHM team compared NIO (using Apache MINA) to Apache APR and also to asynchronous IO using direct Linux OS calls (i.e. not going through the APR abstraction layer). | | I believe the direct hooks gave the best performance, NIO was pretty good, and APR not so good due to the overhead of having to find a common API over all OSs. | | Sorry for the vaguities, but this is what I remember them mentioning. Don't know if their findings were correct or not. | | BTW we (JBM) definitely need NIO for handling large number of connections. APR is a "nice to have" if it gives radically better performance than NIO, but I'm not particularly bothered about it. Is there any written report related with their findings? I am with Tim in that APR is a nice-to-have. Some platform's NIO performance might not be better than APR and vice versa, so it would be nice if users can choose what the best is for their running platform. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085841#4085841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085841

18 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Interruption and the Remoting 3 API

by trustin

Thanks for explanation David. If it's purely about interruption of a local thread, I'd prefer the option D without introducing a new subclass exceptions. I'm not sure it's cluttering but it will be very convenient for the API users though. Personally I chose interruptable one as default: http://mina.apache.org/report/trunk/xref/org/apache/mina/common/IoFuture.... As you pointed out, a user can know explicitly that the interruption status flag is set from the fact that he or she caught the InterruptedException by oneself. We will need more documentation if we deal it with any other exception classes (i.e. RemotingException subclasses). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085829#4085829 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085829

18 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Interruption and the Remoting 3 API

by david.lloyd＠jboss.com

One consequence of using a RemotingException subclass is that, unlike when using InterruptedException, the thread must be re-interrupted before throwing the exception. So user code that doesn't check for it, will be interrupted at the next interruptable point anyway. On the other hand, if the user does catch the interruption subclass, they may have to clear the thread's interruption status in addition to catching the exception. This is in contrast to user code that catches InterruptedException; such code already has had the thread's interruption status cleared. I'm not sure if this will be an advantage or disadvantage though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085816#4085816 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085816

18 years, 6 months

1
0
0 / 0

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

by weston.price＠jboss.com

It varies and there are no hard and fast rules. Typically the adapter takes care of this if the timeout is required beyond the default, but again, this is not a strict requirement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085768#4085768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085768

18 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Interruption and the Remoting 3 API

by jason.greene＠jboss.com

"david.lloyd(a)jboss.com" wrote : Some operations in Remoting 3 might be | So here's the question: should these normally-quick-but-possibly-sometimes-slow methods: | a) throw InterruptedException, | b) translate the InterruptedException into a RemotingException (and keep the thread's interruption status set), | or c) just run uninterruptably (and propagate the thread's interruption status)? | IMO I like option A for everything that is obviously I/O, and option B for anything very high-level, but using a subclassed exception in case someone wants to handle it still. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085741#4085741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085741

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