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

[Design of JBoss ESB] - JBossESB JAAS Integration

by anil.saldhana＠jboss.com

I was looking for the current JAAS integration that exists in JBossESB and google search pointed me to the following: http://anonsvn.labs.jboss.com/labs/jbossesb/workspace/platform/soa_tags/S... Primarily, the file that I looked at was JaasSecurityService.java http://anonsvn.labs.jboss.com/labs/jbossesb/workspace/platform/soa_tags/S... Is this the correct file? I see that there is a direct reference to a Sun JDK class. :) This may be an issue with different JDKs. import com.sun.security.auth.login.ConfigFile; | Is there a location where more information on the declarative security can be found? Like a wiki etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186849#4186849 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186849

15 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - expected behavior on switching layout

by prabhat.jha＠jboss.com

When you switch from 3 column layout to say 1 column layout, we show the portlets in center column which I think is a good default behavior. Although we don't show the other two columns, the portlets in that column are still operational in terms of rendering. 1. Should we not give a warning to the user/admin when changing layout where information gets hidden? 2. If we keep this approach, should not our rendering logic be smart not to go through the render call? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186823#4186823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186823

15 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: remoting-jboss-beans.xml

by scott.stark＠jboss.org

"ron.sigal(a)jboss.com" wrote : | 1. Currently, an instance of org.jboss.remoting.network.NetworkRegistry is created, but I don't think we need it. | | a. NetworkRegistry is used by an instance of a subclass of org.jboss.remoting.detection.AbstractDetector to store information about known instances of org.jboss.remoting.transport.Connector. But the JNDIDetector in remoting-service.xml is commented out by default. | | b. It looks like the only part of the Application Server that uses the Remoting detection service is Tom's jmx-remoting package, which, I believe, is used only in the presence of jdk 1.4, which should never apply to AS 5. | | I checked with Tom, and his memory was a little fuzzy but he thought I was right. Does anyone remember how jboss-service.xml happened to have a NetworkRegistry and no JNDIDetector? | This has been there since AS5 was using jdk1.4, so I'm sure its just for the jmx remoting integration work. "ron.sigal(a)jboss.com" wrote : | 2. If I understand correctly, setting "registerDirectly" to "false" in org.jboss.aop.microcontainer.aspects.jmx.JMX would be more semantically consistent with MBeans in older versions of AS. Do we have a policy about that for beans derived from existing MBeans? | Looking at the JMXIntroduction, its not a question of different semantics, its a question of whether not the underlying bean is a JMX compatible bean. If it is, it can be registered directly, otherwise its wrapped in a StandardMBean with the JMX annotation specified interface. POJOs with *MBean interfaces can be registered directly, simple POJOs that don't match the default jmx interface conventions cannot. "ron.sigal(a)jboss.com" wrote : | 3. As MBeans are transformed into POJOs, should the names in binding.xml be updated to refer to the POJO names? Does it matter? | Generally I would say yes, but if there are dependencies on the mbean name it should be exposed either using the JMX annotation, or using a alias element in the bean deployment. 4. I've named the "jboss.remoting:service=Connector,transport=socket" Connector "UnifiedInvokerConnector", which isn't strictly appropriate, now that it has the JSR88 handler as well. Any suggestions for a better name? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186818#4186818 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186818

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA resource and setting the timeout

by timfox

Take a look at RemotingServiceImpl to see how we do something similar. There's a timer that scans the connections and fails one where no ping has arrived. You could do something very similar (copy and paste). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186817#4186817 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186817

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA resource and setting the timeout

by timfox

I'd also test that time outs work after server is restarted and prepared txs are reloaded. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186812#4186812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186812

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA resource and setting the timeout

by timfox

Also ResourceManagerImpl::timeoutSeconds is only being set via the setTimeout method. This means if the transactionmanager never calls setTimeout() it will always be zero. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186811#4186811 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186811

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA resource and setting the timeout

by timfox

Looking at the code committed today for this. I notice a new TxTimeoutHandler is being created for every transaction. I don't think this scales and is unnecessary. Instead we should have a single thread that scans the transaction map every x seconds/milliseconds and times transactions out that way. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186807#4186807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186807

15 years, 7 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - remoting-jboss-beans.xml

by ron.sigal＠jboss.com

I'm working on moving the Remoting related stuff in AS from deploy/remoting-service.xml to deploy/remoting-jboss-beans.xml, and I have a few questions. A skeletal version of remoting-jboss-beans.xml is appended below. 1. Currently, an instance of org.jboss.remoting.network.NetworkRegistry is created, but I don't think we need it. a. NetworkRegistry is used by an instance of a subclass of org.jboss.remoting.detection.AbstractDetector to store information about known instances of org.jboss.remoting.transport.Connector. But the JNDIDetector in remoting-service.xml is commented out by default. b. It looks like the only part of the Application Server that uses the Remoting detection service is Tom's jmx-remoting package, which, I believe, is used only in the presence of jdk 1.4, which should never apply to AS 5. I checked with Tom, and his memory was a little fuzzy but he thought I was right. Does anyone remember how jboss-service.xml happened to have a NetworkRegistry and no JNDIDetector? 2. If I understand correctly, setting "registerDirectly" to "false" in org.jboss.aop.microcontainer.aspects.jmx.JMX would be more semantically consistent with MBeans in older versions of AS. Do we have a policy about that for beans derived from existing MBeans? 3. As MBeans are transformed into POJOs, should the names in binding.xml be updated to refer to the POJO names? Does it matter? 4. I've named the "jboss.remoting:service=Connector,transport=socket" Connector "UnifiedInvokerConnector", which isn't strictly appropriate, now that it has the JSR88 handler as well. Any suggestions for a better name? Thanks. =============================================================================== | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | <bean name="UnifiedInvoker" class="org.jboss.invocation.unified.server.UnifiedInvoker"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=invoker,type=unified",exposedInterface=org.jboss.invocation.unified.server.UnifiedInvokerMBean.class,registerDirectly=true)</annotation> | <property name="connector"><inject bean="UnifiedInvokerConnector"/></property> | <depends>TransactionManager</depends> | </bean> | | <bean name="UnifiedInvokerConnector" class="org.jboss.remoting.transport.Connector"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.remoting:service=Connector,transport=socket",exposedInterface=org.jboss.remoting.transport.ConnectorMBean.class,registerDirectly=true)</annotation> | <property name="serverConfiguration"><inject bean="UnifiedInvokerConfiguration"/></property> | </bean> | |  | <bean name="UnifiedInvokerConfiguration" class="org.jboss.remoting.ServerConfiguration"> | <constructor> | <parameter>socket</parameter> | </constructor> | |  | <property name="invokerLocatorParameters"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> | <entry><key>serverBindAddress</key> <value>${jboss.bind.address}</value></entry> | <entry> | <key>serverBindPort</key> | <value> | <value-factory bean="ServiceBindingManager" method="getStringBinding"> | <parameter>jboss.remoting:service=Connector,transport=socket</parameter> | <parameter>${port}</parameter> | </value-factory> | </value> | </entry> | <entry><key>dataType</key> <value>invocation</value></entry> | <entry><key>marshaller</key> <value>org.jboss.invocation.unified.marshall.InvocationMarshaller</value></entry> | <entry><key>unmarshaller</key> <value>org.jboss.invocation.unified.marshall.InvocationUnMarshaller</value></entry> | </map> | </property> | |  | <property name="serverParameters"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> |  | </map> | </property> | | <property name="invocationHandlers"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> |  | <entry><key>JSR88</key> <value>org.jboss.deployment.remoting.DeployHandler</value></entry> | </map> | </property> | </bean> | | </deployment> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186799#4186799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186799

15 years, 7 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - move lib-opt under the corresponding deployer

by dimitris＠jboss.org

I was discussing again with Ales the server/xxx/lib-opt directory we've added a while back, and it seems to me a lot more appropriate to put any conditionally enabled .jars together with the corresponding deployer. I.e. deployers/seam.deployer/lib/jboss-seam-int-jbossas.jar With the proper classloading settings this lib, or other versions of it, should be conditionally put in the classpath by the seam deployer. This makes the deployer more self-contained and removes the extra directory bloat. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186791#4186791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186791

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by ataylor

anonymous wrote : I'd like to know if there was any difficulty in implementing HTTP on top of Netty so that I can make the Netty API more user-friendly. :) The API was cool Trustin. Especially the ReplayingDecoder, it makes decoding complex messages much easier. anonymous wrote : 1) IIUC, HTTP allows multiple headers with the same key. It seems like the current HttpMessage interface assumes there's only one value per key. Therefore, the headers should be represented as Set<String, List> instead of Map<String, String>. Ok, thats done and ive changed the API. anonymous wrote : 2) HTTP allows multiple parameters with the same key. Therefore, the parameters should be represented as Set<String, List> instead of Map<String, String>. (Same with the issue 1) also done anonymous wrote : 3) I'm not sure if a multi-line header is decoded correctly: no, you are correct. If i understand this correctly it should be as follows. A header valu ecan be on multiple lines if the next line starts with a space or tab, so: aheader: abcdefg | hij would be the same as: aheader: abcdefghij also multiple values are seperated by a comma, i.e. aheader: a,b,c actually has 3 values a, b and c. The caveat here is Date type headers such as Date, Expires etc as they have commas within them. anonymous wrote : 4) Reason (error message) is missing in HttpResponse. HttpResponseStatusCode already has the pre-defined reason phrases, but it should be customizable on a per-response basis. (Perhaps we could simply make the HttpResponseStatusCode constructor public?) enums can't have public constructors so ive added another static method for overriding the reason description. anonymous wrote : 5) What about renaming HttpProtocol to HttpVersion? P of HTTP already stands for 'protocol'. Also, HttpRequest.get/setProtocol() needs to be renamed to get/setVersion() or get/setProtocolVersion(). I agree, done. anonymous wrote : 6) java.net.URI already has a query property. I think we don't need the parameter accessor methods in the HttpRequest interface. We could provide a helper class like UriBuilder later. not sure i follow completely, i need the URI for encoding purposes so i need an accessor. Unless you meant replace it with a String? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186790#4186790 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186790

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