Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1. Get jboss with facelets and some application that uses facelets. Weave jsf-facelets.jar (does not depend on how you write the aspects). 2. Generate project output as jar 3. Jboss cannot load taglibs from this jar 1a (OK scenario) same as 1 2a Generate output as a dir. Pack it to jar manually from the bin directory. 3a Jboss will load the taglibs More information: I tried to understand what is the difference between manually packed jar and Eclipse plugin packed jar, and they look almost the same to me when unpacked again - just the ordering of entries is different. But maybe I miss something.
probably it is because some attributes have been lost, need to investigate.
I am trying to look into this but know nothing about facelets. How are taglibs recognized in the jar? which classes in there represent taglibs? that will enable me to understand what got lost in weaving.
Actually - ignore that. I made a recent change to AspectJ so that it will include directory entries when specifying an outjar. Previously it did not and removed them from the input. I've learned that some tools rely on the directory entries being there. If you manually packed up the bin folder I think the directory entries would be there, whereas using an older version of AspectJ and -outjar they would be lost. That could be the difference. Are you able to retry with a recent version of AspectJ? I believe it was included in 1.6.2 final release (the bug where i addressed this was 203235).
believed fixed by the repackaging changes made in the previous comment. But please reopen if still a problem. *** This bug has been marked as a duplicate of bug 203235 ***
First, sorry for not responding to your query. I haven't been doing anything with facelets or aspectj since long ago. Although it was 2 years ago, I think the directory entries were present in jars made in both ways - the "ok manual" and "not ok by tooling" versions - at least "jar -tv" showed them, iirc. I think I remember that, if you know that's not possible because that's not the way you implemented it, forget my comment. I don't really know how taglibs work, but it seems to me that the package contains classes and some xml descriptors that bind classes to html-like tags. It might be that what is described in the other bug solves the problem, or it might be that it's yet another resource loading problem. I'll remember to check that when I do anything with taglibs. Anyway, fwiw since this whole thing for me is about debugging, it is not a top prio, it was just one of time consuming problems.
