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

[Design of EJB 3.0] - Re: JNDI names with a leading /

by jaikiran

"ALRubinger" wrote : | My personal opinion is that we should throw some descriptive error if the first character of the jndiName is '/'. | | However, if we wanna be nice, we could just as easily remove... | Maybe a combination of both - Log a WARN message telling the user that the jndi name will be stripped of the leading / and we then go ahead remove those leading / while binding. "ALRubinger" wrote : | all leading "/" from the String (recursively until done). | | Good point - Hadn't thought of the multiple leading / case :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249121#4249121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249121

16 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI names with a leading /

by ALRubinger

So it binds something it cannot lookup. :) We haven't documented any support for absolute JNDI references (everything goes into global JNDI anyway), so I don't think we much need to worry about backwards compatibility for breaking user's cases (like our test is). My personal opinion is that we should throw some descriptive error if the first character of the jndiName is '/'. However, if we wanna be nice, we could just as easily remove all leading "/" from the String (recursively until done). S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249120#4249120 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249120

16 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - JNDI names with a leading /

by jaikiran

I have a fix for https://jira.jboss.org/jira/browse/EJBTHREE-1884 in which, i now bind the remote ProxyFactory to the JNDI. A local testsuite run after this fix, has exposed a couple of other issues, one of which is in the testcases. The other one is related to clustered stateful beans loadbalancing which is have to investigate a bit more (to understand why it was expected to work the way its currently configured). The testsuite issue i am talking about is in the org.jboss.ejb3.test.jms.managed.unit.ManagedTestCase which deploys a JMSTestBean with a remote jndi binding for the session bean: <session> | <ejb-name>JMSTest</ejb-name> | | <resource-ref> | <res-ref-name>jms/MyConnectionFactory</res-ref-name> | <resource-name>connectionfactoryref</resource-name> | </resource-ref> | <resource-ref> | <res-ref-name>jms/MyQueue</res-ref-name> | <resource-name>queueref</resource-name> | </resource-ref> | | <jndi-name>/jms-test-ejbs/JMSTest</jndi-name> | </session> | Notice the leading / in the JNDI name. This results in our proxy-impl generating the jndi name for the default business interface as: /jms-test-ejbs/JMSTest - EJB3.x Default Remote Business Interface And the remote proxyfactory being bound in JNDI and registered in MC with the following key: ProxyFactory/jms-managed/JMSTest//jms-test-ejbs/JMSTest Notice the double // in the name. This binds fine in JNDI: +- ProxyFactory (class: org.jnp.interfaces.NamingContext) | | | +- jms-managed (class: org.jnp.interfaces.NamingContext) | | | +- JMSTest (class: org.jnp.interfaces.NamingContext) | | | | +- jms-test-ejbs (class: org.jnp.interfaces.NamingContext) | | | | | +- JMSTest (proxy: $Proxy257 implements interface But when the ProxyFactory is looked up in the JNDI, it fails with NameNotFoundException: 10:10:31,701 ERROR [STDERR] javax.naming.NameNotFoundException: not bound | 10:10:31,701 ERROR [STDERR] at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) | 10:10:31,701 ERROR [STDERR] at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) While doing the lookup, it internally splits the names on the / and obviously runs into this exception because of the double //. IMO, we should fix this by our jndi binding logic (JNDISessionRegistrarBase) to strip any leading /. But what do others think? Possible options are: 1) Change the testcase to not use the leading / in the jndi-name. (Not an ideal fix, since end users too might end up with this exception if they do something similar). 2) Fix our jndi binding code. I think this is the ideal solution 3) Change the name lookup code (in jboss-naming) to parse this differently. I guess, this should not even be an option, since its not the responsibility of that piece of code to do the cleaning :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249118#4249118 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249118

16 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JVMTI committed on Branch_2_0

by clebert.suconic＠jboss.com

anonymous wrote : Also, the current code already has some support for inspecting methods. It's crashing but it's an initial version already. | I meant native profiling by this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249117#4249117 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249117

16 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JVMTI committed on Branch_2_0

by clebert.suconic＠jboss.com

There is a test called org.jboss.profiler.test.jvmti.JVMTIWebTestManual I don't have an ant target for it yet. But if you run it through eclipse, you would be able to see the simple web interface. You have to add those two parameters on the JDK: -Djava.library.path=/work/projects/prof2/src/native/ -agentpath:/work/projects/prof2/src/native/libJBossProfiler.so Or define LD_LIBRARY_PATH, and only add one: -agentlib:JBossProfiler View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249116#4249116 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249116

16 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - JVMTI committed on Branch_2_0

by clebert.suconic＠jboss.com

I just committed JVMTIInterface on JBossProfiler2. One of the good things on JBoss profiler 1 was the JVMTI module, that can be automated through JNI. There are a few tests using it on JBoss AS, and I think this is perfectly aligned with JBoss Profiler 2. Jason was looking for a replacement of the JVMTI for a final version on JBAS, so I think this would be a good solution. I've also added a few features around memory profiler. I had a few leaks to chase on JBoss Messaging 2, and the best way to find them was by creating a few reports instead of spending a lot of time on tinkering with JVMTI Interface. It is possible now to call a method startMemoryProfiler(InetAddress). That method will start a small embedded Web Server (available on JDK 1.6+), and you would be able to link on references through the JVM (All live). I've kept the build using Cmake. It should be fairly simple to compile it. Also, the current code already has some support for inspecting methods. It's crashing but it's an initial version already. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249114#4249114 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249114

16 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: ERROR: JVMPI, an experimental interface, is no longer su

by clebert.suconic＠jboss.com

I just committed a memory profiler on Branch_2_0... look at my post on dev forum now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249113#4249113 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249113

16 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JUnit holds the test references until the end of the suite c

by clebert.suconic＠jboss.com

This is to confirm what I suspected here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=159702 Say that you have this test: public class SomeTest extends TestCase | { | | // Constants ----------------------------------------------------- | | // Attributes ---------------------------------------------------- | | Server server; | | // Static -------------------------------------------------------- | | // Constructors -------------------------------------------------- | | // Public -------------------------------------------------------- | | public void setUp() | { | ts = new SomeClass(); | } | | public void testOne() throws Exception | { | System.gc(); | Thread.sleep(1000); | } | | public void testOneA() throws Exception | { | System.gc(); | Thread.sleep(1000); | } | JUnit will hold one reference of the Server for each method on the test. Those referencess will be released only at the end of the class. So it would be great if as a best practice, we set any big object to null on tearDown. (Things like servers, connections... etc). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249094#4249094 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249094

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Abstract Beans JBKERNEL-10

by kabir.khan＠jboss.com

The problem in doing this refactoring is that BeanMetaDataBuilder (which can be changed) and JBoss XB (which cannot be changed) do something like: | BeanMetaData bmd = ...; | HashSet<PropertyMetaData> properties = bmd.getProperties(); | if (properties == null) | { | properties = new HashSet<PropertyMetaData>(); | bmd.setProperties(properties); | } | properties.add(propertyMetaData1); | properties.add(propertyMetaData2); | So if we copy the set into a map when calling BMD.setProperties() the properties.add() calls do not get reflected in the underlying data in the map. I have looked into writing a Map enabled wrapper around the passed in set, but since we will need to work with the set underneath there does not seem to be that much point. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249082#4249082 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249082

16 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Does ScopeKey need to maintain a sorted (in ScopeLevel.l

by jason.greene＠jboss.com

Yeah, I agree with Adrian, this approach is better than my suggestion since its less work and we can likely merge it into the 5.x series. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249073#4249073 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249073

16 years, 8 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 August 2009