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

[Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience

by mark.little＠jboss.com

"kurt.stam(a)jboss.com" wrote : (i) This can be best accomplished by introducing a 'deployTrailblazer' task. :) | Sounds just about perfect. Let me guess, something like | <target name="deployTrailblazer" | depends="configure, deploy"/> | ;-) anonymous wrote : | (ii) We should get rid of the ant wizzard all together and just have one loanbroker.properties file (we check in an -example) just like we do for the esb itself. | That sounds good too. We already tell people they have to edit the loanbroker.properties-template file anyway. anonymous wrote : | There is nothing better then simplicity. We could annotate this file with info on where this parameter is going to be used. Just so that it becomes easier to check up on yourself. (Currently the ant wizzard still has problems with slashes, spaces and it doesn't keep track of your previously given answers) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976563#3976563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976563

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience

by kurt.stam＠jboss.com

(i) This can be best accomplished by introducing a 'deployTrailblazer' task. :) (ii) We should get rid of the ant wizzard all together and just have one loanbroker.properties file (we check in an -example) just like we do for the esb itself. There is nothing better then simplicity. We could annotate this file with info on where this parameter is going to be used. Just so that it becomes easier to check up on yourself. (Currently the ant wizzard still has problems with slashes, spaces and it doesn't keep track of your previously given answers) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976560#3976560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976560

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Trailblazer out-of-the-box experience

by mark.little＠jboss.com

The machine I was building the TB on had a disk failure last night, so I've been trying to set this up from scratch on Mac OS X. Not something I've had to do in a while. I'd forgotten how many steps you have to go through. Some observations: (i) we should have a single rule for configuring and running the demo. Multiple rules are fine for the user who wants to go through each step at a time, but I think the 80/20 rule needs to apply here. (ii) the configuration step should cache the answers from each run and echo them back if you want to re-run. That way you don't have to answer all of the same set of questions again if only one thing needs changing. Where I've used this approach before you see the default answer in [], so for example: [input] Enter the path to the root of your local JBoss Application Server Installation (required for access to JBoss libraries): would be [input] Enter the path to the root of your local JBoss Application Server Installation (required for access to JBoss libraries): [/usr/local/jboss-4.0.4] and [input] Enter the host address of the JBoss Application Server on which your deployed JBoss ESB is running (for "localhost" simply press return): would be [input] Enter the host address of the JBoss Application Server on which your deployed JBoss ESB is running: [25] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976549#3976549 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976549

19 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - SLBs cyclic dependencies

by yandosh

I would like to ask a question about cyclic dependencies between EJB. I have 3 stateless EJBs: A depends on B, B depends on C, C depends on A. EJBs refuse to deploy due to MBeans waiting for other MBeans error. My question is: Is there really any kind of limitation of cyclic dependencies between stateless session beans? If there is why and is there any "workaround" to make the EJBs deploy? Thanks in advance. Frantisek Jandos View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976546#3976546 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976546

19 years, 6 months

1
0
0 / 0

[Other JBoss Development Design] - Re: run.sh to launch JBoss in background

by dimitris＠jboss.org

I don't think this is the right way to solve this. It would be better to avoid the passing of variables back and forth and the background functionality in run.sh script and control it solely from the init.d script or whatever. Then change run.sh to a) remember the PID of the java process b) install a trap that will simply forward the signal you are interested to the child java process See http://learnlinux.tsf.org.za/courses/build/shell-scripting/ch12s03.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976536#3976536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976536

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()

by scott.stark＠jboss.org

Ok, I see. Yes, the JarEntryHandler.getChildren is inconsistent with the testcase usage. There is no proper notion of a directory in a jar in terms of java.util.jar.* providing a parent/child api, so the entries either the entries associated with a jar directory that share the same prefix will need to be added, or we will have to implement a special List that lazily traverses the jar entries and only returns those that have the directory entry prefix. The latter is probably the easiest way to do this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976485#3976485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976485

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: PojoCache physical POJO field mapping and region

by ben.wang＠jboss.com

"genman" wrote : | Why couldn't you create a node wrapper and hang your meta data from it? | | | | class DelegatingNode implements Node { | | Node delegate; | | ... | | } | | | | class PojoNode extends DelegatingNode { | | Object secretData; | | } | | | | Or... | | There's a couple of internal cache fields, such as TreeCache.UNINITALIZED, etc. Rather than be strings, perhaps they could be typed using an interface and hidden from the user. | | Maybe create a partitioning map wrapper that delegates to the ConcurrentHashMap or whatever, and has "secret" storage for internal data. | This is certainly interesting to hide the internal fields from the users. But this will involve the underlying Cache design change either with a new API. Or if we access it directly, how do we go through the cache interceptor chain? I have created a Jira to diiscuss it: http://jira.jboss.com/jira/browse/JBCACHE-797 Thanks, -Ben View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976476#3976476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976476

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: PojoCache physical POJO field mapping and region

by ben.wang＠jboss.com

"bstansberry(a)jboss.com" wrote : It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose. I know you have told me before but what exactly is the usage for getChildrenNames() again? I mean can PojoCache provide that kind of functionality such that you don't need to use the underlying cache API? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976474#3976474 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976474

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests

by rachmatowicz＠jboss.com

I hope to present a detailed picture of my understanding of what you want tomorrow (Friday) which we can use to move forward. One question though: from what I have read, the microcontainer (MC) has limitations, in particular that remote communication is not supported at present. I assume this means that, say, in a test case based on MicrocontainerTestCase, that the JMS provider, deployed destinations, and test case itself all have to reside in the same VM. (Please correct me if i'm mistaken). So running test cases using the MC, despite this limitation, makes sense when we are outside the AS, as there is no alternative. However, what if JMX (which supports remote communication) is available?. You mentioned in an earlier posting that tests should be written against the MC. Does this mean that you want to run these generic JMS tests against the MC, even when the AS is available? That is, in the AS test suite, to run all JMS tests (whether against the JBossMQ provider or Messaging preovider) by deploying these providers to the MC and not JMX? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976447#3976447 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976447

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()

by kabir.khan＠jboss.com

I've added some tests to FileVFSUnitTestCase: -testGetMetaDataUnpackedJar() -testGetMetaDataPackedJar() These use the same code to access the children as where it ends up in AbstractDeploymentContext.getMetaDataFiles(). The unpacked one works, the packed one fails, i.e. returns an empty list View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976446#3976446 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976446

19 years, 6 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