January 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Transaction Services] - Re: ClientUserTransaction and the JTS

by mark.little＠jboss.com

How can you change the tpc implementation? It's based on the standard from the OTS so we have no room for changing that, unless you mean that we should restrict distributed transactions from running in the client? We could (have in the past) always produce a thin-tx-client jar that knows only about the OTS.idl classes and how to manipulate that in the client abstractly, i.e., without having to have access to JBossTS implementation specific classes, but it could become a management nightmare. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200579#4200579 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200579

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: jta/jts jar/config file change

by mark.little＠jboss.com

This gets my vote! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200577#4200577 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200577

17 years, 2 months

1
0
0 / 0

[Design of JBoss Profiler] - JBoss Profiler 2 Results

by fatlog

hi, i've setup JBoss Profiler 2 on JBOss 5.0.0.GA and have it working fine. I can see all the log files etc... I need to profile an application and am having a little trouble interpreting the results in the log files. Is there any good articles on JBoss Profiler 2? For example, in the threads folder each thread has a break-down of mthods called. These are seperated into 'Frames'. What are the frames? thanks in advance for any advice View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200576#4200576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200576

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - ClientUserTransaction and the JTS

by jhalliday

I'm starting to investigate AS 5 testsuite failures with the server running in JTS mode rather than with the default JTA. First up: ClientUserTransaction is barfing because the transaction propagation context (tpc) used by the JTS contains classes from the JTS implementation that are not present on the client classpath. The RMI classloader does not have a policy to permit them to be remote loaded from the server, so deserialization fails. Apparent options: add the jts implementation to the manifest of jbossall-client.jar; change the client classpath so it includes the jts impl jar in addition to jbossall-client.jar (not all users need the jts); change the classloader policy; change the tpc implementation. My vote is for changing the jbossall-client.jar. Any thoughts from the AS team? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200575#4200575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200575

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - jta/jts jar/config file change

by jhalliday

The jta and jts builds of the transaction service have historically existed separately. Each has its own .jar files (jbossjta[-*].jar and jbossjts[-*].jar) and config file (jbossjta-properties.xml and jbossjts-properties.xml) respectively. Internal metadata in the jar references the config file name, so the jts jar is not actually a superset of the jta one, although the .class files it contains are. This is all well and good for the standalone customers, who tend to download only one or the other distribution. With the introduction of the jts to AS 5.x it has become apparent that the situation is less than ideal, particularly now that the AS layout has a shared lib directory for all servers. Upgrading some servers to jts whist keeping the others running jta (not all of them have the orb needed for jts) is unduly complex. Very weird things can happen when the jts and jta jar files are both present on the classpath. I'd like to (hopefully) simplify matters by changing both versions to use jbossts-properties.xml as the config file. Of course the actual contents of the file will still differ according to the version you want to run, but at least the jts jar files will become a strict superset of the jta ones. That means we can put the jts jar files in the AS' shared lib directory and individual server configurations can select between the jts and jta just by editing the jbossts-properties.xml and transaction-jboss-beans.xml. This increases the footprint of the AS lib directory fractionally (jts is larger than jta), but decreases the overall app server bundle size as the jta jar files are no longer needed. More importantly, it reduces the number of ways users can potentially screw things up. It's slightly unintuitive that even those users wanting only the jta will need a jts jar file in the path, but I don't think its worth renaming the jar files or splitting the jts into a jta+jts pair rather than a single jar -the potential space saving is only around 300k. Unless I hear any objections I'll make this config change for JBossTS 4.6 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200574#4200574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200574

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Using ClassInfo in JBoss AOP

by kabir.khan＠jboss.com

Fixed mistake in my previous post View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200544#4200544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200544

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - jbpm4 task management component

by thomas.diesler＠jboss.com

I'd like to have a look at the jBPM4 Task Management component. Do you perhaps have links to design docs, blog entries, wiki pages, etc I'm looking for stuff similar to the Drools, WS-HumanTask posts http://blog.athico.com/2008/09/drools-and-ws-humantask.html http://www.jboss.org/feeds/post/creating_a_dsl_for_ws_humantask_and_when_... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200500#4200500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200500

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover & Paiging...

by clebert.suconic＠jboss.com

It was just faster to act and implement something now while everybody in Europe was sleeping and talk about other options later, so we could move forward now. It was actually relatively simple to force depage when the reference is not found, what fixed the problems I raised on my previous posts. All of this is being controlled at ServerConsuemerImpl::deliverReplicated. Now I'm also sending the address used on delivery. If the reference is not found I will force a depage. I don't think we would actually have an issue with OMEs or anything. Even if there are order differences between the two nodes, I don't think both page systems would be too different. We will talk about it when I wake up. All of this is on the branch I created: https://svn.jboss.org/repos/messaging/branches/Branch_Failover_Page View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200495#4200495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200495

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover & Paiging...

by clebert.suconic＠jboss.com

There is an issue with DuplicateIDCache and rollback also. Case the user decide for a rollback after the failOver, we need to make sure the data will come back to the Queue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200479#4200479 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200479

17 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Splitting subprojects

by ron.sigal＠jboss.com

Don't mind either. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200478#4200478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200478

17 years, 2 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 January 2009