September 2009 - jboss-dev-forums

[JBoss Cache Development] - Re: Regarding Jboss Cache with Jboss Applicaion Server

by sawan1424

Hi , I just want to know how to to use Jboss Cache in Jboss Application Server for new Java Project.Please provide me the procedure to integrate with Jboss AS. As per my understanding says,For new project I have to put jbosscache-pojo.jar , jbosscache-core-sources.jar and jbosscache-core.jar . And try to use Cache feature.Please tell me "Am I right ? " as well as correct procedure to add cache functionality. Thanks Sandy View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255644#4255644 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255644

16 years, 6 months

1
0
0 / 0

[JBoss AS Development] - Re: getResources in BaseClassLoader, ClassLoaderDomain, and

by ttarhan

I went ahead and posted a patch to the JIRA to handle item #1 listed above. I also posted a snapshot of jboss-classloader.jar which is built with the patch against tags/2.0.6.GA, thus making it a drop-in replacement for JBoss 5.1.0.GA. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255643#4255643 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255643

16 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Potential deadlock in ClassLoaderManager

by thomas.diesler＠jboss.com

HttpServiceTestCase approximately fails on every third run (without trace). In which case you would see | [tdiesler@tdvaio example]$ mvn -Dtest=HttpServiceTestCase test | | Running org.jboss.test.osgi.example.http.HttpServiceTestCase | FIXME [JBCL-116] Potential deadlock in ClassLoaderManager | Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.233 | https://jira.jboss.org/jira/browse/JBCL-116 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255638#4255638 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255638

16 years, 6 months

1
0
0 / 0

[JBoss AS Development] - Re: Performance issue: VFSClassLoaderPolicy uses URL.hashCod

by ttarhan

We can discuss the larger API issue here: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255635 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255636#4255636 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255636

16 years, 6 months

1
0
0 / 0

[JBoss AS Development] - Re: getResources in BaseClassLoader, ClassLoaderDomain, and

by ttarhan

Added to JIRA as well, although maybe this is premature? https://jira.jboss.org/jira/browse/JBCL-118 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255635#4255635 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255635

16 years, 6 months

1
0
0 / 0

[JBoss AS Development] - getResources in BaseClassLoader, ClassLoaderDomain, and frie

by ttarhan

Folks, BaseClassLoader, ClassLoaderDomain and several other classes in JBossCL have public API methods which take Set as a parameter. We can't control what implementation of Set is passed in to these methods, but HashSet is commonly used, causing the URL.hashCode() performance problem (DNS lookup). I do not understand enough about the public API of JBossCL to know where these methods might be used from. However, I do know that these methods are called internally from several areas in JBossCL with a HashSet. I see a two-step solution: 1) Change anywhere in JBossCL where HashSet is used to another Set implementation. This is a quick and non-API-breaking change that will actually take care of the most common scenarios. An example (from user code in the container): ClassLoader.getResources(String) eventually calls BaseClassLoader.loadResources(String) which creates a HashSet and passes that to ClassLoaderDomain.getResources(...) to be filled in, eventually returning the HashSet to the caller. Changing the internal usage of ClassLoaderDomain and friends to use a Set other than HashSet would fix this scenario. 2) Consider if there is an API change required to prevent misuse of this by callers outside of JBossCL. I'm not sure if any of these methods are intended to be used from outside. Some are public, some are not. I'm willing to tackle solution #1 and may submit a patch later this evening. However, I need some help/discussion/advice before I could tackle #2. Thoughts? Comments? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255634#4255634 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255634

16 years, 6 months

1
0
0 / 0

[JBoss AS Development] - Re: Performance issue: VFSClassLoaderPolicy uses URL.hashCod

by ttarhan

Jason, The issue also appears on line 526 of VFSClassLoaderPolicy when we call urls.add(child.toURL()) where urls is an object of type Set passed in to getResources. Causes the exact same symptoms, at slightly different times. This is a little trickier than the previous case since the Set is passed-in from the caller. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255630#4255630 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255630

16 years, 6 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Deployment isolation problem with ear being ported from Webl

by jwchristy

I have an ancient weblogic-hosted J2EE application (2003ish) that I am porting to Jboss 4.2.3.GA. It uses old versions of lots of 3rd party tools, including JAXB, version 1.0.4. I have gotten the ear to deploy cleanly by removing those 3rd party jars from the ear that conflict with jars already in use by the Jboss server, and the application almost runs, but hits problems when it tries to get an old JAXB ContextFactory class that no longer exists in the version of JAXB that the Jboss server is using, 2.1.4. I then went down the path of putting the old jars back into the ear and doing an isolated deployment, in the hope that I could use the old JAXB. I am using this deployment descriptor in the ear: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd"> <jboss-app> <loader-repository> com.ghx:archive=cm.ear <loader-repository-config> java2ParentDelegation=false </loader-repository-config> </loader-repository> </jboss-app> However, now it appears that various components within the ear can no longer see each other. The deployment is bombing when an application class in an included jar tries to find an xml document in another included jar. This worked fine with a non-isolated deployment. Help, what am I doing wrong? The ear has 4 EJB jars, a war, numerous jars of application code, and even more jars of 3rd party library code (about 50 total jars/war within the ear). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255598#4255598 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255598

16 years, 6 months

1
0
0 / 0

[JBoss XML Binding Development] - Re: XB profiling during the AS start-up

by alex.loubyansky＠jboss.com

I know that there are definitely things to improve in XB and I'd also like to see whether it'd be worth to spend time on it. That's why I want to at least have a picture of what's going on with the current impl. I don't think there have been an effort to get it. You can't avoid pure XML parsing, right? The rest is what can be optimized. So, it appears that total unmarshalling time (including all the XML files) during AS start-up consists of ~33% of pure XML parsing (xerces) + ~67% of the XB code on top of it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255588#4255588 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255588

16 years, 6 months

1
0
0 / 0

[JBoss XML Binding Development] - Re: XB profiling during the AS start-up

by david.lloyd＠jboss.com

I for one would rather see investment in Bill's precompilation idea, at least to see if it's feasible, than having more effort put towards optimizing XB as it is. Pregenerated optimized code should produce the fastest possible unmarshaller (and marshaller for that matter), especially using SAX or StAX from the generated code. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255575#4255575 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255575

16 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 September 2009