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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch_Stable will be unstable for a while...

by bstansberry＠jboss.com

What's your estimate for having 1.4.1.Beta2 in AS 5 trunk? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141519#4141519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141519

18 years

1
0
0 / 0

[Design of Security on JBoss] - Re: U Prove, sso holy grail?

by anil.saldhana＠jboss.com

Kim Cameron's concept of an Identity Meta System is very interesting and appropriate for the myriad tech/specs that float around in the name of IdM. He provided an analogy of how there was ethernet, token ring etc etc in networking long long and then there came a TCP/IP based meta system to shield the underlying protocols/tech. But I am unsure whether card space is the right direction to reach that meta system. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141518#4141518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141518

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Branch_Stable will be unstable for a while...

by clebert.suconic＠jboss.com

I'm working with the AOP team on getting a version of AOP 2 that works with JBM. If it takes more than 1 or 2 days, I will revert the changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141515#4141515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141515

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by bstansberry＠jboss.com

LOL. I pick #1 or #3. :-) #4 isn't an option -- the code's in EAP; it's supported. #3 seems to be along the lines of the standard policy in EAP; we don't just fix everything we think of, since the fix could introduce other issues. We are conservative. Would #1 be that bad? You create ExtendedHASingletonElectionPolicy with the missing methods from the AS 5 API. If the injected policy implements Extended, you invoke on it the way AS 5 does. Otherwise it gets used as it is now. In ExtendedHASingletonElectionPolicy javadoc, any HASingletonElectionPolicy methods that don't get called anymore should have comments noting that fact. Don't get me wrong; I can see how it would get messy. #3 is OK. I know you did a lot of refactoring to tighten things up in trunk, i.e. with HASingletonElectionPolicyBase; that doesn't need to happen in 4.x, and *shouldn't* happen if it might break some custom subclass. HASingletonElectionPolicySimple just needs to work correctly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141508#4141508 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141508

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by galder.zamarreno＠jboss.com

Re: http://jira.jboss.com/jira/browse/JBAS-5155 The other day was looking into the possibility of having this fixed in AS 4.x. There's 2 (well 4 really) ways this can be fixed: 1.- Add new API that allows either: a) passing the singleton name to the HASEP so that DRM can be queried, or b) passing a List to pickSingleton() with the ClusterNodes where the singleton is deployed. 2.- Use setManagedSingleton() as a way to pass the String version of the singleton name which is later used to query the DRM. It's got HACK written all over it, but we can do an instanceof for String within it in case someone out there calls this. One thing is for sure, a HASingleton can't be an instanceof String. This safes us the possibility of having to add new API in 4.x and all the trouble associated with it. 3.- Is it worth fixing this? Hmmmm, we haven't advertised this much which is good in some ways, but any day, someone running 4.x could come and report this to us in a support case. 4.- I guess we could take the add HA Singleton Election Policy functionality as experimental and hence not supported in 4.x. This could safe us a lot of headaches. My preference right now is with either 2 or 4. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141498#4141498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141498

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Listen address of JBossTS ports not configurable

by mark.little＠jboss.com

This is an old discussion. There are JIRAs covering this. Monitor those for progress. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141488#4141488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141488

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Listen address of JBossTS ports not configurable

by phufnag

anonymous wrote : JBossTS opens a bunch of network ports (three, I think, but debug output only mentions two) it listens on, but JBossTS does not give me the option to specify at which address it listens for connections. | | As such, this is not a bug or error. However, standard practice in practically every single network listening software is to give the option for the administrator to specify at which address the software listens on. JBoss AS also gives this option, it even has a global system property jboss.bind.address, and every single service except JBossTS can be separately configured to listen on a particular address, and by default the services usually are configured to listen on ${jboss.bind.address}. I have to echo this sentiment, as far as configurability. At present, we run WebSphere6 (on the machine base address), and jboss4.0/4.2 on secondary IP's on our systems (with the plan of migrating everything to jboss eventually). While setting up 4.2 for migrating (4.0->4.2) for our apps, I'm also moving away from "IP per jvm" which we were doing for 4.0 (ugly, having to plumb a new IP for every jvm) to "port range per jvm" - every jboss 4.2 instance running on eth0:1, with a port range where 42009 would be AJP/JK, 42099/42098 for jnp/jndi, etc (420xx for that particular jvm - range of 100 ports 00-99 for each jvm, trying to keep the last 2 digits from the 'default' ports, and room for any new features that may creep in with future jboss releases). The sticking point here is JbossTS/Arjuna, which doesn't allow a unique port to be assigned for a particular instance. I've already had (just today) one new jvm we couldn't start, because TS on another instance "happened" to randomly grab port 44209 (which would be the AJP port for the new instance). Had to bounce another app to get it to use a different port for TS, so I could start the new one. Luckily still in our "QA" environment, because that would be *unacceptable* in a live production environment (to bounce a "live" running prod app, because its "random" port is preventing another from starting). For now, I've set (linux): net.ipv4.ip_local_port_range="49000 65000" ... to keep the "random" ports out of the way of other applications, however it would be far preferable to be able to specify the ports and keep them within the specified range for the particular jvm. (side note here, jboss portal had hardcoded 1100/1098/1099 ports in one of the XML files that had to change too - the assumption that every jvm will run on a unique IP with fixed ports based on ${jboss.bind.address} is really a bad one, yet seems to be a 'presumption' in most of the jboss packages - while an easy fix (one XML - where I replaced them with -D cmd line variables so we can map for each instance), the idea of being able to control port mappings at the least for *every* service can be very important, especially from a security/firewalling perspective. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141479#4141479 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141479

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - New jboss-cluster-dev mail list

by bstansberry＠jboss.com

FYI, we've created a new jboss-cluster-dev(a)lists.jboss.org mail list. This is meant to be a general cross-project list for discussion of clustering issues that may impact multiple JBoss projects (e.g. JGroups, JBC, JBM, AS). A number of the more meaningful clustering-related discussions seem to happen on e-mail threads; often on the jbosscache-dev list. But when the subject matter extends beyond JBC specifics, either other folks uninterested in JBC miss the discussion, or the thread ends up going private. Both are bad. This list is meant to be place to hold these discussions. My intent is for this to be a pretty low volume list, focused solely on cross-project issues. Anyone who regularly follows this forum is encouraged to subscribe. In order to keep the volume on the mail list low, my intent is to continue to use this forum for purely AS-centric discussions (e.g some dev work on HAPartition or something). If a discussion isn't meaningful to projects other than JBoss AS, let's keep it here. Please see https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev if you wish to subscribe. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141478#4141478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141478

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Maven release artifacts

by pgier

"richard.opalka(a)jboss.com" wrote : "heiko.braun(a)jboss.com" wrote : I am looking for a smart way to hook into that without having to migrate our build completely. | I agree. We have to deal with the integration issue. I would do it in the way we do it now in our spy, just release it to local maven repository and force developer to commit it there manually ;) Just wanted to add that this is currently the only way to deploy to the maven releases repository (i.e. deploy locally and then commit to svn). This page has some information about how to commit to the maven repository (http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenReleaseRepository) Please use the maven deploy plugin or the ant tasks when deploying to the repository, so that the correct metadata is generated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141468#4141468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141468

18 years

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-5278 Errors .

by clebert.suconic＠jboss.com

This is a JCA adapter bug. I - org.jboss.resource.adapter.jms.JmsManagedConnection doesn't know if JmsXA supports XA or not II - JBossMessaging Connection Factories will implement both XAConnectionFactory and ConnectionFactory (BTW: There is nothing wrong with this. This is just an implementation point). III - JmsManagedConnection will use an instanceof to determine if it should open an XA or a regular transaction: You will find lots of things like: | if (con instanceof XATopicConnection) | { | xaTopicSession = ((XATopicConnection)con).createXATopicSession(); | topicSession = xaTopicSession.getTopicSession(); | xaTransacted = true; | } | else if (con instanceof TopicConnection) | { | topicSession = | ((TopicConnection)con).createTopicSession(transacted, ack); | if (trace) | log.trace("Using a non-XA TopicConnection. " + | "It will not be able to participate in a Global UOW"); | } | Instead of relaying on the implementation details of the ConnectionFactory, IMO JCA should be extending JmsConnectionRequestInfo to determine if the request is for a XA or a non XA connection. I believe this would be an issue with other JMS implementations as well (besides JBossMQ). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141467#4141467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141467

18 years

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 April 2008