Bug 302611 - Caused by: org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: warning can't determine implemented interfaces of missing type com.ibm.ws.sib.api.jms.JmsInternalConstants
Summary: Caused by: org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldExceptio...
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: 1.6.8   Edit
Hardware: PC Windows Server 2003
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-11 13:02 EST by relphie CLA
Modified: 2013-06-24 11:04 EDT (History)
2 users (show)

See Also:

Attachments
stack trace (2.58 KB, text/plain)
2010-02-11 13:04 EST, relphie CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description relphie CLA 2010-02-11 13:02:51 EST 
Deploying an application to Websphere Application Server 6.1.27, using Spring Framework to look up a JMS topic causes and exception on startup as Spring tries to create the WebApplicationContext.  (Stack trace attached).

Spring config for the JMS beans:

	<jee:jndi-lookup
		id="jmsTopic"
		jndi-name="jms/RepositoryTopic" />

	<jee:jndi-lookup
		id="jmsTopicConnectionFactory"
		jndi-name="jms/RepositoryTopicConnectionFactory" />

	<bean id="jmsTemplate"
		class="org.springframework.jms.core.JmsTemplate">
		<property name="connectionFactory">
			<ref
				bean="jmsTopicConnectionFactory" />
		</property>
		<property name="defaultDestination">
			<ref bean="jmsTopic" />
		</property>
		<property name="receiveTimeout">
			<value>30000</value>
		</property>
	</bean>

Spring AOP is included in the project, but it should not be applying any aspects to the JMS beans (and I don't think it would, but this exception seems to occur while trying to figure out that it shouldn't).

This exception does not occur when using aspectj 1.6.6.  I did not try using 1.6.7.
Comment 1 relphie CLA 2010-02-11 13:04:35 EST 
Created attachment 158888 [details]
stack trace
Comment 2 Andrew Clement CLA 2010-02-11 15:30:37 EST 
Do you expect the type 'com.ibm.ws.sib.api.jms.JmsInternalConstants' to be around and accessible?
Comment 3 Andrew Clement CLA 2010-02-11 15:34:13 EST 
Caused by: org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: warning can't determine implemented interfaces of missing type com.ibm.ws.sib.api.jms.JmsInternalConstants
 [Xlint:cantFindType]
	at org.aspectj.weaver.reflect.ReflectionWorld$ExceptionBasedMessageHandler.handleMessage(ReflectionWorld.java:129)
	at org.aspectj.weaver.Lint$Kind.signal(Lint.java:316)
	at org.aspectj.weaver.MissingResolvedTypeWithKnownSignature.raiseCantFindType(MissingResolvedTypeWithKnownSignature.java:232)
	at org.aspectj.weaver.MissingResolvedTypeWithKnownSignature.getDeclaredInterfaces(MissingResolvedTypeWithKnownSignature.java:86)
	at org.aspectj.weaver.ResolvedType$2.get(ResolvedType.java:304)
	at org.aspectj.weaver.ResolvedType$2.get(ResolvedType.java:300)


AspectJ 1.6.8 does use a different way of walking the type hierarchy.  It may well be it walks a different route than 1.6.6 and 1.6.6 exited early before it discovered a type it couldn't find, whereas 1.6.8 hits this type first.

If you don't think the type is around, maybe I should move errors about missing types to be reported only at the end of a match request if we can't definitively know a match is false by checking other interfaces.
Comment 4 relphie CLA 2010-02-11 15:42:03 EST 
I really do not know what the type is, as my jndi lookup / java code is simply asking for a javax.jms.TopicConnectionFactory, and doesn't care about the implementation class.  I would assume that Websphere's internal implementation classes would be available, and it seems odd that it is unavailable

If it is possible to satisfy a match request without needing every type available, it seems sensible to only exit after all type paths are exhausted the match request is still un-defined
Comment 5 relphie CLA 2010-02-11 15:44:22 EST 
Can I log out each step that is taken in the heirarchy, to see the differences between 1.6.6 and 1.6.8?
Comment 6 Andrew Clement CLA 2010-02-24 16:32:02 EST 
Unfortunately no, you cannot log the visited list of interfaces in 1.6.6 or 1.6.8.

The message is just a warning, so you could just turn off the Xlint if you believe everything is working just fine.

In the longer term I think the solution I posted in an earlier comment is the way to go: 

> move errors about missing
> types to be reported only at the end of a match request if we can't
> definitively know a match is false by checking other interfaces.
Comment 7 Andrew Clement CLA 2013-06-24 11:04:27 EDT 
unsetting the target field which is currently set for something already released