July 2007 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4276 Discussion Thread

by bstansberry＠jboss.com

This bumps into the "who guarantees the HAPartition and the Cache are using the same channel" problem. Independently injecting them puts the burden on the person writing the config file; i.e. there is no software enforcement. I've been tempted several times to go that way. But my gut always tells me it's a mistake. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063517#4063517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063517

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - current logged users

by sviluppatorefico

maybe useful a portlet to see the current users online View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063510#4063510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063510

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4276 Discussion Thread

by JerryGauth

I haven't fully digested your comments yet but upon review of the existing implementation, it looks like a simpler solution may be viable. What about injecting the cache instance into HA-JNDI, similar to what we now do for DistributedState? This should eliminate any need for HA-JNDI to invoke getClusteredCache(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063502#4063502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063502

18 years, 9 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: jaxb whitepsace handling

by adrian＠jboss.org

The example you post is NOT valid, your missing the managed-connection-factory-class element. Have you enabled validation on the parser? You'll need it if you want whitespace collpasing by the parser because its gots to read the schema to find out the datatype. e.g. in your case it should be | <connection-definition> | <managed-connection-factory-class> | org.jboss.resource.adapter.jms.JmsConnectionFactory | </managed-connection-factory-class> | </connection-definition> | managed-connection-factory-class is a j2ee:fully-qualified-classType which is a j2ee:string which is a token. See javaee.xsd | <xsd:complexType name="string"> | <xsd:annotation> | <xsd:documentation> | | This is a special string datatype that is defined by Java EE as | a base type for defining collapsed strings. When schemas | require trailing/leading space elimination as well as | collapsing the existing whitespace, this base type may be | used. | | </xsd:documentation> | </xsd:annotation> | <xsd:simpleContent> | <xsd:extension base="xsd:token"> | <xsd:attribute name="id" type="xsd:ID"/> | </xsd:extension> | </xsd:simpleContent> | </xsd:complexType> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063499#4063499 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063499

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: JBoss/JCA Maven Build

by adrian＠jboss.org

Snapshots are no longer in the main repository. And the jar is called jboss-kernel.jar now. It's only dependent on the MC for configuring the tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063491#4063491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063491

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4276 Discussion Thread

by bstansberry＠jboss.com

I'm going to think out loud here, as this gets into an area where things aren't too clean. Apologies in advance for what I'm sure will ramble on.... I tend to think things through in writing. ClusterPartition is really playing two roles right now: 1) It's an impl of HAPartition that uses JGroups as an implementation detail. This is it's primary function. 2) There are services that use HAPartition for group RPCs and a JBC instance for maintaining shared state. These services need a guarantee that the HAPartition and the JBC instance are using a consistent underlying group comm layer (i.e. the group members for the HAPartition and for the cache are the same). ClusterPartition is acting as a guarantor. If you call getClusteredCache() and getHAPartition(), the two services are guaranteed to be using the same underlying JChannel. ClusterPartitionMBean should really just be a management interface for ClusterPartition -- i.e. something used by management tools like JBoss Operations Network or jmx-console. It shouldn't be used by clients like HA-JNDI. It also really shouldn't expose methods not needed by the mgmt tools. In this respect, ClusterPartitionMBean is pretty reasonable as a mgmt interface. The suspect methods are getClusteredCache(), getDistributedStateService() and getHAPartition() -- it's not clear what a mgmt tool would do with those methods. getMultiplexer() could be on the suspect list too, although I could see how a tool might want to navigate from ClusterPartitionMBean to the ChannelFactory. So, HA-JNDI shouldn't be using the mgmt tool interface to call getHAPartition() and getClusteredCache(). Which gets us to your question: what should it be using: 1) Don't want to add getClusteredCache() to HAPartition. We could (and should) have a separate discussion about what HAPartition is/should be. But in general its an abstraction of a group RPC layer, somewhat intended to hide JGroups. It then has two services bolted on via getters (DRM and DistributedState). Those really don't have anything to do with the RPC functionality other than since the interface clubs them together a client can assume the DRM/DS and RPCs are using the same underlying group comm channel. Hmm -- sounds familiar. Adding another getter to expose JBC further confuses things by pushing HAPartition away from its core function as a group RPC abstraction. It also goes against the idea that HAPartition hides JGroups. JBC is very much tied to JGroups. 2) Inject HAPartition, cast to ClusterPartition and make the getClusteredCache() call. Nah. 3) For DetachedHANamingService, injection type is ClusterPartition instead of HAPartition. Remove the attribute from DetachedHANamingServiceMBean -- tools don't need it; the microcontainer does, and a public method on the class itself is all the MC needs. The fact that ClusterPartition is injected into the service impl is an implementation detail. This solves the problem of HANamingService making calls against ClusterPartitionMBean. 4) Make a new interface that encapsulates the "guarantor of consistent HAPartition and JBC" function. (I have no good name for it.) Exposes getHAPartition() and getClusteredCache(). ClusterPartition can implement this interface. For DetachedHANamingService, injection type is this interface. This use of an interface leaves us free to refactor someday and break ClusterPartition's two roles into separate classes. I'm inclined toward #4. #3 seems OK for the immediate task but if we do it we should add a subtask to JBAS-4276 to look at it again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063467#4063467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063467

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Providing bean name aware feature

by alesj

Regarding this issue: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063062#4063062 I'm thinking of adding name-method attribute to bean and beanfactory. e.g. | <bean name="MyName" class="org.jboss.test.XBean" name-method="applyName" /> | | public class XBean | { | ... | | public void applyName(String name) | { | ... | } | I'll apply the name in Configured state (ConfigureAction). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063443#4063443 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063443

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: JBoss/JCA Maven Build

by vickyk

The Maven Build for the jboss-jca is dependent on the jboss-microcontainer , I don't see the jboss-microcontainer.jar at http://repository.jboss.com/maven2/jboss/jboss-microcontainer/2.0.0-SNAPS... Looks like it is missing . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063437#4063437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063437

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMSHeader fields

by mark.little＠jboss.com

"beve" wrote : I'm a bit concerned about the connection variable. I looks like this should be a connection factory, but should it be normal one or a clustered connection factory. Maybe I should get this from the configuration file? | The current code seems to obtain it via the configuration file. Best to stick with that for now IMO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063420#4063420 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063420

18 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Optional input for AbstractSimpleVFSRealDeployer

by wolfc

http://jira.jboss.com/jira/browse/JBMICROCONT-193 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063414#4063414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063414

18 years, 9 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 July 2007