[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Ales Justin
JBoss development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/531337#531337
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
>
>
>
>
> I have not added caching yet, and adding this simple test passes with the introspection implementation, but fails with the Javassist implementation
>
> *public* Comparable<String> signatureCachedParameterizedClassInfo()
> {
> *return* *null*;
> }
>
> *public* *void* testCachedParameterizedClassInfo() *throws* Throwable
> {
> Type type = getGenericReturnType("signatureCachedParameterizedClassInfo");
> TypeInfo typeInfo1 = getTypeInfoFactory().getTypeInfo(type);
> TypeInfo typeInfo2 = getTypeInfoFactory().getTypeInfo(getGenericReturnType("signatureCachedParameterizedClassInfo"));
> assertEquals(typeInfo1, typeInfo2);
> assertSame(typeInfo1, typeInfo2); // <-- FAILS
>
> //Also check the results of repeated calls to getGenericSuperClass/-Interfaces() etc.
> }
>
>
>
>
> Is this object equality a requirement? My fear is that working out the key will be costly
My first answer is yes, but you can convince we otherwise. ;-)
As all of the stuff in Reflect works this was, why is this here a problem?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531337#531337
16 years
[JBoss Microcontainer Development] New message: "Updating ClassPool version at JBoss Deployers project"
by Flavia Rainone
JBoss development,
A new message was posted in the thread "Updating ClassPool version at JBoss Deployers project":
http://community.jboss.org/message/531223#531223
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
I'm updating the version of classpool to 2.0.0.Alpha4 in jboss-deployers:
https://jira.jboss.org/jira/browse/JBDEPLOY-250
As I told Ales in a private e-mail, updating the classpool version raised new requirements for the classpool tests to work (in the jboss-deployers project).
First of all, I need to set a FilteredClassPool as the SystemClassPool so that the excluded classes can be filtered out. This should be set up by a test deleagte, but, to create a delegate, I needed to break a few of the design conventions in the tests:
- my test delegate must be a subclass of BootstrapDeployersTestDelegate, but it ended up containing duplicate code:
ClassFilter classFilter = new ClassFilter()
{
// duplicate code
};
defaultClassPool = new FilteredClassPool(AbstractClassPoolFactory.getDefaultClassPool(), classFilter);
I need to use the same classFilter that is used by BootstrapDeployersTestDelegate. However, the way the code is right now, I can't have that, so I ended up duplicating this code
- my test delegate needs to be defined for only ClassPoolTestCase and JavassistTypeInfoTestCase, but not for IntrospectionTypeInfoTestCase.
Hence, I cannot apply it by implementing a getDelegate() method at ReflectTest, which would be the right place if all subclasses needed the delegate. So, I ended up adding it to ClassPoolTest and to JavassistTypeInfoTestCase. But JavassistTITC is not abstract, and, for what I can tell, it is a design convention in the project that this method should be added always to an abstract test class. On the other hand, I'm not sure if I should add a JavassistTypeInfoTest class just for that.
- following the conventions, my TestDelegate should be named after the Test class. So, if I was applying it to ReflectTest, it would be called ReflectTestDelegate. But as I'm applying it to two test classes, I don't know what to name it? I temporarily named it JavassistTestDelegate.
FYI, another change that I'm commiting is that, with VFS3 new URL format (using file://), I will also need a FilteredIsLocalResourcePlugin, so that the classes in the excluded packages can be filtered out before the URL reaches the ClassLoader level.
I'll be committing these changes for Ales to take a look and decide what is the best way of working around these design issues.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531223#531223
16 years
[JBoss ESB Development] New message: "Re: juddi.war missing in 4.7?"
by Kevin Conner
JBoss development,
A new message was posted in the thread "juddi.war missing in 4.7?":
http://community.jboss.org/message/531211#531211
Author : Kevin Conner
Profile : http://community.jboss.org/people/Kevin.Conner@jboss.com
Message:
--------------------------------------------------------------
Hiya Scott.
The juddi.war file as provided by the juddi project does not actually deploy on a stock JBoss app server and was therefore not included in the 4.7 release. In any case we do not usually use that for remote invocations, preferring instead the juddi RMI transport.
We did have a need to create our own version of that war, as part of our productisation process for 4.7, and will shortly be rolling all those changes out through the project as part of the 4.8 release.
I'll post something about 4.8 in the next couple of days and the release will occur before the end of March.
Kev
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531211#531211
16 years