[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [ajdt-dev] Can't determine superclass of missing type
|
Thanks Simone.
That's got things working, but it's broken the read-only condition on 'base'. The requirement to include jbcl on the classpath of base-facade breaks the layered structure of the software, as I don't want base-façade or above to see the libraries that base requires.
I think there's good room to improve this for AJDT1.7
My configuration is now:
base (Java project)
- Java classpath
- itext.jar (not exported)
- jbcl.jar (exported)
- jcommon.jar (exported)
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.
> -----Original Message-----
> From: ajdt-dev-bounces@xxxxxxxxxxx
> [mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Simone Gianni
> Sent: 02 March 2009 13:14
> To: ajdt-dev@xxxxxxxxxxx
> Subject: Re: [ajdt-dev] Can't determine superclass of missing
> type(was Weavinginto a "read-only" project)
>
> Hi Neale,
> this is a common error, but it's not AspectJ fault. Basically, many
> libraries include some classes (a typical case is a Log4J logger or
> something similar), but you haven't Log4J as a dependency, probably
> because you don't use that classes in your project. In your
> case, this
> seems to be an implementation of something related to
> com.borland.jdbl
> library. (In a maven system, this can get quite common, cause
> many jars
> have "optional" dependencies, like Log4J, which are not
> fetched by maven
> by default, causing this kind of warnings over and over).
>
> When AspectJ finds an aspect operating on a type, ajc needs to figure
> out wether a class on the inpath is a subclass of the type
> decalred in
> the aspect or not. Ajc does this check for every class, and
> if it does
> not find the superclass, that error is given.
>
> You should not need to put dependencies on the inpath, unless
> you need
> to weave classes there too, placing them on the classpath should be
> enough. The metaphor is this : "Transform what is placed on
> the inpath,
> using aspects from the aspectpath, and fetching whatever else
> you need
> from the classpath". If a source dir is present, it is
> virtually placed
> both on the inpath (aspects in the aspectpath weave the
> classes in the
> source dirs), on the aspectpath (aspects in the source dirs
> affect stuff
> in the inpath) and on the classpath, obviously.
>
> What error is the weaver giving if you don't put the
> dependency jar on
> the inpath but on the classpath instead?
>
> Simone
>
> Neale Upstone wrote:
> > I'll add another one to this. I've tried adding jbcl.jar
> to the inpath,
> > but then get:
> >
> > can't determine implemented interfaces of missing type
> > com.borland.dx.dataset.AccessListener
> > when weaving type com.borland.jbcl.control.b
> > when weaving classes
> > when weaving
> > when batch building
> BuildConfig[C:\Apps\eclipse\emini-facade] #Files=81
> > AopXmls=#0
> > [Xlint:cantFindType]
> >
> > The problem here is that I don't even have that class
> within the libs
> > for 'base'.
> >
> > 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.
> >
> > Cheers,
> >
> > Neale
> >
> >
> >
> >> -----Original Message-----
> >> From: ajdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:ajdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Neale Upstone
> >> Sent: 02 March 2009 09:07
> >> To: ajdt-dev@xxxxxxxxxxx
> >> Subject: [ajdt-dev] Can't determine superclass of missing
> >> type (was Weavinginto a "read-only" project)
> >>
> >> 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
**********************************************************************
