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

[Management Development] - createdProgrammatically Property

by nmalki

Hello, I would like to know what does the createdProgrammatically Property of the Topic/Queue represent? We are using ManagementView in order to create Queue/Topic. When we get the createdProgrammatically Property of Queue (for example) using managedComponent.getProperty we get false value. Is it bug? Or what should be the expected value of "createdProgrammaticall"? Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251274#4251274 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251274

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Deploying ValidatorFactory

by stan.silvert＠jboss.com

I did another svn update and I got everything to build now. Your code isn't working: 14:40:28,347 ERROR [[/jbossws]] Error configuring application listener of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener | java.lang.NoClassDefFoundError: org/jboss/mc/servlet/vdf/spi/VDFConnector | at java.lang.Class.getDeclaredConstructors0(Native Method) | at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) If you want to run my unit test: 1) Build AS 5.2 2) Build testsuite 3) Start AS 5.2 4) cd to testsuite and run: build one-test -Dtest=org.jboss.test.web.test.JSFIntegrationUnitTestCase View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251273#4251273 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251273

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: VFSClassLoaderPolicy backed jboss-cl performance issue

by jaikiran

I looked at this in a bit more detail and i think this can be optimized, although i don't have the exact changes that we need to do. Here's a more detailed version of the flow: 1) The BaseClassLoader is invoked to load a class 2) The BaseClassloader delegates this to the appropriate BaseClassLoaderDomain 3) The domain has knowledge of the EXPORTs and also the package capabilities (i.e. which package is available in which jar) of those EXPORTs. 4) The domain then selects a collection of such EXPORTs to identify the correct classloader out of those. 5) In order to identify the correct loader, it asks each of those, through a getResource(String classResourceName) call whether it contains that resource. Actually, this is more of a isResourceAvailable type of boolean call where it doesn't care of the returned URL. 6) If #5 indicates that the loader contains the necessary resource, then this loader is selected and scheduled for loading the class. The problem starts in #5 when the VFSClassLoaderPolicy is used. Specifically when the VFSClassLoaderPolicy.getResource(String classResourceName) is called, it starts looking in various "roots" to see if that resource is available within any of its known roots. While doing this, internally the each of the file handlers are invoked which ultimately lead to AbstractVirtualFileHandler.structureFindChild(String classResourceName) first splits the resource path name into multiple tokens (through PathTokenizer). This in itself is expensive because of the various String operations involved: PathTokenizer.getTokens(): | public static List<String> getTokens(String path) | { | if (path == null) | throw new IllegalArgumentException("Null path"); | | int start = -1, length = path.length(), state = STATE_INITIAL; | char ch; | List<String> list = new ArrayList<String>(); | | for (int index = 0; index < length; index ++) { | ch = path.charAt(index); | switch (ch) { | case '/': { | switch (state) { | case STATE_INITIAL: { | // skip extra leading / | continue; | } | case STATE_MAYBE_CURRENT_PATH: { | // it's '.' | list.add(CURRENT_PATH); | state = STATE_INITIAL; | continue; | } | case STATE_MAYBE_REVERSE_PATH: { | // it's '..' | list.add(REVERSE_PATH); | state = STATE_INITIAL; | continue; | } | case STATE_NORMAL: { | // it's just a normal path segment | list.add(path.substring(start, index)); | state = STATE_INITIAL; | continue; | } | } | continue; | } | case '.': { | switch (state) { | case STATE_INITIAL: { | // . is the first char; might be a special token | state = STATE_MAYBE_CURRENT_PATH; | start = index; | continue; | } | case STATE_MAYBE_CURRENT_PATH: { | // the second . in a row... | state = STATE_MAYBE_REVERSE_PATH; | continue; | } | case STATE_MAYBE_REVERSE_PATH: { | // the third . in a row, guess it's just a weird path name | if (errorOnSuspiciousTokens) { | throw new IllegalArgumentException("Illegal suspicious token in path: " + path); | } | state = STATE_NORMAL; | continue; | } | } | continue; | } | default: { | switch (state) { | case STATE_INITIAL: { | state = STATE_NORMAL; | start = index; | continue; | } | case STATE_MAYBE_CURRENT_PATH: | case STATE_MAYBE_REVERSE_PATH: { | if (errorOnSuspiciousTokens) { | throw new IllegalArgumentException("Illegal suspicious token in path: " + path); | } | state = STATE_NORMAL; | } | } | } | } | } | // handle the last token | switch (state) { | case STATE_INITIAL: { | // trailing / | break; | } | case STATE_MAYBE_CURRENT_PATH: { | list.add(CURRENT_PATH); | break; | } | case STATE_MAYBE_REVERSE_PATH: { | list.add(REVERSE_PATH); | break; | } | case STATE_NORMAL: { | list.add(path.substring(start)); | break; | } | } | | return list; | } | For each of this token, the control is passed to the FileHandlers. One such handler is the ZipEntryHandler. And from what i see, the main reason why the loading of a class shows up as expensive is a result of our ZipEntryHandler. Here are some of the things it does almost for all operations. But in the current use case let's just consider the getChild(String path) method: i) ZipEntryHandler.getChild -> First gets the correct ZipEntryContext and then calls the getChild on the context. Any operations on the ZipEntryContext go through a isModified check which involves a call to System.currentTimeInMillis to get the current time and then comparing it with the earlier time. Do we need to do this modification check? This check happens almost on all operations on the context: | VirtualFileHandler getChild(ZipEntryHandler parent, String name) | { | if (parent == null) | throw new IllegalArgumentException("Null parent"); | | checkIfModified(); | | String pathName = parent.getLocalPathName(); | if("".equals(pathName)) | pathName = name; | else | pathName = pathName + "/" + name; | | EntryInfo ei = entries.get(pathName); | if(ei != null) | return ei.handler; | | return null; | } | | | private synchronized void checkIfModified() | { | // TODO: if zipSource represents a nested archive we should maybe delegate lastModified to its parent | if (initStatus == InitializationStatus.NOT_INITIALIZED) | { | ensureEntries(); | } | else if (initStatus == InitializationStatus.INITIALIZED && getZipSource().hasBeenModified()) | { | EntryInfo rootInfo = entries.get(""); | entries.clear(); | entries.put("", rootInfo); | | if (getZipSource().exists()) | { | try | { | initEntries(); | } | catch(Exception ignored) | { | log.warn("IGNORING: Failed to reinitialize context: " + getRootURI(), ignored); | } | } | } | } | ii) Within this flow, there's even an invocation to ZipEntryHandler.isLeaf(). Similar to the isModified call, this internally checks whether the zip context is closed. The isLeaf() implementation itself is a bit expensive since it's not a simple boolean check and instead does a .equals() on AbstractVirtualFileHandler: ZipEntryContext.isLeaf: | boolean isLeaf(ZipEntryHandler handler) | { | if (handler == null) | throw new IllegalArgumentException("Null handler"); | | if (getRoot().equals(handler) == false) | checkIfModified(); | | EntryInfo ei = entries.get(handler.getLocalPathName()); | if (ei == null || ei.entry == null) | return false; | | return ei.entry.isDirectory() == false; | } | AbstractVirtualFileHandler.equals() | public boolean equals(Object obj) | { | if (this == obj) | return true; | if (obj == null || obj instanceof VirtualFileHandler == false) | return false; | VirtualFileHandler other = (VirtualFileHandler) obj; | if (getVFSContext().equals(other.getVFSContext()) == false) | return false; | if (getPathName().equals(other.getPathName()) == false) | return false; | return true; | } | | So overall, in order to find whether a zip (jar) file contains a given class resource (remember we already know it contains the package, we are just checking whether it contains the specific class) we do a lot of expensive operations. I haven't completely looked at the ZipEntryHandler/Context, but would it be possible to have some sort of a mapping which has the entries contained in that jar? I see that we are doing something similar in the initEntries() but not sure whether it can be used. So if we wanted to check if a given resource is available in the ZipEntryContext, maybe we could just do a entries.containsKey(resourcePath)? Would it be possible to simplify the zip entry handling? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251266#4251266 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251266

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Deploying ValidatorFactory

by stan.silvert＠jboss.com

"alesj" wrote : "stan.silvert(a)jboss.com" wrote : | | I'll run the unit test against the new code and then merge to trunk. | | | Does this then mean that you already ported my VF-deployer code to trunk? | Otherwise new code won't kick in - it fall backs to old V::buildDefaultValidatorFactory code. No, I'm not that fast! :-) I'm going to make sure it works in 5.2 before I port to trunk. Unfortunately, right now there is an error that keeps testsuite from building. Stan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251262#4251262 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251262

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - HOWTO chage the behaviour of the CL policy

by thomas.diesler＠jboss.com

Currently bundle class loading uses VFSClassLoaderPolicy, which seems to load the class from the private packages first rather than considering imports. This is related to https://jira.jboss.org/jira/browse/JBOSGI-135 How can I configure/swap the policy being used? More specifically I see in BaseClassLoaderDomain that | Loader findLoaderInImports(ClassLoaderInformation info, String name, boolean trace) | { | List<? extends DelegateLoader> delegates = info.getDelegates(); | if (delegates == null || delegates.isEmpty()) | { | if (trace) | log.trace(this + " not loading " + name + " from imports it has no delegates"); | return null; | } | does not have delegates for imports. At the end of the day I want org.apache.felix.log.jar to load [org.osgi.service.log.LogService] from org.osgi.compendium.jar You can reproduce the issue by running | [tdiesler@tdvaio trunk]$ mvn -Dtest=SimpleLogServiceTestCase test | | Running org.jboss.test.osgi.integration.simple.SimpleLogServiceTestCase | FIXME [JBOSGI-135] Cannot handle package beeing imported and exported by the same bundle | Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.355 sec | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251255#4251255 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251255

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Deploying ValidatorFactory

by alesj

"stan.silvert(a)jboss.com" wrote : | I'll run the unit test against the new code and then merge to trunk. | Does this then mean that you already ported my VF-deployer code to trunk? Otherwise new code won't kick in - it fall backs to old V::buildDefaultValidatorFactory code. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251248#4251248 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251248

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Deploying ValidatorFactory

by stan.silvert＠jboss.com

"alesj" wrote : Done - committed to Branch 5_x. | Can you merge with trunk? Yes. I'll run the unit test against the new code and then merge to trunk. Thanks, Stan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251245#4251245 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251245

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Deploying ValidatorFactory

by alesj

Done - committed to Branch 5_x. Can you merge with trunk? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251243#4251243 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251243

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Bundle.start() does not transition to ACTIVE

by thomas.diesler＠jboss.com

Yes, I agree. The OSGiBundleClassLoadingDeployer currently contains this TODO [core] // [TODO] Import package requirements should probably resolve against export capabilities boolean isExportPackage = exportedNames.contains(packageName); [/core] The configured system packages are now set as a filter on the parent domain. Please see OSGiClassLoaderSystem for details. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251227#4251227 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251227

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Bundle.start() does not transition to ACTIVE

by alesj

"thomas.diesler(a)jboss.com" wrote : | I fixed by only adding PackageRequirement for packages that are not system and not exported. | This looks like a hack, at least the "not exported" part. Where it might make sense for system stuff, which doesn't go over MC's CLDescribe deployer, hence not describing its exporting packages --> making sense to exclude them. But I don't see why this would be useful for imports? The imports are declarative info, so why should it be excluded if it's also found in exports? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251225#4251225 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251225

16 years, 7 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