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

[Design of JBoss jBPM] - Re: current activity of execution

by camunda

Okay, I should RTFM ;-) But still, this doesn't lead to a problem with the getActivityName, or? If I am in a composite, the root execution may be in the scope/composite state, and the child in the "real" state. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242786#4242786 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242786

16 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP tests still on Hudson

by jmesnil

I wanted to check first if the tests were still failing with the timer tasks properly canceled. The failures are still there, so I've committed a temporary exclusion the http tests. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242779#4242779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242779

16 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Netty HTTP tests still on Hudson

by timfox

Hudson still seems to be running the Netty HTTP tests - I thought these were going to be temporarily removed to see if it solves the problem? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242772#4242772 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242772

16 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Usage of Timers in JBM 2

by timfox

Timers should rarely if ever be used. Each Timer maintains its own thread so this doesn't scale. On the client side a scheduled executor pool is available to the session factory and this should be used for any scheduled tasks, e.g. for http transport. Take a look at the thread pooling chapter in the user manual. We have to be very careful where and how threads are created, always use the pools unless you have a *very* good reason not to (e.g. you need to set thread priority) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242770#4242770 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242770

16 years, 9 months

1
0
0 / 0

[Design of Embedded JBoss] - AS Branch_5_x now booting in Embedded

by ALRubinger

With a bunch of the requisite bootstrap refactoring done, I've moved into making an Embedded booter for AS. At the same time, I'm prototyping some APIs for virtual (declarative, VFS-backed) deployments much like Bill did in "DeploymentGroup" of the old Embedded. The issue of the day is: https://jira.jboss.org/jira/browse/EMB-32 So AS now is running in what I call "Mode 1", which is backed by a true filesystem installation. The API looks like: final JBossASEmbeddedServer server = new JBossASEmbeddedServerImpl(); | server.start(); There's also a single-arg constructor which will accept a JBOSS_HOME. In the no-arg form we look for environment variable "JBOSS_HOME" or system property "jboss.home". Then we can make a deployment: final String name = "testDeployment.jar"; | final VirtualVfsArchive deployment = new VirtualVfsArchiveImpl(name).addClasses(OutputBean.class, | OutputLocalBusiness.class); | log.info(deployment.toString(true)); The "toString(true)" is a verbose form which aids in debugging the virtual deployment, printing out something similar to: 23:35:47,852 INFO [ServerTestCase] MemoryContextHandler@324589909[path= context=vfsmemory://testDeployment.jar real=vfsmemory://testDeployment.jar] | - 0 bytes | org - 0 bytes | org/jboss - 0 bytes | org/jboss/embedded - 0 bytes | org/jboss/embedded/testsuite - 0 bytes | org/jboss/embedded/testsuite/fulldep - 0 bytes | org/jboss/embedded/testsuite/fulldep/ejb3 - 0 bytes | org/jboss/embedded/testsuite/fulldep/ejb3/slsb - 0 bytes | org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputBean.class - 844 bytes | org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputLocalBusiness.class - 312 bytes Then we deploy and test: server.deploy(deployment); | final OutputLocalBusiness bean = (OutputLocalBusiness) new InitialContext().lookup(OutputBean.class | .getSimpleName() | + "/local");; | final String output = bean.getOutput(); | log.info("Got output: " + output); | Assert.assertEquals(OutputLocalBusiness.OUTPUT, output); This test is now turning green. So we can say that Embedded is showing some signs of life, and the bootstrap refactoring is starting to pay off. The phase of development I'm in now is building out the virtual archive APIs. I want tests that show Servlets, JMS, SLSB, SFSB, JCA, etc all working in this mode. And even further we need finer-grained unit tests which are currently absent in the Embedded source tree (it's all integration thus far). Wiki documentation to be forthcoming, but in the interim anyone who wants to be involved should ping me directly. http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/testsuite-... S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242750#4242750 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242750

16 years, 9 months

1
0
0 / 0

[Design of JBossXB] - Re: Referencing the bean-deployer namespace from a custom me

by david.lloyd＠jboss.com

"alex.loubyansky(a)jboss.com" wrote : anonymous wrote : So maybe it's treating the outer choice as maxOccurs=1 or something? | | Yes, of course. And IMO that's how it should be. Otherwise, the structures of the bound components/types in Java and XSD are inconsistent. Why don't you use a sequence? What problem does it cause in this case? The problem is that it prevents the user from putting the element in any order. In the schema, all the elements listed in this class are in one "choice"; the only reason they're grouped as they are here is because that's how they're mapped in terms of Java types. So the effect I'm really going for is to have XB take all the XmlElement instances in the class and make one big "choice" out of it with maxOccurs=unbounded. anonymous wrote : I have my root element set up to be propOrder={} and modelgroup=CHOICE. If you bind to a choice then propOrder should be removed. propOrder={} is supposed to bind to all. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242733#4242733 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242733

16 years, 9 months

1
0
0 / 0

[Design of JBossXB] - Re: Referencing the bean-deployer namespace from a custom me

by alex.loubyansky＠jboss.com

anonymous wrote : So maybe it's treating the outer choice as maxOccurs=1 or something? Yes, of course. And IMO that's how it should be. Otherwise, the structures of the bound components/types in Java and XSD are inconsistent. Why don't you use a sequence? What problem does it cause in this case? anonymous wrote : I have my root element set up to be propOrder={} and modelgroup=CHOICE. If you bind to a choice then propOrder should be removed. propOrder={} is supposed to bind to all. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242726#4242726 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242726

16 years, 9 months

1
0
0 / 0

[Design of Security on JBoss] - Re: JBAS-7049: AccessController permission check throwing NP

by anil.saldhana＠jboss.com

DML created a bug : http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=364 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242725#4242725 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242725

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM4 History/Log implementation.

by kukeltje

You are welcome. I just hope someone can give me my total number of posts some day. Should be around 10.000 I think View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242721#4242721 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242721

16 years, 9 months

1
0
0 / 0

[Design of Security on JBoss] - Re: JBAS-7049: AccessController permission check throwing NP

by anil.saldhana＠jboss.com

Thanks to DML. Actually the openjdk7 code is: | for (int i=0; i< context.length; i++) { | if (context != null && !context.implies(perm)) { | if (dumpDebug) { | debug.println("access denied " + perm); | } | if (Debug.isOn("failure") && debug != null) { | // Want to make sure this is always displayed for failure, | // but do not want to display again if already displayed | // above. | if (!dumpDebug) { | debug.println("access denied " + perm); | } | Thread.currentThread().dumpStack(); | final ProtectionDomain pd = context; | final Debug db = debug; | AccessController.doPrivileged (new PrivilegedAction<Void>() { | public Void run() { | db.println("domain that failed "+pd); | return null; | } | }); | } | throw new AccessControlException("access denied "+perm, perm); | } | } Looks like the debug != null check has been added on the if condition in openjdk7. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242720#4242720 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242720

16 years, 9 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 July 2009