January 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: VersionImpl is not correct.

by alesj

"adrian(a)jboss.org" wrote : 1) The compareTo() that uses a registry to do comparison | will only work when the specific version being tested uses the registry. | This is expected. Since you need to write a comparator anyway. It's then minimal work if you also need to write a thin wrapper over existing external Version impl. btw: our VersionIMpl was changed, and it's now the same implementation as OSGi Version Except that it knows how to compare to other internal Version impls. Or when do you expect to have direct compareTo to external Version instance? Since we control all the comparison code, we/user can also introduce thin wrappers. If you let any Version type to be present in our VersionRange, then you would have to let version be Object, which is a lot less type safe than our Version approach with comparators and thin wrappers present. Not to mention that there is exactly one external Version impl present that I'm aware of. Or what did you have in mind with your 'pass the Comparator into the VersionRange check.' approach? "adrian(a)jboss.org" wrote : | Also for HashMaps/Sets, etc. | the hashCodes will likely disagree, so they are broken. What if we put this in Version | public boolean equals(Object obj) | { | if (obj instanceof Version == false) | return false; | | VersionComparatorRegistry registry = VersionComparatorRegistry.getInstance(); | return registry.compare(this, Version.class.cast(obj)) == 0; | } | | public int hashCode() | { | return toString().hashCode(); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124908#4124908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124908

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Datasource Connection Properties using CollectionMetaType, i

by bytor99999

So the connection properties property is using a CollectionMetaType with a List of GenericMetaValues Is this the correct mapping that should be used. connection properties needs a name-value pair for each property. Should connection properties be CompositeValue types? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124905#4124905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124905

16 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - FYI - dynamicRootURL is not correctly implemented

by adrian＠jboss.org

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124886#4124886 I'll fix this since I'm working on creating a proper spi out what was previously and implementation detail. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124887#4124887 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124887

16 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - dynamicRootURL in Module

by adrian＠jboss.org

To fix the AOP dynamic class generation a "hack" has been put into the Module. This is not correct for a number of reasons. 1) It should be in the DeploymentUnit.getClassPath() where others that need the classloading roots can get at it. 2) The implementation is hardwired | | public URL getDynamicClassRoot() | { | if (dynamicClassRoot == null) | { | try | { | dynamicClassRoot = new URL("vfsmemory://" + new GUID()); | } | catch (MalformedURLException e) | { | throw new RuntimeException(e); | } | } | return dynamicClassRoot; | } | instead of allowing somebody to specify how the dynamic root is determined. 3) It uses the VFS api in a package (DeployersImpl) that should not depend on the VFS (compare the url above). This needs fixing to move it into a seperate deployer where people can (fixing the relevant problems above). 1) Access it for other uses besides creating the classloader (or creating their own classloader that isn't part of the ClassLoading system e.g. an alternate classloader implementation). 2) Determine where/how the dynamic classes are stored 3) Doesn't break the dependencies between the projects View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124886#4124886 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124886

16 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Moving out of the UnifiedClassloaders

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | But it's one of those N^2 problems in writing comparators between | | all the different versions, e.g. our own, maven, osgi, java manifest, jdk7 module system, etc. | | | I've taken this approach. | Since I doubt the N will be big. :-) | | Adding VersionComparator: | | | public interface VersionComparator<T extends Version, U extends Version> | | { | | /** | | * Compare the two version impls. | | * | | * @param t T version impl | | * @param u U version impl | | * @return compare the two version impls | | */ | | int compare(T t, U u); | | } | | | and a VersionComparatorRegistry singleton to keep all the known implementations. | | And changing the Version class to delegate the compareTo to the registry: | | | public int compareTo(Version v) | | { | | VersionComparatorRegistry registry = VersionComparatorRegistry.getInstance(); | | return registry.compare(this, v); | | } | | There are a number of issues with this, I'll start a new thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124882#4124882 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124883#4124883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124883

16 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - VersionImpl is not correct.

by adrian＠jboss.org

1) The compareTo() that uses a registry to do comparison will only work when the specific version being tested uses the registry. VersionImpl.compareTo(OSGiVersion) -> registry OSGiVersion.comapreTo(VersionImpl) does not The way I said to fix the problem was to pass the Comparator (really a registry of comparators) into the VersionRange check. 2) The equals() doesn't work as expected. | public boolean equals(Object object) | { | if (object == this) | return true; | | if (object instanceof VersionImpl == false) | return false; | | VersionImpl other = (VersionImpl)object; | return (major == other.major) && (minor == other.minor) && (micro == other.micro) && qualifier.equals(other.qualifier); | } | VersionImpl ours = VersionImpl.parse("1.0.0"); OSGiVersion osgi = OSGiVersion.parse("1.0.0"); ours.equals(osgi) == false and vice versa This one is a lot harder to fix. e.g. We can't override the equals() calls if versions (or composites thereof) are used as keys in maps. Even if we fix the above code to something like: | Version other = (Version)object; | return registry.equals(this, other); | it won't work the other way around. Also for HashMaps/Sets, etc. the hashCodes will likely disagree, so they are broken. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124882#4124882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124882

16 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: A compilation error in AbstractTypeMap, R3

by david.lloyd＠jboss.com

I think this must be an eclipse bug, since IDEA doesn't complain about it and it builds OK with ant in both JDK 1.5 and 1.6. There's certainly nothing syntactically wrong with the line that I can see... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124848#4124848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124848

16 years, 2 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: jboss-app/module-order

by scott.stark＠jboss.org

It should at least parse and produce a warning if the behavior is not supported. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124847#4124847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124847

16 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New ClassLoader initial checkin

by adrian＠jboss.org

No I haven't changed my view. The MC doesn't favour a specific classloader implementation. It is left to the configuration how you create classloaders and what type they are. There are some basic rules that need to be followed to work with what the other deployers expect. e.g. * support hierarchical domains/repositories * switching from j2se classloading compliance * delegation to peer classloaders * allowing specific imports and versioning for OSGi style deployments * (in future) filtering out certain packages, etc. All these are encapsulated by the ClassLoaderMetaData. If the classloader doesn't support these notions, (e.g. the old UCL doesn't support OSGi version rules) then those deployments won't work as expected. We could add validation to the legacy ServiceClassLoaderDeployer that creates the old UCLs to spot when it cannot support the new features, but in practice we'll probably just drop support for this old classloader implementation. So, in summary, I don't see a need to tightly integrate the classloader with the MC. The question is only whether your choice of classloader implementation can support all the features requested by the other deployers via the ClassLoaderMetadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124846#4124846 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124846

16 years, 2 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Remoting 3 deployers

by david.lloyd＠jboss.com

"alesj" wrote : But for new things, I would definitely recommend KernelDeployment/BeanMetaData. | OK, that's what I'm going with then. "alesj" wrote : If you have any issues, let me know. | Here or on the MC user forum. Hint taken. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124836#4124836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124836

16 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2008