September 2007 - jboss-dev-forums

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

I don't think the ClientDeployer/ClientMetaData will exist once the metadata project is in use. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086609#4086609 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086609

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LoadMessages problem during merge...

by timfox

This is an old one http://jira.jboss.com/jira/browse/JBMESSAGING-908 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086600#4086600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086600

18 years, 6 months

1
0
0 / 0

[Design of JBoss Build System] - Snapshot thirdparty dependencies

by pete.muir＠jboss.org

I'm starting to look at deploying snapshots of Seam to snapshots.jboss.org. We have a lot of dependencies which aren't in the jboss repositories (some aren't in any repository) which are released dependencies. Should these go in the snapshots.jboss.org repository or should I do a check in to repository.jboss.org for these to start with? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086595#4086595 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086595

18 years, 6 months

1
0
0 / 0

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

by richard_opalka

"palin" wrote : 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 ;-) | RM subsystem will be hooked to the whole invocation framework, it will consists of handlers, transport wrappers, database based store and other entities. It won't be implemented on the transport layer only. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086566#4086566 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086566

18 years, 6 months

1
0
0 / 0

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

by richard_opalka

"heiko.braun(a)jboss.com" wrote : Could it be that you require fine grained control over the transport? | I.e. dealing with return codes and continuation? Is that the reason you chose the RemotingConnectionImpl.java? Yes Heiko, you're absolutely right. I need the full control over the transport layer. "heiko.braun(a)jboss.com" wrote : Another drawback is that the RemotingConnection is only available on the client side. How is the server side dealing with it? I'm working on client side only in present. When I will code and think about the server side I will clarify my decisions. Maybe I will change my mind during the development. For now I study a lot of JBossWS code and can't tell you how I will really implement it finally. Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086562#4086562 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086562

18 years, 6 months

1
0
0 / 0

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

by richard_opalka

I'll do the clarification first. What is the RM subsystem for me? * RM JAXWS handlers communicating with RM store * RM Channel (as drawn on the picture above) communicating with RM store too (represents reliable transport wrapper for me only) * RM store (database based persistent store) * RM sender/receiver used by RM channel and RM handlers too What is the above picture about? It's only about reliable resending of processed and accepted messages on the transport level. Alessio and Heiko ask me why I decided to put RM channel to the RemotingConnectionImpl and not to the handler? My answer is: RM sender must be placed on top of transport layer because of his resending capability. I can't put it to the JAXWS handler. If I would do it, the problem could be with WS-Security (next JAXWS handler that could be in the chain). If I would communicate with transport layer directly from RM handler, WS-Security handler wouldn't be called at all and thus WS security wouldn't be supported in combination with WS-RM. Thus what I need is to ensure that all handlers in the handler chain are executed, and then, on transport layer RM channel will accept such completely processed outgoing messages and resend them. I hope it's now more clear for you now ;-) Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086553#4086553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086553

18 years, 6 months

1
0
0 / 0

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

by richard_opalka

"palin" wrote : | 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. | There's a lot of issues related to the Cluster vs. Web Services. First of all I need to say that clustered environment is the most suitable for stateless web services. It's because if you have stateless services, you do not need to replicate sessions and cluster manager can forward message to any cluster node of his choice. The situation becomes complicated if your web service isn't stateless (and each RM enabled endpoint isn't stateless). Imagine the situation you have RM receivers running on multiple cluster nodes. What you can do in such situation? In real life there is the loadbalancer in the front of cluster and if you have the good one it is cookies aware. Thus the solution for clustered RM environment is: * use cookies aware loadbalancer in the front of cluster * all your RM endpoints (hosted on cluster nodes) must be cookies aware * your cluster must be able to replicate the sessions and cookies * use clustered database (where RM messages are stored) * your cluster can't be hidden behind the filewall If you will meet all these preconditions I don't see the problem to have clustered RM ;-) Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086524#4086524 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086524

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JIRA JBAS-4732: RmiBindAddress attrribute missing for HA

by twenckebach

As an addition to the "PS" statement: RMI uses java.rmi.server.hostname for construction of the remote reference which is passed to the client during JNDI lookup. So, if RmiBindAddress != java.rmi.server.hostname, the client gets an exception View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086496#4086496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086496

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JIRA JBAS-4732: RmiBindAddress attrribute missing for HAJNDI

by twenckebach

Hello, I opened JIRA JBAS-4732 and was asked to open a forum thread in addition. That was my description: anonymous wrote : | For multihomed servers, it is essential to be able to bind JBoss services to dedicated interfaces (bind address). This requirement is fulfilled by jboss service Naming, and all other services known to the author, but not HAJNDI. | Since this is an inconsistency in implementing the design, I classify this to be a bug. | | Affected source files: | $JBOSS_SRC/cluster/src/main/org/jboss/ha/jndi/HANamingServiceMBean.java | $JBOSS_SRC/cluster/src/main/org/jboss/ha/jndi/HANamingService.java | Comment by Brian Stansberry [17/Sep/07 10:30 AM] anonymous wrote : | HANamingService exposes attributes "BindAddress" and "AutoDiscoveryBindAddress", both of which are by default set to whatever you set the -b startup switch to. Same as Naming and everything else. | Please open a forum thread to discuss if you are having issues with this. | Here we go: The point is, that the world is not so simplistic that it would be always enough to just modify jboss.bind.address and the problem of multihoming is solved. What if we want to bind different JBoss services to different LANs? AutoDiscoveryBindAddress is only a solution if multicast is available, which cannot be assumed. I think you as providers of a general platform should simply acknowledge that there is such a requirement in the outside world and provide the possibility to define service binding to IP addresses in a per-service granularity. PS: It should be noted, that it is a very weak concept of RMI which comes into play, if RmiBindAddress of Naming is not modified via the -b option, but directly in the XML file (already supported today). RMI allows to explicitely define the port where a server shall be exported, but not the IP address. To this end, JBoss uses a server socket factory (rg.jnp.server.Main.initJnpInvoker()), which is used on creation of the socket: DefaultSocketFactory passes RmiBindAddress to the constructor of ServerSocket. However, RMI doesn`t know which IP address the such created socket was bound to, but instead relies on the system property java.rmi.server.hostname. JBoss does not check in the socket factory that the system property is set accordingly, either. If not set, RMI internally uses | InetAddress.getLocalHost().getHostAddress() | (sun.rmi.transport.tcp.TCPEndpoint.java), which may very well be different from RmiBindAddress. Even worse, if such an RmiBindAddress is also configurable for HAJNDI, it must be assured by someone ("the JBoss user") that it equals RmiBindAddress defined for Naming (there is only one value possible for java.rmi.server.hostname!). This should be checked during JBoss startup. Note that this remark is not really an argument against introducing RmiBindAddress for HAJNDI, since the same issue exists for all other RMI servers, including JRMPInvoker and JRMPInvokerHA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086495#4086495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086495

18 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JAXBIntros, backwards-compatibility with 2.0.0

by tfennelly

That's great. Thanks Heiko :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086492#4086492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086492

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