Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ajdt-dev] Can't determine superclass of missing type (was Weaving into a "read-only" project) 
Hi Andy,
 
Improvements sound good.
 
I think a wiki page is needed here to evolve a comprehensive FAQ around
this (although I suspect I wouldn't be able to edit it..?).
 
There is an update from me later in the thread, where the following
behaviour is found:

"My configuration is now:
base (Java project)
 - Java classpath
   - itext.jar (not exported)
   - jbcl.jar (exported - I don't want to have to export this)
   - jcommon.jar (exported - nor this)

base-facade (AJ project)
 - Java classpath
   - base (project)
 - inpath
   - base/libs/itext.jar 
   - base (project)

The results in base base's bin/ dir are the classes of:
 - base-facade
 - base
 - itext
 - jbcl (possibly getting woven even though I don't want it to)
 - jcommon (ditto)

There should be no need to unpackage jbcl & jcommon here, and I
certainly don't want them woven."
 
 
Essentially, my view is that if I do not specifically include a jar on
the inpath, I don't want it woven, and don't expect to see it's .class
files appearing in /bin
 


________________________________

	From: ajdt-dev-bounces@xxxxxxxxxxx
[mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
	Sent: 02 March 2009 17:07
	To: ajdt-dev@xxxxxxxxxxx
	Subject: Re: [ajdt-dev] Can't determine superclass of missing
type (was Weaving into a "read-only" project)
	
	
	Firstly, i apologise for jumping in mid thread. it just caught
my eye this morning, hope I'm not contradicting anyone.
	
	> The weaver seems to want to have it on the inpath, which I'd
have
	> thought shouldn't be necessary (surely we can weave a jar in
isolation
	> from those it depends on).
	
	As a specific example, suppose I wrote 
	
	before(): call(SomeInterface+.new(..)) {}
	
	Then we had the code: PaneLayout paneLayout1 = new PaneLayout();
	
	How would I know if PaneLayout implements SomeInterface?
AspectJ needs to see it, and see what it's supertypes are.  Effectively
for completeness it ought to have access to everything that was used to
build the code.  Now you can rework your pointcuts/advice to limit how
much exploration of the type system is necessary by AspectJ - it will
only analyse what it needs to.
	
	That said, there might well be bugs where too much analysis is
done, or further possibilities for optimization - but we would need to
go into deep details of each case - feel free to raise a few on AspectJ
bugzilla if you want to explore them, but I'll need to know quite a bit
of info.
	
	We also have an enhancement on the 'back burner' that situations
like this would result in extra runtime tests.  So if I can't find a
type at compile time, all I can do is insert a test for what I wanted to
confirm into the code - but that is paying a heavy price at runtime
because the class wasn't passed in earlier...
	
	> Inpath seems rather broken, and my only solution would seem to
be to put
	> everything in the same project, which I've already had, and
found
	> horrendously slow.
	
	that doesn't sound right.  In order to satisfy any dependencies
(like PaneLayout above), AspectJ only needs access to the type from the
classpath, it doesn't need it on any inpath or aspectpath.
	
	cheers,
	Andy.
	
	
	
	
	
	2009/3/2 Neale Upstone <neale.upstone@xxxxxxxxxx>
	

		Thanks Andrew,
		
		I think we've got some corner cases here that need
looking at, which
		I'll post as separate threads.
		
		
		I set up as you suggested (which is thankfully what I'd
guessed) and
		there's another complication.  There is another library
in 'base'
		jbcl.jar (mmm... ;), which I don't want to weave into.
		
		The weaver seems to want to have it on the inpath, which
I'd have
		thought shouldn't be necessary (surely we can weave a
jar in isolation
		from those it depends on).
		
		The error I get is:
		can't determine superclass of missing type
		com.borland.jbcl.layout.PaneLayout
		when weaving type JDL_ColorChooser
		when weaving classes
		when weaving
		when batch building
BuildConfig[C:\Apps\eclipse\emini-facade] #Files=76
		AopXmls=#0
		 [Xlint:cantFindType]
		
		The only use of PaneLayout is simply the field:
PaneLayout paneLayout1 =
		new PaneLayout();
		
		
		Cheers,
		
		Neale
		
		
		
		
		
		> -----Original Message-----
		> From: ajdt-dev-bounces@xxxxxxxxxxx
		> [mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
Andrew Eisenberg
		> Sent: 27 February 2009 18:09
		> To: ajdt-dev@xxxxxxxxxxx
		> Subject: Re: [ajdt-dev] Weaving into a "read-only"
project
		>
		> If I understand what you want to do correctly, this
should work:
		>
		> 1. put base on the inpath of base-facade.  If
itext.jar is a required
		> library of base, then it should be included in the
inpath.
		> Essentially, this means that all of base's class files
are sent to
		> base-facade's weaver and woven classes are spit out in
the default
		> output location.
		>
		> 2. If you want, you can specify an inpath-out-jar in
the AspectJ
		> project build path page in the inpath tab.  This will
separate the
		> woven class files from base-facade from the woven
files of base.
		>
		> 3. Then app should put base-facade as a required
project (and possibly
		> the inpath out jar if you specified one).
		>
		> Please let me know if this works for you.
		>
		> On Fri, Feb 27, 2009 at 9:55 AM, Neale Upstone
		> <neale.upstone@xxxxxxxxxx> wrote:
		> > I have 3 Java projects with some interesting
dependencies, and I'm
		> > struggling to understand how to let AJDT know what
to do:
		> >
		> > The projects are app, base-facade, and base.
		> >
		> > 'base' is read-only.
		> >
		> > We want to weave into base, and also into at least
one of
		> it's referenced
		> > libraries (itext.jar in this case), so we have a
project
		> that depends on
		> > base, called base-facade.
		> >
		> > 'app' does nothing with aspects, and wants to see
		> base-facade and a woven
		> > version of base and any libs in base that were woven
into.
		> >
		> > Ideally:
		> > - I don't want base to be an AJ project, as I just
want to
		> bring it into my
		> > workspace.
		> > - I don't want to be running any ant scripts
		> >
		> > I've solved the problem for the build server (using
iajc to
		> weave base and
		> > itext.jar).
		> >
		> > Cheers,
		> >
		> > Neale
		> >
		> >
		>
**********************************************************************
		> >
	
**********************************************************************
		IMPORTANT NOTICE.
		Confidentiality:  This e-mail and its attachments are
intended for the above named only and may be confidential.  If they have
come to you in error you must take no action based on them, nor must you
copy or show them to anyone; please reply to this e-mail and highlight
the error.
		Security Warning:  Please note that this e-mail has been
created in the knowledge that Internet e-mail is not a 100% secure
communications medium.
		We advise that you understand and observe this lack of
security when e-mailing us.
		Viruses:  Although we have taken steps to ensure that
this e-mail and attachments are free from any virus, we advise that in
keeping with good computing practice the recipient should ensure they
are actually virus free.
		Monitoring and Scanning:  Cambridge Cognition has
monitoring and scanning systems in place in relation to emails sent and
received to: monitor / record business communications; prevent and
detect crime; investigate the use of the Company's internal and external
email system; and provide evidence of compliance with business
practices.
		
		Cambridge Cognition Limited
		Company Registration Number 4338746
		Registered address:
		Tunbridge Court
		Tunbridge Lane
		Bottisham
		Cambridge
		CB25 9TU
		UK
	
**********************************************************************
		
		_______________________________________________
		ajdt-dev mailing list
		ajdt-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/ajdt-dev
		


**********************************************************************
IMPORTANT NOTICE.
Confidentiality:  This e-mail and its attachments are intended for the above named only and may be confidential.  If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this e-mail and highlight the error.
Security Warning:  Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium.
We advise that you understand and observe this lack of security when e-mailing us.
Viruses:  Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Monitoring and Scanning:  Cambridge Cognition has monitoring and scanning systems in place in relation to emails sent and received to: monitor / record business communications; prevent and detect crime; investigate the use of the Company's internal and external email system; and provide evidence of compliance with business practices.

Cambridge Cognition Limited
Company Registration Number 4338746
Registered address:
Tunbridge Court
Tunbridge Lane
Bottisham
Cambridge
CB25 9TU
UK
**********************************************************************

Back to the top