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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by clebert.suconic＠jboss.com

Is there a problem on the guess be the random server? That would diminish the probability of a hopping to happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002961#4002961 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002961

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by timfox

No need to guess, just choose a random server and hopping will take care of the rest. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002960#4002960 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002960

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by clebert.suconic＠jboss.com

anonymous wrote : Then you can prevent this "race condition" from happening in the first place? The server side doesn't know about failed Connections... it will send the callback as soon as the view was changed. To replicate this race condition I had to disable Lease on the client side. And have connections opened on different servers. Maybe it wouldn't occur in regular circunstances, but I wanted to prevent such behavior. The guess routine could find the right failoverServer fixing the race condition. Holding the update somewhere waiting failover to perform on all connections would require a lot of coding... while the simple guess routine could fix the problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002952#4002952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002952

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: SerializableDeploymentRepository notions

by scott.stark＠jboss.org

"bill.burke(a)jboss.com" wrote : I'm thinking of: | | | | DeploymentContext.getAttachments().addAttachment(key, value, List<VirtualFile> metaSources); | | | | Then, when getAttachment() is called, DC scans and checks to see if that attachment should be killed. | It should be the repository that scans the deployment and throws aways preprocessed content, not the DC. The repository could already have an index of metadata files, etc. I would rather have the api just provide the DC relative metadata file path than the full VirtualFile. "bill.burke(a)jboss.com" wrote : | Also, there should be additional methods on DeploymentContext: | | | | getAttachments(); | | getManagedObjects(); | | | | These attachments would actually be serialized with the profile while getTransientAttachments() would not. | | If i'm being too obvious, then apologies. | There is no difference between getAttachments() and getManagedObjects(). Both are attachments, or are you saying you want to express a DC ManagedObject at that level rather than use the ManagedObjectBuilder: | public interface ManagedObjectBuilder | { | /** | * Build managed objects for this deployment context | * | * @param unit the deployment unit | * @param managedObjects the managed objects | * @throws DeploymentException | */ | void build(DeploymentUnit unit, Map<String, ManagedObject> managedObjects) throws DeploymentException; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002948#4002948 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002948

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Running with the full featured profile service

by scott.stark＠jboss.org

No as svn was down past 2am. It won't be until latter today now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002942#4002942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002942

19 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Update to maven pom.xml

by kabir.khan＠jboss.com

Thank you. I've been burying my head in the sand and still know nothing about maven. Do you have commit access, or is there something I need to do? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002941#4002941 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002941

19 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Update to maven pom.xml

by pgier

I updated the maven build script (pom.xml) because I noticed a couple things weren't working (missing dependencies, some files not compiling). A couple things to note: the JRockit source files are skipped because they are dependent on a file not in the maven repo. And the JUnit tests are skipped for now. But the project builds ok, and I put a snapshot version in the maven repository. | <project xmlns="http://maven.apache.org/POM/4.0.0" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> | <modelVersion>4.0.0</modelVersion> | <groupId>jboss</groupId> | <artifactId>jboss-aop</artifactId> | <packaging>jar</packaging> | <version>snapshot</version> | <name>Maven Quick Start Archetype</name> | <url>http://maven.apache.org</url> | | <repositories> | <repository> | <id>jboss</id> | <name>JBoss Inc. Repository</name> | <layout>default</layout> | <url>http://repository.jboss.com/maven2/</url> | <snapshots> | <enabled>true</enabled> | </snapshots> | </repository> | </repositories> | | <build> | <sourceDirectory>src/main/</sourceDirectory> | <testSourceDirectory>src/test/</testSourceDirectory> | <plugins> | <plugin> | <groupId>org.apache.maven.plugins</groupId> | <artifactId>maven-compiler-plugin</artifactId> | <configuration> | <source>1.5</source> | <target>1.5</target> | <excludes> | <exclude>org/jboss/aop/hook/JRockit*</exclude> | </excludes> | </configuration> | </plugin> | <plugin> | <groupId>org.apache.maven.plugins</groupId> | <artifactId>maven-surefire-plugin</artifactId> | <configuration> | <skip>true</skip> | </configuration> | </plugin> | </plugins> | </build> | | <dependencies> | <dependency> | <groupId>ant</groupId> | <artifactId>ant</artifactId> | <version>1.6.5</version> | </dependency> | <dependency> | <groupId>javassist</groupId> | <artifactId>javassist</artifactId> | <version>3.4.GA</version> | </dependency> | <dependency> | <groupId>jboss</groupId> | <artifactId>jboss-dependency</artifactId> | <version>2.0.0.Beta</version> | </dependency> | <dependency> | <groupId>jboss</groupId> | <artifactId>jboss-container</artifactId> | <version>2.0.0.Beta</version> | </dependency> | <dependency> | <groupId>jboss</groupId> | <artifactId>jboss-test</artifactId> | <version>1.0.1.GA</version> | <scope>test</scope> | </dependency> | <dependency> | <groupId>jboss.profiler.jvmti</groupId> | <artifactId>jboss-profiler-jvmti</artifactId> | <version>1.0.0.CR5</version> | <scope>test</scope> | </dependency> | <dependency> | <groupId>junit</groupId> | <artifactId>junit</artifactId> | <version>3.8.1</version> | <scope>test</scope> | </dependency> | <dependency> | <groupId>oswego-concurrent</groupId> | <artifactId>concurrent</artifactId> | <version>1.3.4</version> | </dependency> | <dependency> | <groupId>qdox</groupId> | <artifactId>qdox</artifactId> | <version>1.6</version> | </dependency> | <dependency> | <groupId>trove</groupId> | <artifactId>trove</artifactId> | <version>2.1.1</version> | </dependency> | </dependencies> | | <distributionManagement> | <repository> | <id>cvs-file-repository</id> |  | <url>file://${maven.cvs.root}</url> | </repository> | </distributionManagement> | | </project> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002930#4002930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002930

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JMS Example in 3.2 Beta

by jeffdelong

I see another issue with using the CommandListenerInterface to start a process: the NewProcessInstanceCommand does not automatically signal the processInstance to advance the token. Thus, a second JMS message is required to signal the processInstance, but since the original message has no way to return a processInstanceId, there is no way to know which processInstance to signal. Also, the SignalCommand has a tokenId, but no processInstanceId (even if there were a way to return the processInstanceId). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002928#4002928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002928

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by alesj

I separated the DispatchContext into two interfaces = AttributeDispatchContext and InvokeDispatchContext: | public interface AttributeDispatchContext | { | /** | * Getter property / attribute | * | * @param name | * @return target's property / attribute instance | * @throws Throwable | */ | Object get(String name) throws Throwable; | | /** | * Setter property / attribute | * | * @param name | * @param value set target's property / attribute instance | * @throws Throwable | */ | void set(String name, Object value) throws Throwable; | } | | public interface InvokeDispatchContext extends AttributeDispatchContext | { | /** | * Invoke method / operation | * | * @param name | * @param parameters | * @param signature | * @return inovocation's return object | * @throws Throwable | */ | Object invoke(String name, Object parameters[], String[] signature) throws Throwable; | | /** | * Get any target | * | * @return the target | */ | Object getTarget(); | | /** | * Get context's classloader. | * Used when determining type info for parameter and | * getting the parameter actual value. | * | * @return context's classloader | * @throws Throwable | */ | ClassLoader getClassLoader() throws Throwable; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002917#4002917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002917

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - new build script updates committed

by tom.baeyens＠jboss.com

let me know if you have a problem with them View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002916#4002916 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002916

19 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 2007