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,
 
Many thanks both of you.
 
Good to see that I've not just been being daft.  I will add on to the classpath of base-facade for now, and review our pointcuts as you suggest too.  Seems to me that using within() would be a good practice to adopt.
 
June (for e3.5, aj1.7) could be an interesting date if you want a bit of extra hand with docs, as I think I'll have some time late April and early May, and want to do a week or so towards an open source project.  It has to be AspectJ as it's what won me this contract :)
 
All the best,
 
Neale


From: ajdt-dev-bounces@xxxxxxxxxxx [mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
Sent: 02 March 2009 20:17
To: ajdt-dev@xxxxxxxxxxx
Subject: Re: [ajdt-dev] Can't determine superclass of missing type (was Weaving into a "read-only" project)

Hi Neale,

I was a little surprised by some behaviours that you were describing, so Andrew and I have been discussing things.

"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)

Although it is sometimes useful that exported jars from the projects upon which you depend are also on your inpath, there are situations - like here - where you just want to weave the classes built as part of compiling base and not inherit the jbcl.jar and jcommon.jar on your inpath, you only need them on your classpath.  (Goes back to what I mentioned earlier: effectively AspectJ would like to have around everything that was used to build some code, in order to perform full analysis).

First option seems to be - don't default to appending exported jars from projects you depend upon to your inpath, just add them to the classpath (it would be an extra option to switch this behaviour).  This would put you in a situation where your base-facade/bin folder would just contain the woven form of 'base' and any 'base-facade' source files.  So this needs an AJDT enhancement to get working - an interim measure it stuffing jbcl/jcommon on the classpath for base-facade and not exporting them from base - but I know that is just a hacky workaround for now.

If we had that option, this seems almost what you want but you would prefer not to export jbcl and jcommon from the base project (and certainly not reference them from base-facade).

Unfortunately, when building base-facade we may have to analyse what is in base - you could see from my previous snippet that AspectJ would want to know more about PaneLayout.  And so AspectJ needs to resolve some types being used from jbcl/jcommon.  Just like you wouldn't imagine running the code in the base project without jbcl/jcommon on the classpath, you can't always weave that code without the dependencies around.  There are really two options here:

- Review your pointcuts to limit the analysis - use within() where possible to exclude any kind of unnecessary investigations.  Look at how interfaces are specified in the signature and type patterns.
- Set the cantFindType message to OFF (it is only an Xlint) - but you would then be taking responsibility that you understand why each of the messages it coming out and you know your type patterns and signature patterns shouldn't match in those scenarios.

> 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
I agree.  The option I discussed in the second paragraph above would address this.

cheers,
Andy.


 

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



________________________________
[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
**********************************************************************

_______________________________________________
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