October 18, 2011  
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

[00:00:38] <stuartdouglas> alesj: it cannot be proxied
[00:00:44] <stuartdouglas> it may be final, or have a final field
[00:00:49] <stuartdouglas> or no default ctor
[00:00:59] <stuartdouglas> or no non-private default ctor
[00:01:06] <stuartdouglas> or public fields
[00:01:22] <alesj> @Decorator
[00:01:22] <alesj> @ApplicationScoped
[00:01:22] <alesj> public abstract class FifoBlobService implements BlobService
[00:01:22] <alesj> {
[00:01:22] <alesj>    private static final int DEFAULT_SIZE = 2;
[00:01:23] <alesj>    private BlobService delegate;
[00:01:23] <alesj>    private int size;
[00:01:24] <alesj>    private Map<String, byte[]> fifo;
[00:01:25] <alesj>    public FifoBlobService()
[00:01:25] <alesj>    {
[00:01:26] <alesj>       this(DEFAULT_SIZE);
[00:01:26] <alesj>    }
[00:01:27] <alesj>    protected FifoBlobService(int size)
[00:01:28] <alesj> this is how it looks like ...
[00:01:40] <alesj> can the problem be protected ctor?
[00:02:15] <alesj> stuartdouglas: ^
[00:03:53] <stuartdouglas> that looks like it should be proxiable
[00:04:07] <stuartdouglas> protected constructor should be fine
[00:05:02] <stuartdouglas> alesj: I did not think decorators could be app scoped?
[00:05:11] <stuartdouglas> I thought they has to be depdennt
[00:05:15] <alesj> stuartdouglas: yeah, thought about that ...
[00:05:40] <alesj> so it means i will get a new instance for every injection / decoration?
[00:05:43] <alesj> stuartdouglas: ^
[00:08:44] <stuartdouglas> yes
[00:09:36] <alesj> hmmm
[00:09:46] <alesj> injectionPoint.getType == Object
[00:09:51] <alesj> that looks strange ...
[00:10:09] <alesj>          if (getServices().get(MetaAnnotationStore.class).getScopeModel(resolvedBean.getScope()).isNormal() && !Proxies.isTypeProxyable(injectionPoint.getType()))
[00:10:09] <alesj>          {
[00:10:09] <alesj>             throw new UnproxyableResolutionException(UNPROXYABLE_RESOLUTION, resolvedBean, injectionPoint);
[00:12:11] <alesj> org.jboss.weld.injection.EmptyInjectionPoint@2b91ef5b
[00:16:55] <alesj> stuartdouglas: ^
[00:17:15] <alesj> imo, we shouldn't get EIP
[00:17:53] <stuartdouglas> Object should be proxiable
[00:17:56] <stuartdouglas> that is kinda odd
[00:18:14] <stuartdouglas> I'm actually not sure exactly what is going on there
[00:18:28] <alesj> i think we just don't see the bug if decorator isNormal scoped
[00:18:42] <alesj> i mean, if it's dependant
[00:18:53] <stuartdouglas> I am pretty sure that the decorator has to be dependent
[00:19:02] <alesj> why?
[00:19:48] <stuartdouglas> "A decorator instance is a dependent object of the object it decorates."
[00:19:54] <stuartdouglas> in the decorators intro
[00:21:05] <alesj> uf ?
[00:22:08] <stuartdouglas> so this is a bug, in that we probably should have thrown a deployment exception, can you file a CDI spec issue, as they spec does not say what should happen with a non-dependent decorator
[00:24:45] <alesj> ok, i have a few more back in the office
[00:24:51] <alesj> can you just ping me tomorrow
[00:25:01] <alesj> so i put the whole list down
[00:25:09] <alesj> before I forget or loose the list
[00:25:10] <alesj> :-)
[00:50:34] *** pmuir has quit IRC
[01:44:09] *** alesj has quit IRC
[01:50:28] *** rruss has quit IRC
[01:53:58] *** kevinpollet has quit IRC
[02:57:23] *** conan has quit IRC
[03:01:14] *** conan has joined #weld-dev
[04:29:03] *** rruss has joined #weld-dev
[04:29:19] *** rruss has quit IRC
[05:12:37] *** magesh has joined #weld-dev
[06:35:28] *** |conan| has joined #weld-dev
[06:38:18] *** conan has quit IRC
[06:38:18] *** |conan| is now known as conan
[08:43:50] *** mkouba has joined #weld-dev
[08:56:07] *** ge0ffrey has joined #weld-dev
[09:11:55] *** maschmid has joined #weld-dev
[09:31:38] *** OndrejZizka1 has joined #weld-dev
[09:32:35] *** OndrejZizka has quit IRC
[09:37:45] *** oskutka has joined #weld-dev
[09:49:01] *** jharting has joined #weld-dev
[09:57:15] *** OndrejZizka1 has quit IRC
[09:57:37] *** OndrejZizka has joined #weld-dev
[10:00:10] *** OndrejZizka1 has joined #weld-dev
[10:02:18] *** OndrejZizka has quit IRC
[10:02:50] *** oskutka has quit IRC
[10:03:57] *** oskutka has joined #weld-dev
[10:06:49] *** mkouba has quit IRC
[10:27:14] *** mkouba has joined #weld-dev
[10:40:53] *** alesj has joined #weld-dev
[11:20:09] *** struberg has joined #weld-dev
[12:12:51] *** oskutka has quit IRC
[12:15:24] *** oskutka has joined #weld-dev
[13:09:33] *** alesj has quit IRC
[13:33:36] *** oskutka has quit IRC
[13:39:27] *** oskutka has joined #weld-dev
[13:40:51] *** struberg has quit IRC
[13:47:04] *** oskutka has quit IRC
[13:51:28] *** struberg has joined #weld-dev
[14:03:46] *** oskutka has joined #weld-dev
[14:29:21] *** alesj has joined #weld-dev
[14:32:19] *** oskutka has quit IRC
[15:14:58] *** mbg has quit IRC
[15:36:18] *** alesj has quit IRC
[16:01:18] *** alesj has joined #weld-dev
[16:03:38] *** magesh has left #weld-dev
[16:06:35] *** mbg has joined #weld-dev
[16:11:54] *** mbg has quit IRC
[16:24:48] *** mbg has joined #weld-dev
[16:24:49] *** mbg has quit IRC
[16:24:49] *** mbg has joined #weld-dev
[17:09:52] *** mkouba has quit IRC
[17:19:04] *** alesj has quit IRC
[17:51:38] *** kevinpollet has joined #weld-dev
[18:17:57] *** rruss has joined #weld-dev
[18:18:30] *** oskutka has joined #weld-dev
[18:18:31] *** oskutka has quit IRC
[18:26:37] *** maschmid has quit IRC
[18:36:12] *** jharting has quit IRC
[19:34:09] *** pmuir has joined #weld-dev
[19:34:09] *** pmuir has quit IRC
[19:34:09] *** pmuir has joined #weld-dev
[19:34:10] *** alesj has joined #weld-dev
[19:34:50] *** kevinpollet has quit IRC
[20:15:13] *** oskutka has joined #weld-dev
[20:26:49] *** ge0ffrey has quit IRC
[20:32:05] *** rruss has quit IRC
[20:49:02] *** conan has quit IRC
[21:03:24] *** kevinpollet has joined #weld-dev
[21:15:21] *** rruss has joined #weld-dev
[21:40:41] *** rruss has quit IRC
[22:22:58] *** lincolnthree has joined #weld-dev
[22:23:04] <lincolnthree> hey alesj, around?
[22:23:26] <alesj> lincolnthree: hey
[22:23:32] <lincolnthree> hey! you're up, cool
[22:23:35] <lincolnthree> question for you
[22:23:56] <alesj> no, you're doing it wrong
[22:24:02] <alesj> just answered in advance :-)
[22:24:19] <alesj> http://googleappengine.blogspot.com/2011/10/app-engine-155-sdk-release.html
[22:24:25] <alesj> eh
[22:24:41] <alesj> ok, seriously now ? go ahead lincolnthree
[22:24:45] <lincolnthree> http://pastebin.com/MFHYFMxi
[22:24:46] <lincolnthree> lol
[22:25:00] <lincolnthree> so
[22:25:09] <lincolnthree> basically what's happening here is that I have weld. 1.1.2.Final
[22:25:14] <lincolnthree> weld requires log4j
[22:25:30] <lincolnthree> i think i know what to do here, but...
[22:25:43] <lincolnthree> i have a plugin that also depends on log4j for some reason
[22:25:49] <lincolnthree> when i start forge with that plugin installed, it complains
[22:25:53] <lincolnthree> still boots, but complains
[22:26:25] <alesj> which is weird, as you probably never share Logger instances
[22:26:31] <alesj> or where is the mismatch
[22:26:34] <lincolnthree> yes
[22:26:47] <lincolnthree> Weld is just complaining as it boots
[22:26:50] <lincolnthree> i have no idea why
[22:26:56] <lincolnthree> both log4j jars are on the classpath though
[22:27:06] <lincolnthree> are visible to the classloader that weld is booting in
[22:27:59] <struberg> different log4j versions?
[22:27:59] <lincolnthree> one comes from its own module
[22:28:04] <lincolnthree> the other comes from a sub-module
[22:28:06] <lincolnthree> yes
[22:28:11] <lincolnthree> 1.2.12 and 1.2.14
[22:28:26] <alesj> ok, that explains it
[22:28:37] <alesj> i just don't see who shares Configuration instance / class
[22:28:59] <lincolnthree> they shouldn't... but assuming they do. what would you recommend to resolve this?
[22:29:04] <lincolnthree> i can't change the versions
[22:29:16] <alesj> why not?
[22:29:18] <struberg> drop 1.2.12
[22:29:22] <alesj> yes
[22:29:28] <alesj> select single version
[22:29:33] <alesj> it's micro version change
[22:29:38] <struberg> 1.2.14 should be compatible
[22:29:41] <alesj> hence it *should* be compatible
[22:29:44] <struberg> heh
[22:29:52] <alesj> ? although, with Ceki I would never be sure ;-)
[22:29:58] <alesj> e.g. see SFL4j
[22:30:32] <lincolnthree> i can't modify this person's code
[22:30:34] <struberg> http://mojo.codehaus.org/clirr-maven-plugin/
[22:30:35] <lincolnthree> it's not my code :)
[22:30:46] <lincolnthree> it's a plugin
[22:30:49] <lincolnthree> forge needs to tolerate that
[22:30:52] <struberg> nice way to check binary compatibility
[22:31:11] <struberg> then you need to create a classloader hierarchy
[22:31:21] <struberg> btw, that was one reason why maven was created
[22:31:25] <lincolnthree> the issue is that it's trying to use a class that was loaded from a different classloader
[22:31:27] <struberg> because with ANT we had similar problems
[22:32:22] *** mbg has quit IRC
[22:32:43] *** jbott has quit IRC
[22:46:27] *** mbg has joined #weld-dev
[22:46:31] *** mbg has joined #weld-dev
[22:59:21] *** oskutka has quit IRC
[23:00:01] *** oskutka has joined #weld-dev
[23:00:03] *** oskutka has quit IRC
[23:04:22] *** pmuir has quit IRC
[23:16:09] *** mbg has quit IRC

top