[EJB 3.0 Development] - EJB metadata and the jndi policy decorators
by jaikiran
While integrating no-interface metadata support in AS i see that there's one more stumbling block - the jndi policy decorator(s). From what i see of those decorators, they are meant to provide (decorated) jndi names on the metadata:
| * Decorate a JBossSessionBeanMetaData with the ability to resolve JNDI Names
| * based on a specified JNDI Binding Policy, so any getter of a JNDI
| * name will never return null.
|
The JBossSessionPolicyDecorator looks like this:
| public class JBossSessionPolicyDecorator<T extends JBossSessionBeanMetaData> extends JBossServiceBeanMetaData implements ResolveableJndiNameJbossSessionBeanMetadata
| {
| ...
| private T delegate;
|
| private DefaultJndiBindingPolicy jndiPolicy;
|
| @SuppressWarnings("unchecked")
| public JBossSessionPolicyDecorator(T delegate, DefaultJndiBindingPolicy jndiPolicy)
| {
| assert delegate != null : "delegate is null";
| assert jndiPolicy != null : this.getClass().getSimpleName() + " requires a specified "
| + DefaultJndiBindingPolicy.class.getSimpleName();
|
| // Disallow double-wrapping
| if(delegate instanceof JBossSessionPolicyDecorator)
| {
| JBossSessionPolicyDecorator<T> d =(JBossSessionPolicyDecorator<T>)delegate;
| delegate = d.getDelegate();
| }
|
| this.delegate = delegate;
| this.jndiPolicy = jndiPolicy;
| }
| ...
| // overrides everything from the JBossSessionBeanMetaData to pass control to the delegate
| // just some example overriden methods
| @Override
| public BusinessLocalsMetaData getBusinessLocals()
| {
| return delegate.getBusinessLocals();
| }
|
| @Override
| public BusinessRemotesMetaData getBusinessRemotes()
| {
| return delegate.getBusinessRemotes();
| }
|
| @Override
| public CacheConfigMetaData getCacheConfig()
| {
| return delegate.getCacheConfig();
| }
|
|
And then when we want to decorate the merged metadata, we create a new instance of this decorator (notice that the decorator itself is a metadata instance):
| // Create a Session JNDI Policy Decorated Bean
| JBossSessionBeanMetaData decoratedBean = new JBossSessionPolicyDecorator<JBossSessionBeanMetaData>(sessionBean, policy);
| // then add as attachment to deployment unit
| du.addAttachment(...,decoratedBean);
|
|
The real problem here is that the decorator itself extends from the metadata (i.e. it's an metadata itself) and we instantiate this decorated metadata and pass it along. Most of the methods in this decorated metadata have been overriden to pass the control to the delegate metadata from which this is constructed. However, if any new methods gets added (like we just added for the EJB3.1 support), then unless someone goes and updates this class to override such methods, this decorated metadata is going to return incorrect information. For example (pseudo code):
| JBossSessionBean31MetaData original = new JBossSessionBean31MetaData();
| original.setNoInterfaceBean(true);
| assertTrue(original.isNoInterfaceBean()); // succeeds
| // now decorate (remember pseudo code, but you get the idea)
| JBossSessionBean31MetaData decorated = new JBossSessionPolicyDecorator(original,jndiPolicy);
| // now check whether the no-interface information was kept intact
| assertTrue(decorated.isNoInterfaceBean()); // FAILS
|
So unless i go and update the decorator to override this method, things are not going to work:
| public class JBossSession31PolicyDecorator<T extends JBossSession31BeanMetaData> extends JBossSessionPolicyDecorator
| {
|
| @Overriden
| public boolean isNoInterfaceBean()
| {
| delegate.isNoInterfaceBean;
| }
| ...
|
This is going to be an issue with the introduction of more and more 3.1 metadata support (for ex: async-methods).
So here's what i was thinking:
The decorator really just needs to update/decorate the metadata with appropriate JNDI names. It shouldn't really mess with anything else. So why not have something like:
| public interface EnterpriseBeanJNDINameDecorator<T extends JBossEnterpriseBeanMetaData>
| {
|
| /**
| * Updates the <code>metaData</code> with the ability to resolve JNDI names.
| * It's upto the implementations of this interface to either:
| * <ul>
| * <li>Create a new instance of metadata and add the ability to resolve JNDI names and return it
| * </li>
| * <li>Or update the passed <code>metaData</code> with the ability to resolve JNDI names
| * and return it back</li>
| * </ul>
| * @param metaData The metaData which will be decorated with JNDI names
| * @return Returns the updated metadata
| */
| T decorate(T metaData);
| }
|
Then an implementation of the decorator for the session beans would look like:
| /**
| * JBossSessionBeanMetaDataJNDINameDecorator
| *
| * Decorates a JBossSessionBeanMetaData with the ability to resolve JNDI Names
| * based on a specified JNDI Binding Policy.
| *
| * @author Jaikiran Pai
| * @version $Revision: $
| */
| public class JBossSessionBeanMetaDataJNDINameDecorator<T extends JBossSessionBeanMetaData>
| implements
| EnterpriseBeanJNDINameDecorator<T>
| {
|
| private DefaultJndiBindingPolicy jndiPolicy;
|
| public JBossSessionBeanMetaDataJNDINameDecorator(DefaultJndiBindingPolicy jndiPolicy)
| {
| this.jndiPolicy = jndiPolicy;
| }
|
| /**
| * @see org.jboss.metadata.ejb.jboss.jndipolicy.plugins.EnterpriseBeanJNDINameDecorator#decorate(org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData)
| */
| @Override
| public T decorate(T sessionBeanMetaData)
| {
| // create a resolveable metadata
| ResolveableJndiNameJbossSessionBeanMetadata resolveableJndiNameMetaData = new JNDIPolicyBasedResolveableJndiNameJBossSessionBeanMetaDataImpl<T>(
| sessionBeanMetaData, this.jndiPolicy);
|
| // Now decorate the metadata (i.e. Update all the relevant JNDI names in the metadata)
|
| // local jndi name
| String localJndiName = resolveableJndiNameMetaData.determineResolvedLocalBusinessDefaultJndiName();
| if (localJndiName != null)
| {
| sessionBeanMetaData.setLocalJndiName(localJndiName);
| }
| // remote jndi name
| String jndiName = resolveableJndiNameMetaData.determineResolvedRemoteBusinessDefaultJndiName();
| if (jndiName != null)
| {
| sessionBeanMetaData.setJndiName(jndiName);
| }
| // home jndi name
| String homeJndiName = resolveableJndiNameMetaData.determineResolvedRemoteHomeJndiName();
| if (homeJndiName != null)
| {
| sessionBeanMetaData.setHomeJndiName(homeJndiName);
| }
| // local home jndi name
| String localHomeJndiName = resolveableJndiNameMetaData.determineResolvedLocalHomeJndiName();
| if (localHomeJndiName != null)
| {
| sessionBeanMetaData.setLocalHomeJndiName(localHomeJndiName);
| }
| // mapped name
| String mappedName = this.getMappedName(sessionBeanMetaData, resolveableJndiNameMetaData);
| if (mappedName != null)
| {
| sessionBeanMetaData.setMappedName(mappedName);
| }
|
| // return the decorated metadata
| return sessionBeanMetaData;
| }
|
This decorator uses the jndipolicy and an implementation of ResolveableJndiNameJbossSessionBeanMetadata to decorate the bean with the JNDI names. The implementation of ResolveableJndiNameJbossSessionBeanMetadata looks like this (i just moved it out of the existing JBossSessionPolicyDecorator):
| public class JNDIPolicyBasedResolveableJndiNameJBossSessionBeanMetaDataImpl<T extends JBossSessionBeanMetaData>
| implements
| ResolveableJndiNameJbossSessionBeanMetadata
| {
|
| ...
| /**
| * Constructor
| *
| * @param bean The enterprise bean metadata whose jndi name has to be transiently resolvable
| * @param jndiPolicy The JNDI policy which will be used to resolve the jndi name(s) of the <code>bean</code>
| */
| public JNDIPolicyBasedResolveableJndiNameJBossSessionBeanMetaDataImpl(T bean, DefaultJndiBindingPolicy jndiPolicy)
| {
| this.sessionBean = bean;
| this.jndiPolicy = jndiPolicy;
| }
|
| // ... THIS implementation has just been moved out of the current JBossSessionPolicyDecorator, so
| // there's nothing new here. No point posting all the code in the forum, so just one method has been
| // posted as an example
| /**
| * Returns the resolved JNDI target to which the
| * default EJB3.x Local Business interfaces are to be bound
| *
| * @return
| */
| @Override
| public String determineResolvedLocalBusinessDefaultJndiName()
| {
| String s = this.sessionBean.getLocalJndiName();
| if (s != null && s.length() > 0)
| return s;
|
| return getJNDIPolicy().getJndiName(getEjbDeploymentSummary(), KnownInterfaces.LOCAL,
| KnownInterfaceType.BUSINESS_LOCAL);
| }
|
So now that we have a decorator (which is *not* an metadata in itself), we can use it to decorate the existing/original metadata as follows:
| JBossSessionBean31MetaData original = new JBossSessionBean31MetaData();
| original.setNoInterfaceBean(true);
| assertTrue(original.isNoInterfaceBean()); // succeeds
| // now decorate
| // 1. create a decorator
| EnterpriseBeanJNDINameDecorator<JBossSessionBean31MetaData> decorator = new JBossSessionBeanMetaDataJNDINameDecorator<JBossSessionBean31MetaData>(new BasicJndiBindingPolicy());
| // decorate with this decorator
| JBossSessionBean31MetaData decorated = decorator.decorate(original);
| // now check whether the no-interface information was kept intact
| assertTrue(decorated.isNoInterfaceBean()); // Now passes
|
Overall, the difference here is that we have now moved away from the decorator being a metadata in itself.
My local testcases (around no-interface) are now passing with these changes. There are some more things that i'll have to work on (for example: a decorator for service beans etc...), but before i do anything around this, i wanted to have other's opinion on this change. Any thoughts on how we should proceed? Does this look OK?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270186#4270186
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270186
15 years
[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool
by kabir.khan＠jboss.com
It runs fine for me now. Initially I thought there was a deadlock in org.jboss.test.classpool.jbosscl.test.CtClassCreationTestCase, but it completed after about 2 minutes.
The next few times I ran the tests, CtClassCreationTestCase only took 2 seconds. Here's a thread dump from the "long" run of CtClassCreationTestCase
| Running org.jboss.test.classpool.jbosscl.test.CtClassCreationTestCase
| ^\Full thread dump Java HotSpot(TM) Client VM (1.5.0_19-137 mixed mode, sharing):
|
| "Thread-7" prio=5 tid=0x012272f0 nid=0x213e200 runnable [0xb1115000..0xb1115d90]
| at java.io.FileInputStream.readBytes(Native Method)
| at java.io.FileInputStream.read(FileInputStream.java:194)
| at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
| at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
| at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
| - locked <0x0e4243f8> (a java.io.InputStreamReader)
| at java.io.InputStreamReader.read(InputStreamReader.java:167)
| at java.io.BufferedReader.fill(BufferedReader.java:136)
| at java.io.BufferedReader.readLine(BufferedReader.java:299)
| - locked <0x0e4243f8> (a java.io.InputStreamReader)
| at java.io.BufferedReader.readLine(BufferedReader.java:362)
| at org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:140)
|
| "Thread-6" prio=5 tid=0x012265c0 nid=0x2070000 runnable [0xb1094000..0xb1094d90]
| at java.io.FileInputStream.readBytes(Native Method)
| at java.io.FileInputStream.read(FileInputStream.java:194)
| at java.io.BufferedInputStream.read1(BufferedInputStream.java:254)
| at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
| - locked <0x0e423228> (a java.io.BufferedInputStream)
| at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
| at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
| at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
| - locked <0x0e420918> (a java.io.InputStreamReader)
| at java.io.InputStreamReader.read(InputStreamReader.java:167)
| at java.io.BufferedReader.fill(BufferedReader.java:136)
| at java.io.BufferedReader.readLine(BufferedReader.java:299)
| - locked <0x0e420918> (a java.io.InputStreamReader)
| at java.io.BufferedReader.readLine(BufferedReader.java:362)
| at org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:153)
|
| "process reaper" daemon prio=5 tid=0x01226440 nid=0x206f200 runnable [0xb0e0f000..0xb0e0fd90]
| at java.lang.UNIXProcess.waitForProcessExit(Native Method)
| at java.lang.UNIXProcess.access$700(UNIXProcess.java:17)
| at java.lang.UNIXProcess$2$1.run(UNIXProcess.java:83)
|
| "pool-1-thread-5" prio=5 tid=0x01008b90 nid=0x840800 in Object.wait() [0xb1013000..0xb1013d90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at java.lang.Object.wait(Object.java:474)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
| - locked <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
| at java.lang.Thread.run(Thread.java:613)
|
| "pool-1-thread-4" prio=5 tid=0x010088e0 nid=0x83fa00 in Object.wait() [0xb0f92000..0xb0f92d90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at java.lang.Object.wait(Object.java:474)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
| - locked <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
| at java.lang.Thread.run(Thread.java:613)
|
| "pool-1-thread-3" prio=5 tid=0x01008630 nid=0x83ec00 in Object.wait() [0xb0f11000..0xb0f11d90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at java.lang.Object.wait(Object.java:474)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
| - locked <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
| at java.lang.Thread.run(Thread.java:613)
|
| "pool-1-thread-2" prio=5 tid=0x01008380 nid=0x892600 in Object.wait() [0xb0e90000..0xb0e90d90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at java.lang.Object.wait(Object.java:474)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
| - locked <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
| at java.lang.Thread.run(Thread.java:613)
|
| "pool-1-thread-1" prio=5 tid=0x010081a0 nid=0x891800 in Object.wait() [0xb0d8e000..0xb0d8ed90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at java.lang.Object.wait(Object.java:474)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
| - locked <0x10a7d138> (a hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
| at hidden.edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
| at java.lang.Thread.run(Thread.java:613)
|
| "Low Memory Detector" daemon prio=5 tid=0x01207db0 nid=0x2022800 runnable [0x00000000..0x00000000]
|
| "CompilerThread0" daemon prio=9 tid=0x01207440 nid=0x2021a00 waiting on condition [0x00000000..0xb0c0b7d8]
|
| "Signal Dispatcher" daemon prio=9 tid=0x01206ff0 nid=0x2020c00 waiting on condition [0x00000000..0x00000000]
|
| "Finalizer" daemon prio=8 tid=0x01206850 nid=0x2014c00 in Object.wait() [0xb0a05000..0xb0a05d90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10975a48> (a java.lang.ref.ReferenceQueue$Lock)
| at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
| - locked <0x10975a48> (a java.lang.ref.ReferenceQueue$Lock)
| at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
| at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
|
| "Reference Handler" daemon prio=10 tid=0x01206490 nid=0x2013400 in Object.wait() [0xb0984000..0xb0984d90]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x10975ad0> (a java.lang.ref.Reference$Lock)
| at java.lang.Object.wait(Object.java:474)
| at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
| - locked <0x10975ad0> (a java.lang.ref.Reference$Lock)
|
| "main" prio=5 tid=0x010004c0 nid=0xb0801000 in Object.wait() [0xb07ff000..0xb0800158]
| at java.lang.Object.wait(Native Method)
| - waiting on <0x0e4209c0> (a java.lang.UNIXProcess)
| at java.lang.Object.wait(Object.java:474)
| at java.lang.UNIXProcess.waitFor(UNIXProcess.java:112)
| - locked <0x0e4209c0> (a java.lang.UNIXProcess)
| at org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:146)
| at org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:98)
| at org.apache.maven.surefire.booter.SurefireBooter.fork(SurefireBooter.java:673)
| at org.apache.maven.surefire.booter.SurefireBooter.forkSuite(SurefireBooter.java:493)
| at org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:412)
| at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249)
| at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:537)
| at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
| at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
| at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
| at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
| at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
| at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
| at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
| at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
|
| "VM Thread" prio=9 tid=0x01205bd0 nid=0x2012600 runnable
|
| "VM Periodic Task Thread" prio=9 tid=0x01208960 nid=0x2024a00 waiting on condition
|
| "Exception Catcher Thread" prio=10 tid=0x010006e0 nid=0x804200 runnable
|
I've not been able to reproduce this, so I'm not sure if it is something to worry about or if it was something weird in the JDK since it was the first time I was using it after installing it?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270149#4270149
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270149
15 years
[JBoss AS Development] - JBAS-7507: UserTransaction & Nested Transactions
by jiwils
This thread is for discussing JBAS-7507 and its implementation.
When nested transactions support is explicitly disabled (the default), we need to throwing a NotSupportedException if a remote (or even local) client calls UserTransaction.begin() twice on the same thread with no rollback/commit in between.
A larger question is whether or not we should be supporting nested transactions at all. While Arjuna supports them, it seems that there is little practical application for them based on comments from Mark Little and others since not many resource managers support them. If we don't throw a NotSupportedException when the Arjuna nested transactions flag is enabled, then we have to ensure that code like the tx sticky load balancing policies support them (more work, and I imagine there are many other examples too).
Dimitris asked that we discuss the implementation for the throwing of the NSE in the disabled case, and that's the focus of JBAS-7507, but I think there is potentially a larger question here too (that may be a different discussion, however).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270092#4270092
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270092
15 years
[JBoss Profiler Development] - Simple (hopefully) new user questions.
by ouch01
First, I've read through the documentation and *think* I have everything setup correctly.
Since I don't see any threads here about this issue, I'm pretty sure it has something to do with how I've configured it or it's just a concept error on my part.
What I've done:
1. copied the files to their correct locations and updated the jboss-profiler.conf file.
2. updated my run.conf file with the jboss-profiler tags.
3. restarted jboss
4. called the command line client with "startProfiler"
(4.1 I also called the command line client with "enable" here during one of my tests).
5. run my web services calls to JBoss.
7. Here I have tried both:
stopProfiler, getSnapShot
and just
getSnapShot
My problem. All the time values for all of the objects/methods are 0.00 ms. I see no threads, no "Most Time" values, no hot spots nothing.
Am I just missing something simple? Do I HAVE to instrument the code somehow? am I not turning something on correctly? It seems like the profiler is working, but I get no data.
Michael
---------- Example of output ----------------
Overview
From 10 December 2009 20:42:47:489
To 10 December 2009 20:57:59:967
Total 912478.00 ms
Threads
Name Time
Most time
Count Ms Avg % Method
Hotspots
Count Ms Avg % Method
Classes
Name Type Time
com.prodeasystems.rsc.am.app.AMApplicationManager JMX_MBEAN 0.00 ms
com.prodeasystems.rsc.am.business.ActivationResponse POJO 0.00 ms
com.prodeasystems.rsc.am.business.KeyResponse POJO 0.00 ms
com.prodeasystems.rsc.am.business.RhcKeyResponse POJO 0.00 ms
com.prodeasystems.rsc.am.business.impl.AMProvisioningManagerImpl
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270086#4270086
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270086
15 years