December 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Remoting, Unified Invokers] - Re: Better support for multi-homing

by tom.elrod＠jboss.com

Good idea. http://jira.jboss.com/jira/browse/JBREM-643 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991522#3991522 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991522

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - JBoss Portal 2.4.0 source org.jboss.portal.portlet.PortletRe

by vietanh.vu

Hi everyone, In this file, at line 210 | if (type == ACTION_TYPE) | { | this.navigationalstate = null; | this.interactionState = query; | this.form = form; | } | else | { | this.navigationalstate = query; | this.interactionState = null; | this.form = null; | } | I don't know if the this.form is deliberately set to null in this case. It means that if the user requests the portlet in render mode, it will discard all form data. For example, | <form action="<portlet:renderURL/>" method="post"> | <input type="hidden" name="xxx" value="1"/> | </form> | when user submit this form, the xxx=1 will be discarded completely. Is it a bug, or a feature? http://vpensieve.blogspot.com/2006/12/jboss-portal-240-revisit.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991514#3991514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991514

18 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Unifying the remoting transport in jbossas

by scott.stark＠jboss.org

Why shouldn't we integrate the ejb3 transport handler into the main connector unning on port 4446 rather than creating a separate socket? | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.remoting:service=Connector,transport=socket" | display-name="Socket transport Connector"> | ... | <handlers> |  | <handler subsystem="invoker">jboss:service=invoker,type=unified</handler> | <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler> | </handlers> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991507#3991507 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991507

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Proposed new package structure

by thomas.diesler＠jboss.com

Folks, the current package structure is becomming a little clutterd. I propose the following change to top level packages | org.jboss.ws.common | org.jboss.ws.common.api | org.jboss.ws.common.metadata | | org.jboss.ws.core | org.jboss.ws.core.jaxrpc | org.jboss.ws.core.jaxws | | org.jboss.ws.extras | org.jboss.ws.extras.addressing | org.jboss.ws.extras.eventing | org.jboss.ws.extras.policy | org.jboss.ws.extras.security | org.jboss.ws.extras.xop | | org.jboss.ws.integration | org.jboss.ws.integration.jboss40 | org.jboss.ws.integration.jboss50 | org.jboss.ws.integration.tomcat | | org.jboss.ws.tools | Further refactoring would be necessary such that * core only has a dependency on common, so has tools. * core does not have a dependency on tools. When this is done, we move common and tools in their respective modules that then can be reused accross branches. Shortly we will have a third branch to maintain jbossws-1.2, wich is targeted for jboss-4.2.x. This can only be done efficiently if the code bases do not divert more than necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991503#3991503 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991503

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Multithreaded services and their EPR(s)

by mark.little＠jboss.com

I don't think it's possible to do this for the GA. There are too many unknowns that we would need to solve in order to do this correctly (e.g., what protocol for the heartbeat, how long should you wait etc.) I believe Kurt said there was a UDDI admin console that we could use? If that's the case then we can add something to the documentation that tells the administrator (or even a client) to use this when they suspect and EPR points to a service that is no longer available. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991483#3991483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991483

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Configuration - normalization

by mark.little＠jboss.com

It looks fine and we should definitely proceed with this for the GA. It will change once we move towards the container approach and I'd like to be able to offer service drop-ins for the ESB: individually deployable entities. This may mean that there's no such thing as a configuration "file" as we know it, but that's something for post GA. One thing though: | <buses> | <bus name="bank-jms-channel" server="fileBankServer" resourceType="QUEUE" userName="" password=""/> | <bus name="bank-ftp-channel" server="inhouse-jboss-4.0.4" resourceType="FTP" userName="kurt" password="secret"/> | </channels> | Do I get points for spotting the deliberate mistake ;-)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991480#3991480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991480

18 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: SEAM / Java 5

by kukeltje

I agree, lets keep 3.2 as it is. 3.3 maybe... Maybe we should do a poll in the userforum? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991476#3991476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991476

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: High-level scoping of Security for JEE5

by scott.stark＠jboss.org

The way this needs to be done in both ejb2/ejb3 is that the method permission metadata is made available for a security aspect to create the permissions from. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991468#3991468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991468

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Better support for multi-homing

by scott.stark＠jboss.org

Consider this connector config: | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.remoting:service=Connector,transport=Socket" | display-name="Socket transport Connector"> | | <attribute name="Configuration"> | <config> | | <invoker transport="socket"> | <attribute name="numAcceptThreads">1</attribute> | <attribute name="maxPoolSize">303</attribute> | <attribute name="clientMaxPoolSize" isParam="true">304</attribute> | <attribute name="socketTimeout">60000</attribute> | <attribute name="serverBindAddress">192.168.0.82</attribute> | <attribute name="serverBindPort">6666</attribute> | <attribute name="clientConnectAddress">216.23.33.2</attribute> | <attribute name="clientConnectPort">7777</attribute> | <attribute name="enableTcpNoDelay" isParam="true">false</attribute> | <attribute name="backlog">200</attribute> | </invoker> | | <handlers> | <handler subsystem="mock"> | org.jboss.remoting.transport.mock.MockServerInvocationHandler | </handler> | </handlers> | </config> | </attribute> | | </mbean> | What I would like to see supported is | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.remoting:service=Connector,transport=Socket" | display-name="Socket transport Connector"> | | <attribute name="Configuration"> | <config> | | <invoker transport="socket"> | <attribute name="numAcceptThreads">1</attribute> | <attribute name="maxPoolSize">303</attribute> | <attribute name="clientMaxPoolSize" isParam="true">304</attribute> | <interfaces> | <interface name="eth0"> | <attribute name="socketTimeout">60000</attribute> | <attribute name="serverBindAddress">192.168.0.82</attribute> | <attribute name="serverBindPort">6666</attribute> | <attribute name="clientConnectAddress">216.23.33.2</attribute> | <attribute name="clientConnectPort">7777</attribute> | <attribute name="enableTcpNoDelay" isParam="true">false</attribute> | <attribute name="backlog">200</attribute> | </interface> | <interface name="eth1"> | <attribute name="socketTimeout">60000</attribute> | <attribute name="serverBindAddress">192.168.10.10</attribute> | <attribute name="serverBindPort">6666</attribute> | <attribute name="clientConnectAddress">216.23.10.2</attribute> | <attribute name="clientConnectPort">7777</attribute> | <attribute name="enableTcpNoDelay" isParam="true">false</attribute> | <attribute name="backlog">200</attribute> | </interface> | </interfaces> | </invoker> | | <handlers> | <handler subsystem="mock"> | org.jboss.remoting.transport.mock.MockServerInvocationHandler | </handler> | </handlers> | </config> | </attribute> | | </mbean> | so that there is an explicit notion of multi-homing for the handler. A problem with the current legacy and remoting connectors is that setting up multiple interfaces requires multiple connectors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991457#3991457 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991457

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: High-level scoping of Security for JEE5

by anil.saldhana＠jboss.com

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/JEE5_TCK/ejb3... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991455#3991455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991455

18 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006