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

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

by mculpepper＠jboss.com

Any details on when the restructure will be complete? I'm curious how a JBossIDE implementation will be able to install itself into a running JBossAS for deployment.. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980766#3980766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980766

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by mark.little＠jboss.com

"kurt.stam(a)jboss.com" wrote : There is no problem to register an EPR under multiple services, but when I register the EPR I need to know under what Service I'm going to register it. | | We can add the (logic) serviceName as a separate argument and assume that who ever does the registration knows to what Service (and category) this thing belongs. Does that work? | Actually that's precisely how I thought it would work. anonymous wrote : | Same holds for unregistring. And you'd only unregister the EPR listed under that category and service. +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980761#3980761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980761

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by kurt.stam＠jboss.com

There is no problem to register an EPR under multiple services, but when I register the EPR I need to know under what Service I'm going to register it. We can add the (logic) serviceName as a separate argument and assume that who ever does the registration knows to what Service (and category) this thing belongs. Does that work? Same holds for unregistring. And you'd only unregister the EPR listed under that category and service. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980757#3980757 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980757

19 years, 5 months

1
0
0 / 0

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

by ddunkin

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. 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980756#3980756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980756

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by mark.little＠jboss.com

Why do you want the serviceName from the EPR? Why do you want the service category in the EPR? An EPR is a physical endpoint address (c.f., a TCP/IP host/port pair, or a WWW URL). Given an EPR I cannot/should not be able to infer the type of service. The same endpoint, addressed through the same EPR, could be offering difference capabilities to different clients and hence appear as difference services. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980750#3980750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980750

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: How to store EPRs in the registry?

by kurt.stam＠jboss.com

I think it makes sense to categorize(classify) the services, so that one could look up all the 'transformation' services. Each service can have have multiple ServiceBindings. Each ServiceBinding relates to an EPR. Questions: 1. from where in the EPR can I get the serviceName (it looks like PortReference has this, should I use this?) 2. can we add the service category to the EPR somewhere (or should we add it in the serviceName by convention?) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980749#3980749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980749

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction thread behaviour

by bstansberry＠jboss.com

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

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

will be part of 3.2 but isn't yet... correct? I do not intend to fix this for 3.1 or so. I'll give it a try. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980736#3980736 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980736

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction thread behaviour

by manik.surtani＠jboss.com

| | Writing the above sparked a tangential thought; may be terrible, haven't thought about implications, etc. When an interceptor finds a node, why not throw it in the InvocationContext or something similar and pass it through the stack that way? Subsequently calls to find the node can check the context first before walking the cache tree. Saves redundant walking of the tree. | | Hmm, I like. Want to throw this into a JIRA task and I'll play around with it when I get a moment ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980732#3980732 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980732

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction thread behaviour

by bstansberry＠jboss.com

"ben.wang(a)jboss.com" wrote : | I don't think it is necessarily true that if a node has a read/write lock, it should not be evicted. Take for example the eivction policy of FIFO or policy with a node max age. Both will evict the corresponding node even when it just has been accessed. | I understand what you mean about FIFO or max age, but if eviction doesn't respect locks that can lead to serious problems; i.e. user thread doing a get acquires a lock in PessimisticLockInterceptor, then eviction thread evicts node, then user thread reaches TreeCache._get, which does a findNode, gets nothing and returns null. No chance to reload from the cache loader as the user thread is already past the interceptor. Writing the above sparked a tangential thought; may be terrible, haven't thought about implications, etc. When an interceptor finds a node, why not throw it in the InvocationContext or something similar and pass it through the stack that way? Subsequently calls to find the node can check the context first before walking the cache tree. Saves redundant walking of the tree. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980728#3980728 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980728

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