October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Problem with multiples wars

by eroscc

Hello I have a problem with multiples wars. My JboosPortal version is: 2.2.1RC3 My classes are shared, but my jboss-web.xml is: | <class-loading java2ClassLoadingCompliance="false"> | <loader-repository> | com.sumersoft:loader=demo | <loader-repository-config> | java2ParentDelegation=false | </loader- repository-config> | </loader-repository> | </class-loading> | I see the problem when I try load one .properties that it is inside of war. Each war it has a different file .properties, with equals name but with different content. In my class that load .properties this code is used: | public class CommonInformationPortal implements ServletContextListener { | | private static Properties properties = null; | | public static void load() | { | try{ | if(properties == null) | { | properties = new Properties(); | properties.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("CommonInformation.properties")); | } | } | catch(Exception e) | { | return; | } | } | | | public static String getProperty(String property) { | try{ | return properties.getProperty(property); | } | catch(Exception e) | { | return null; | } | } | } | But always return the ClassLoader of last deployed war. So the file .properties read is always the file of last deployed war. I try use ServletContextListener the load of file .properties is ok, but when I get any propertie of this file is returned propertie of last deployed war. How i can resolve this problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980790#3980790 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980790

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by ovidiu.feodorov＠jboss.com

Tim wrote : By avoiding blocking on reads or writes it enables a small number of threads to handle a large amound of "connections". If reads or writes were blocking that wouldn't be possible. That's the crux of the matter. Well, read again my previous post. I am quoting it here for completness: "First there is the fact that a non-blocking IO implementation, complete with readiness selection, allows a single thread (or a precisely limited number of threads) to efficiently do what in a thread-per-connection model would take a number of threads equal with the number of connections. This approach a) avoids thread context switching that becomes toxic after the number of threads in use reaches a certain threshold and b) prevents using the thread scheduler as a substitute for a readiness selection mechanism (threads that suddenly get something to read, or write, are un-blocked by the scheduler, which acts as a "de facto" readiness detector)." So I really don't see what we're arguing about. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980789#3980789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980789

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by ovidiu.feodorov＠jboss.com

Tim wrote : | I think we have now (at least tacitly) agreed that byte buffers should be exposed, not byte[] so this is rather moot. | Let's make this explicit. Yes, ByteBuffer should be exposed. I said this may days and many posts ago. The problem in contention is where should they be exposed? At the top level or by one of the "layers". This is what we're trying to decide during the meeting today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980788#3980788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980788

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Design of a Content Based Routing Service

by ddunkin

"mark.little(a)jboss.com" wrote : "ddunkin" wrote : I have a ProcessPurchaseOrder document that comes into the system. That document is routed to the order management system for the supplier identified in the document. Now what I want to do is send a copy of all ProcessPurchaseOrder documents to a component that will extract certain information and store it for statistical analysis. It's a separation of concerns. The listener doesn't need to know anything about the statistical analysis. Neither does the order management system. | | | | So this is routing sequentially though? I had assumed you were maybe talking about routing the message concurrently, e.g., like a broadcast of the message to multiple destinations. | No, it would be concurrent. The order management system shouldn't have to wait for the statisticl analysis system. "mark.little(a)jboss.com" wrote : | anonymous wrote : | | Another example is a document that contains hours worked on a case where the employee working the case is paid billable time. That document should go to both receivables, so that the client can be billed, and to payroll, so the employee can be paid. | | Is this done sequentially or concurrently? Do you wait for the receivables to ack before sending to the payroll? If the answer is yes, then there's not really a problem AFAICT. If the answer is no, then we're talking about "asynchronous" interactions and, assuming the sender wants some kind of ack from each, the underlying infrastructure will need to be able to tally responses with "rendezvous" requests from the client, in just the same way it would for any "asynchronous" interaction. It would be concurrent. I think the assumption that the sender needs an ack from each receiver is not necessarily true. In fact, the sender doesn't even need to know where the message is going, just that the message was received by the ESB. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980787#3980787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980787

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: JBoss5 integration

by scott.stark＠jboss.org

The vfs changes should be complete as the stuff Bill is working on should not change the spi. I'm testing the deployer changes currently against trunk and hope to have that done today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980784#3980784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980784

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: status of merge, non persisted script on fork, and n-out

by kukeltje

Great Tom, this works perfectly. Sounds stupid but this 'small' enhancement and the little time it took helped me convince one of my colleagues to start investigating jBPM for a serious project. Probably the same is needed for making the join configurable as well... correct? With a little beanshell an n-out-of-m join can be created in jdpl for the moment (until it becomes an attribute...., same is true for the 'descriminator') Next step would be to be able to use drools for this also, at least on the fork..... I'm looking into this now I understand more of the internals of jBPM. btw, I already expected the fork.hbm.xml should be changed this way, just didn't try since I did not expect it to be this simple. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980775#3980775 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980775

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Design of a Content Based Routing Service

by daniel.brum＠jboss.com

anonymous wrote : Is this done sequentially or concurrently? Do you wait for the receivables to ack before sending to the payroll? If the answer is yes, then there's not really a problem AFAICT. If the answer is no, then we're talking about "asynchronous" interactions and, assuming the sender wants some kind of ack from each, the underlying infrastructure will need to be able to tally responses with "rendezvous" requests from the client, in just the same way it would for any "asynchronous" interaction. I would say that this is actually not a part of routing, but in fact a BPM process that keeps track of all the routings required for a particular message that comes in. The routing should be fire and forget, and it should be the job of an encompassing business process definition that knows if all parties required have been notified or not. If not, maybe it takes an action to have the message routed again, or if it's an optional recipient (say a statistical analysis system) that can live without the data being there for a real-time process, then it let's the logic continue, etc. I don't think we should be coupling the routing system to the systems receiving those routed data sets. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980774#3980774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980774

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Re: Failed to create new jboss debug configuration in Eclips

by rob.stryker＠jboss.com

JBoss 4.x should not be appearing there. See new demos: http://docs.jboss.org/jbosside/jboss-as/NewAndNoteworthy/jbosside2.0.0.be... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980773#3980773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980773

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Design of a Content Based Routing Service

by mark.little＠jboss.com

"ddunkin" wrote : anonymous wrote : I think the first question to ask is: why multiple destinations? The answer to that will impact the rest. | | I have a ProcessPurchaseOrder document that comes into the system. That document is routed to the order management system for the supplier identified in the document. Now what I want to do is send a copy of all ProcessPurchaseOrder documents to a component that will extract certain information and store it for statistical analysis. It's a separation of concerns. The listener doesn't need to know anything about the statistical analysis. Neither does the order management system. | So this is routing sequentially though? I had assumed you were maybe talking about routing the message concurrently, e.g., like a broadcast of the message to multiple destinations. anonymous wrote : | Another example is a document that contains hours worked on a case where the employee working the case is paid billable time. That document should go to both receivables, so that the client can be billed, and to payroll, so the employee can be paid. Is this done sequentially or concurrently? Do you wait for the receivables to ack before sending to the payroll? If the answer is yes, then there's not really a problem AFAICT. If the answer is no, then we're talking about "asynchronous" interactions and, assuming the sender wants some kind of ack from each, the underlying infrastructure will need to be able to tally responses with "rendezvous" requests from the client, in just the same way it would for any "asynchronous" interaction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980771#3980771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980771

19 years, 5 months

1
0
0 / 0

[Design of JBoss Eclipse IDE (dev)] - Failed to create new jboss debug configuration in Eclipse

by ah6511

Hi, I have latest Eclipse (3.2.1) and installed jboss eclipse IDE 2.0 Beta 2. Now I tried to createa new jboss debug configuration in Eclipse by going to "debug...", selecting "jboss 4.x" and clicking "new", nothing happened. I also tried jboss eclipse IDE 1.6, same thing. Any help will be greatly appreciated. -Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980770#3980770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980770

19 years, 5 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 October 2006