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

[Design of JBoss Web Services] - Re: JBossWS Test Approach

by richard.opalka＠jboss.com

I'd like to start discussion about above JIRA issue. I don't like our current testing approach because: it's error prone approach we don't test against AS distributions but against local maven repository it wastes our development time I'll explain each point in next posts. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215183#4215183 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215183

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - JBossWS Test Approach

by richard.opalka＠jboss.com

This thread is related to JBWS-2530. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215179#4215179 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215179

17 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Management of deployed bundles

by alesj

"thomas.diesler(a)jboss.com" wrote : | Where could I read up on the PS or find related documentation and examples | that could help me to potentially migrate the above to the PS? Your best bet would be the Managed test cases and ProfileService tests in JBossAS testsuite. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215151#4215151 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215151

17 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: JBOSGI-38 and bundle deployment order

by alesj

I still don't see what this has got to do with RBDI? I wouldn't worry about such cases: * deploy A which depends on X * wait 30min * deploy X Since this is not realistic. And even then, I don't see a problem, as the only thing we'll get is a exception meant to be a warning. You either deploy the missing pieces or you remove the initial deployment. As discussed, mostly it's this behavior that we see/use: * MD::addDeployment A * MD::addDeployment X * MD::process * MD::checkComplate And even with this and current HD scanner we might not get all dependent deployments in one group/snapshot, e.g. X is just being droped, while we did a scan, but that wouldn't be a problem apart from IDE, which can easily be dealt with - ignored or handled properly. If we're gonna use MC's VDF to handle our OSGi Runtime deployments, we should do it as we're already doing them - with proper dependencies tied into deployment's lifecycle. And that's exactly what RBDI and a proper deployer's split does. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215149#4215149 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215149

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by timfox

Guys- please do not use pastebin links (internal or external) in forum threads. Pastebins are a temporary resource, so if anyone comes back in days/weeks/months for now they won't be able to access the info. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215147#4215147 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215147

17 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Management of deployed bundles

by thomas.diesler＠jboss.com

Folks, currently there is a management view on the deployed OSGi Framework | public interface ManagedFrameworkMBean | { | /** The default object name: jboss.osgi:service=ManagedFramework */ | static final ObjectName OBJECT_NAME = ObjectNameFactory.create("jboss.osgi:service=ManagedFramework"); | | /** | * Get the list of all installed bundles | */ | Set<ObjectName> getBundles(); | | /** | * Get the installed bundle | */ | ObjectName getBundle(String symbolicName); | } | Every deployed bundle is also registered as an MBean | public interface ManagedBundleMBean | { | /** | * Returns this bundle's current state. | * A bundle can be in only one state at any time. | * | * @return An element of UNINSTALLED,INSTALLED, RESOLVED,STARTING, STOPPING,ACTIVE. | */ | int getState(); | | /** | * Returns the symbolic name of this bundle as specified by its Bundle-SymbolicName manifest header | */ | String getSymbolicName(); | | /** | * Starts this bundle with no options | */ | void start() throws BundleException; | | /** | * Stops this bundle with no options. | */ | void stop() throws BundleException; | } | As I understand it the ProfileService (PS) is meant to provide a general management view on installed components, which is not limited to JMX. Where could I read up on the PS or find related documentation and examples that could help me to potentially migrate the above to the PS? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215134#4215134 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215134

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by alesj

Why does it have to be on a MutableX in the first place? I guess having a custom interface is OK, but then you need to separate your AOP code as well, to have this part in configurable (depending on the actuall Reflect impl) class. e.g. org.jboss.aop.bodyt.BodyTranslator org.jboss.aop.bodyt.javassist.JavassistBodyTranslator org.jboss.aop.bodyt.cglib.CGLibBodyTranslator View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215128#4215128 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215128

17 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Runtime and bundle lifecycle/dependency resolution

by thomas.diesler＠jboss.com

Please see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151463 on why the DependencyItem approach cannot not (yet) work View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215108#4215108 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215108

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM

by clebert.suconic＠jboss.com

I was thinking now... I guess the JORAM hang may be indirectly related to this: My guess is, a missing ping happened after the server was stopped, while close was called at the same time. (What the test is about). Maybe there is a way to avoid the close and missing ping at the same time. (Maybe making sure the Server is only stopped after the sessions are closed). But this hang (replicated on PingStressTest) is probably the root cause. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215087#4215087 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215087

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another DeadLock, something around InVM (Repost)

by clebert.suconic＠jboss.com

Just had another look at the original thread dump (first one reported on this thread, that I got on hudson-build 3761): I can also see the waiting to shutdown the executor there: | [junit] "main" prio=1 tid=0x08deb950 nid=0x76c8 waiting on condition [0xffc33000..0xffc33d58] | [junit] at sun.misc.Unsafe.park(Native Method) | [junit] at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146) | [junit] at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1879) | [junit] at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1028) | [junit] at org.jboss.messaging.integration.transports.netty.NettyAcceptor.stop(NettyAcceptor.java:354) | [junit] - locked <0xb2718638> (a org.jboss.messaging.integration.transports.netty.NettyAcceptor) | [junit] at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:213) | [junit] - locked <0xb2714c30> (a org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl) | [junit] at org.jboss.messaging.core.server.impl.MessagingServiceImpl.stop(MessagingServiceImpl.java:67) | [junit] at org.jboss.messaging.tests.integration.remoting.PingTest.tearDown(PingTest.java:102) | [junit] at junit.framework.TestCase.runBare(TestCase.java:136) | [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) | [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) | [junit] at junit.framework.TestResult.run(TestResult.java:109) | [junit] at junit.framework.TestCase.run(TestCase.java:120) | [junit] at junit.framework.TestSuite.runTest(TestSuite.java:230) | [junit] at junit.framework.TestSuite.run(TestSuite.java:225) | [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421) | [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912) | [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) | (Dump extracted from run 3761 at http://hudson.qa.jboss.com/hudson/view/JBM%202/job/JBM2-tests/3761/console) (Sorry non RedHatters for using an internal link.. but the relevant information is pasted here) So, this is the same condition replicated by PingStressTest. And I also confirmed the test passed without the changes from r5990. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215069#4215069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215069

17 years, 1 month

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 March 2009