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

[JBoss Microcontainer Development] - Re: Added initial support for split packages

by adrian＠jboss.org

I don't really understand what you are trying to do? The LAST policy is certainly non-deterministic since it means the used version of a package could change at random based on what gets deployed when. That would break all the consistency checking. The idea of split packages is that two modules can provide the same exported package but only if they are at the same version. The importing module should then import BOTH (in some deterministic order - e.g. first deployed is the first to be used). The validation of the ClassLoaderSpace should not treat this as an error (which it currently does). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251572#4251572 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251572

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by adrian＠jboss.org

The issue is that this has got a slower with 2.1.2.GA. 40 seconds vs 10 seconds I can't tell which version I was using before since we now use the Maven plugin to generate the classpath. This means there's no history in .classpath files. I guess you could checkout the project from a week ago and see what it uses (assuming the snapshots haven't changed)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251565#4251565 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251565

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: FrameworkUtil and Filter implementations

by adrian＠jboss.org

It looks like the osgi code has changed for these classes. In the version I was using before, the class looked like this. (See the OSGI-INF/src folder in the r4v41 jar) | /* | * $Header: /cvshome/build/org.osgi.framework/src/org/osgi/framework/FrameworkUtil.java,v 1.10 2007/02/21 16:49:05 hargrave Exp $ | * | * Copyright (c) OSGi Alliance (2005, 2007). All Rights Reserved. | * | * Licensed under the Apache License, Version 2.0 (the "License"); | * you may not use this file except in compliance with the License. | * You may obtain a copy of the License at | * | * http://www.apache.org/licenses/LICENSE-2.0 | * | * Unless required by applicable law or agreed to in writing, software | * distributed under the License is distributed on an "AS IS" BASIS, | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | * See the License for the specific language governing permissions and | * limitations under the License. | */ | | package org.osgi.framework; | | import java.lang.reflect.*; | import java.security.AccessController; | import java.security.PrivilegedAction; | | /** | * Framework Utility class. | * | * <p> | * This class contains utility methods which access Framework functions that may | * be useful to bundles. | * | * @since 1.3 | * @ThreadSafe | * @version $Revision: 1.10 $ | */ | public class FrameworkUtil { | /* | * NOTE: A framework implementor may also choose to replace this class in | * their distribution with a class that directly interfaces with the | * framework implementation. | */ | | /* | * This class will load the FrameworkUtil class in the package named by the | * org.osgi.vendor.framework package. For each instance of this class, an | * instance of the vendor FrameworkUtil class will be created and this class | * will delegate method calls to the vendor FrameworkUtil instance. | */ | | private static class ImplHolder implements PrivilegedAction { | private static final String packageProperty = "org.osgi.vendor.framework"; | | /* | * This is the delegate method used by createFilter. | */ | static final Method createFilter; | | static { | createFilter = (Method) AccessController.doPrivileged(new ImplHolder()); | } | | private ImplHolder() { | } | | public Object run() { | String packageName = System | .getProperty(packageProperty); | if (packageName == null) { | throw new NoClassDefFoundError(packageProperty | + " property not set"); | } | | Class delegateClass; | try { | delegateClass = Class.forName(packageName | + ".FrameworkUtil"); | } | catch (ClassNotFoundException e) { | throw new NoClassDefFoundError(e.toString()); | } | | Method result; | try { | result = delegateClass.getMethod("createFilter", | new Class[] {String.class}); | } | catch (NoSuchMethodException e) { | throw new NoSuchMethodError(e.toString()); | } | | if (!Modifier.isStatic(result.getModifiers())) { | throw new NoSuchMethodError( | "createFilter method must be static"); | } | | return result; | } | } | | | /** | * FrameworkUtil objects may not be constructed. | */ | private FrameworkUtil() {} | | /** | * Creates a <code>Filter</code> object. This <code>Filter</code> object | * may be used to match a <code>ServiceReference</code> object or a | * <code>Dictionary</code> object. | * | * <p> | * If the filter cannot be parsed, an {@link InvalidSyntaxException} will be | * thrown with a human readable message where the filter became unparsable. | * | * @param filter The filter string. | * @return A <code>Filter</code> object encapsulating the filter string. | * @throws InvalidSyntaxException If <code>filter</code> contains an | * invalid filter string that cannot be parsed. | * @throws NullPointerException If <code>filter</code> is null. | * | * @see Filter | */ | public static Filter createFilter(String filter) | throws InvalidSyntaxException { | try { | try { | return (Filter) ImplHolder.createFilter | .invoke(null, new Object[] {filter}); | } | catch (InvocationTargetException e) { | throw e.getTargetException(); | } | } | catch (InvalidSyntaxException e) { | throw e; | } | catch (Error e) { | throw e; | } | catch (RuntimeException e) { | throw e; | } | catch (Throwable e) { | throw new RuntimeException(e.toString()); | } | } | } | Now the class provides its own implementation of the Filter class. So we need to decide which of the two implementations is better (the provided one or the one I wrote). I'd say it would be easier in terms of maintenance to let FrameworkUtil provide new features of the filters rather than us having to keep up. That is unless there is a serious performance issue that needs to be addressed? Currently all filter construction is delegated to FrameworkUtil so if we go with that it would just be a case of deleting my filter implementation. P.S. The same looks to be true for AdminPermission (although I never implemeted that :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251559#4251559 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251559

16 years, 7 months

1
0
0 / 0

[jBPM Development] - Re: Java Activity not using Interface

by jbpmjboss11

Ronald, I am really sorry about posting my issue in here... Tom, would you mind if I send you an email regarding why my execution is not existing anymore and more details on this issue? Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251555#4251555 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251555

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development] - Added initial support for split packages

by thomas.diesler＠jboss.com

Folks, this relates to https://jira.jboss.org/jira/browse/JBCL-25 What I've basically done is make the generated error dependent on the the SplitPackagePolicy, which can be configured at at PackageCapability | Module otherModule = modulesByPackage.get(exportedPackage); | if (otherModule != null) | { | PackageCapability exportCapability = module.getExportCapability(exportedPackage); | if (exportCapability.getSplitPackagePolicy() == SplitPackagePolicy.Error) | { | // TODO JBCL-22 ERRORS | throw new IllegalStateException(module + " cannot be added because it is exports package " + exportedPackage + " which conflicts with " + otherModule); | } | } | There is additional code that tries to swap the module for an existing export package | // Update the exported packages | if (exportedPackages != null && exportedPackages.isEmpty() == false) | { | for (String exportedPackage : exportedPackages) | { | Module firstModule = modulesByPackage.get(exportedPackage); | PackageCapability exportCapability = module.getExportCapability(exportedPackage); | if (firstModule == null || exportCapability.getSplitPackagePolicy() == SplitPackagePolicy.Last) | modulesByPackage.put(exportedPackage, module); | } | } | This however, does not work and I'd like to get some insight on how to do this properly The test that is supposed to verify SplitPackagePolicy.Last is here | public void testSplitPackageLast() throws Exception | { | MockClassLoadingMetaData ab = getModuleAB(null); | MockClassLoadingMetaData ac = getModuleAC(SplitPackagePolicy.Last); | | KernelControllerContext contextAB = install(ab); | try | { | ClassLoader clAB = assertClassLoader(contextAB); | assertLoadClass(A.class, clAB); | assertLoadClass(B.class, clAB); | | KernelControllerContext contextAC = install(ac); | ClassLoader clAC = assertClassLoader(contextAC); | System.out.println("FIXME: SplitPackagePolicy.Last"); | // assertLoadClass(A.class, clAC); | assertLoadClass(B.class, clAB); | assertLoadClass(C.class, clAC); | } | finally | { | uninstall(contextAB); | } | assertNoClassLoader(contextAB); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251548#4251548 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251548

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Circular and self dependencies

by thomas.diesler＠jboss.com

Yes will do - thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251545#4251545 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251545

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Circular and self dependencies

by kabir.khan＠jboss.com

"alesj" wrote : "adrian(a)jboss.org" wrote : | | It looks like a fix to me. Before we've only had circular references on a different state of itself. e.g. "this" | | | Kabir, can you also apply this to trunk please. Done https://jira.jboss.org/jira/browse/JBKERNEL-53 Thomas, in future please create JIRA issues in JBKERNEL for your commits there :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251542#4251542 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251542

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by alesj

I guess you're reading a lot of different manifest files. Since all of the code in VFSCLPolicy is cached. But to read manifest a lot of slow ops are present. * find the root with class file ** read-in all jars ** navigate to class file * read manifest.mf ** again navigate ** read manifest attributes Which means a lot of PathTokenizer and StructuredVirtualFileHandler usage. With VFS-performance issue already present in MC dev forum, I'll have a look what can be improved, and then re-run this here. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251540#4251540 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251540

16 years, 7 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by adrian＠jboss.org

The issue appears to be in the VFS. If I comment out the reading of the manifest for the package information (which uses the VFS) then the tests take about 16 seconds (i.e. less than half the time). BaseClassLoader::definePackage | - PackageInformation pi = policy.getClassPackageInformation(className, packageName); | + PackageInformation pi = null; | This is using jboss-vfs 2.1.2.GA View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251529#4251529 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251529

16 years, 7 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Circular and self dependencies

by alesj

"adrian(a)jboss.org" wrote : | It looks like a fix to me. Before we've only had circular references on a different state of itself. e.g. "this" | Kabir, can you also apply this to trunk please. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251526#4251526 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251526

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