[01:08:02] <jbossbot> git [mail] push master f81048f.. Dan Allen fix typo
[01:08:02] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/8a4f828...f81048f
[01:08:27] *** bleathem has quit IRC
[01:14:39] *** akazakov has quit IRC
[01:19:09] <jbossbot> git [parent] push master e941f49.. Dan Allen update to Weld 1.1 final
[01:19:09] <jbossbot> git [parent] push master URL: http://github.com/seam/parent/compare/8d6e3b3...e941f49
[01:19:22] <mojavelinux> I'll publish seam-parent 8 tonight
[01:19:26] <mojavelinux> if you need something else in parent, let me know
[01:19:39] <mojavelinux> but publishing parent is pretty simple, so it's not like it's a big deal
[01:19:42] <mojavelinux> gotta run, bbl
[01:27:41] *** cbrock has quit IRC
[01:45:52] *** aslak has quit IRC
[01:57:08] *** jganoff has joined #seam-dev
[02:03:08] *** jganoff has quit IRC
[02:13:41] *** johnament has joined #seam-dev
[02:34:56] <jbossbot> git [forge] push master 8853494.. Lincoln Baxter, III Merge branch 'master' of http://github.com/mikebrock/seam-forge
[02:34:56] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/a1652a0...8853494
[03:09:34] *** lightguard_jp has quit IRC
[03:21:40] *** jganoff has joined #seam-dev
[03:24:31] *** kenfinnigan has joined #seam-dev
[03:25:20] <lincolnthree> BTW: http://ocpsoft.com/prettyfaces/prettyfaces-3-2-0-is-released-url-rewriting-for-servlet-java-ee-and-jsf/
[03:31:16] <kenfinnigan> lincolnthree: not sure how you find the time to work on prettyfaces with all the Seam work you've been doing!
[03:31:38] <kenfinnigan> though I do appreciate it, as it is a great framework that I'm planning to use in my current side project
[03:31:50] <lincolnthree> To be honest
[03:31:56] <lincolnthree> I don't work on it much anymore
[03:32:04] <lincolnthree> the other main dev is doing most of the work
[03:32:07] <lincolnthree> Christian Kaltepoth
[03:32:10] <lincolnthree> awesome guy
[03:32:12] <lincolnthree> chkal on twitter
[03:32:38] <lincolnthree> ive been doing most of my work maintianing and running the builds/CI/deployments
[03:32:42] <lincolnthree> releases
[03:32:42] <lincolnthree> etc
[03:34:22] *** tsurdilo has quit IRC
[03:35:06] <johnament> you sound like a manager now
[03:35:17] <lincolnthree> heh, kinda feel like it
[03:36:00] <jganoff> lincoln is a rock star
[03:36:07] <lincolnthree> negative
[03:36:12] <lincolnthree> just a rock
[03:36:14] <lincolnthree> solid
[03:36:24] <jganoff> Maybe when they light hits you just right?
[03:37:16] <lincolnthree> must be a very bright light
[03:37:21] <lincolnthree> :)
[03:37:22] <jganoff> johnament, how's it going?  Did my emails make sense? ;)
[03:37:29] <jganoff> lincolnthree, hah.  very well then.
[03:37:53] <johnament> jganoff: the way i see it, the original spec is trying to use jMS as a non-EJB way to have asynchronous observer methods
[03:38:24] <jganoff> johnament, pretty much.
[03:38:58] <johnament> jganoff: in the end, if i were the user, i would find this to be an extremely inconvenient side effect; i'd more likely than not only want one or the other.
[03:39:24] <jganoff> johnament, ..and that's why I'd rather just have the interface way of registering routes be a side thing.  We'll implement it because the spec requires us to do so.
[03:39:56] <johnament> as far as the arquillian thing goes, in my case, i'm not injecting anything but the event, and it does get fired, but it doesn't seem to hit the queue receiver fast enough.
[03:40:07] <jganoff> johnament, I much prefer doing something like: @Inject EventBridge bridge;   ... bridge.createRoute(mydestination, myEventType.class).addQualifier(Bridged.class);
[03:40:29] <jganoff> johnament, oh, so it's "working" just slow?... interesting
[03:40:56] <mojavelinux> alright, something to ponder, exciting
[03:40:58] <johnament> jganoff: i think so.  i want to rerun it with a higher timeout to verify, like 60 seconds.
[03:41:17] <jganoff> mojavelinux, howdy :)
[03:41:19] <johnament> jganoff: TBH, i hate the current event routing API (no offense).
[03:41:31] <jganoff> johnament, good feedback! :)  What would you change?
[03:41:54] <jganoff> johnament, and keep in mind the plan is to change it to all hinge on an injectable Event Bridge
[03:42:18] <johnament> jganoff: you mean as far as registering the bridges?
[03:42:25] <jganoff> johnament, registering the routes
[03:42:36] <jganoff> johnament, So, let's go back.  What don't you like about the current api?
[03:42:46] <jganoff> johnament, we still have plenty of time to change it
[03:42:59] <jganoff> johnament, (maybe not plenty of time, but time nonetheless)
[03:43:08] <johnament> jganoff: it's too verbose.
[03:43:32] <jganoff> johnament, we were actually going for verbose
[03:43:46] <mojavelinux> definitely focus on getting it right, not on being rushed
[03:43:51] <mojavelinux> we'll worry about the rushing part :)
[03:44:24] <jganoff> johnament, So you're referring to EventBridge specifically, and then to Route ?
[03:44:35] <johnament> jganoff: yeah pretty much.
[03:44:43] <jganoff> mojavelinux, heh, my commit rate should be an indication of not rushing... ;(
[03:44:46] <johnament> for one, i had to think hard for a while to remember egress vs ingress
[03:45:08] <johnament> obviously e vs i for inbound and outbound mappings
[03:45:10] <jganoff> johnament, ok.  so producer/consumer is better?
[03:45:21] <lincolnthree> jganoff: wow you still lurk here?
[03:45:23] <johnament> jganoff: it maps clearly to the jMS implementations
[03:45:34] <johnament> MessageConsumer/MessageProducer
[03:46:01] <jganoff> johnament, sure.  I was working a lot with JBoss ESB when I drafted up that api
[03:46:04] <johnament> so that behind the scenes you end up knowing ok this @Producer maps toa  message producer
[03:46:14] <jganoff> lincolnthree, I should more often... been busy
[03:46:21] <lincolnthree> jganoff: kidding :)
[03:46:29] <jganoff> lincolnthree, har har! :)
[03:46:56] <jganoff> johnament, ok, good ideas.  Let's try to capture these in JIRA
[03:47:21] <jganoff> johnament, then we have a clear history and something to work off of
[03:48:31] <johnament> the other benefit to using a pure annotation based configuration API is that it should work pretty well with seam-xml and matches the more annotation oriented development that EE5/EE6 were pushing
[03:49:34] <jganoff> johnament, I agree that you should be able to configure it through annotations but the underlying implementation has to be written somewhere.  May as well expose that to the user as well.
[03:50:15] <jganoff> johnament, So with that in mind we should come up with a way to allow you to define one-way routes through annotations (like you mentioned in your email)
[03:50:39] <jganoff> johnament, and since the spec doesn't define how that has to happen we have some liberty to make it as we wish :)
[03:55:28] <jganoff> johnament, Let's resume this over email.  I have a few other things I need to get done before the night is over!
[03:56:17] <johnament> jganoff: so essentially you're saying to have a builder API?
[03:56:30] <jganoff> johnament, right, that's basically what EventBridge is
[03:56:43] <jganoff> johnament, so it's an injectable builder api
[03:56:52] <mojavelinux> congrats to cody for getting arquillian integration tests running in hudson...glad to see some coverage for another module :)
[03:57:21] <johnament> jganoff: we could probably then just extend what you already have, scan for any methods that return a Route object and invoke them on the beans.
[03:58:47] <jganoff> johnament, that's already implemented via @EventRouting albeit a little rough around the edges.  Definitely one of the first places I would start refactoring after EventBridge is changed to allow direct registration (and de-registration) of routes
[03:58:56] *** johnament_ has joined #seam-dev
[03:59:09] <jganoff> johnament, that's already implemented via @EventRouting albeit a little rough around the edges.  Definitely one of the first places I would start refactoring after EventBridge is changed to allow direct registration (and de-registration) of routes
[03:59:31] <johnament_> ok, those two did come through
[03:59:50] <jganoff> johnament, https://github.com/jganoff/jms/blob/master/impl/src/test/java/org/jboss/seam/jms/test/bridge/route/RoutingConfig.java
[04:00:00] <jganoff> johnament, that's an example from the unit tests
[04:00:13] *** johnament has quit IRC
[04:00:13] *** johnament_ is now known as johnament
[04:00:35] <jganoff> johnament, @EventRouting should be removed in favor of having something like EventBridge.addRoute
[04:01:23] <jganoff> johnament, maybe I did a poor job of explaining it but I created SEAMJMS-5 for this
[04:01:24] <jbossbot> jira [SEAMJMS-5] Add/Remote routes programmatically [Open, Major, Unassigned] https://issues.jboss.org/browse/SEAMJMS-5
[04:01:41] <jganoff> hrm, nice typo in the title, should read Add/Remove ;)
[04:01:44] <johnament> jganoff: i looked at that one and said add/remote ?
[04:01:51] <jganoff> doh!
[04:01:59] <jganoff> fixing...
[04:02:24] <jganoff> test: SEAMJMS-5
[04:02:24] <jbossbot> jira [SEAMJMS-5] Add/Remote routes programmatically [Open, Major, Unassigned] https://issues.jboss.org/browse/SEAMJMS-5
[04:02:27] <jganoff> :D
[04:02:33] <jganoff> bot caches!
[04:02:36] <jbossbot> git [international] push master 7c33fc4.. Ken Finnigan Merge commit 'c9aaf021051490288006b4cab6bb886c69755f78'
[04:02:36] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/df2f8e4...7c33fc4
[04:04:13] <johnament> jganoff: i think if we just make event bridging more dynamic, cleanly support EGRESS/INGRESS/BOTH from a registration standpoint, then just provide a number of ways to register against it, we'll have more to work off of
[04:04:32] <jganoff> johnament, exactly, you got it :)
[04:04:49] <johnament> so if you really want, you have programmatic support, but also have annotation driven registration.
[04:05:06] <jganoff> johnament, With that as the core we can expose many ways of registering routes to the user
[04:05:10] *** kenfinnigan has left #seam-dev
[04:05:26] <johnament> git commit hashes are way too long
[04:05:36] <jganoff> well you can usually take the first 6
[04:05:47] <jganoff> like in that compare url
[04:06:02] <jganoff> compare df2f8e4 to 7c33fc4
[04:06:16] <jganoff> it'll fail if those 6 aren't unique though so no ambiguity :)
[04:09:04] <johnament> jganoff: per the spec, shouldn't it support multiple destinations for the same mapping?
[04:09:16] <jganoff> johnament, yep
[04:12:58] <johnament> jganoff: ok, so i think #1 is to get the existing observer extended, and in a CDI enriched message listener to handle the asynch messages to be bound to a receiver/subscriber
[04:15:36] <jganoff> johnament, yea, first thing would be to create an observer method for any interface method defined with @observes and a destination
[04:16:14] <jganoff> johnament, "ingress", or your app consuming jms messages can be implemented with message listeners.  that's the part i don't have a great answer for yet
[04:16:30] <johnament> jganoff: i have an unpublished prototype of that working
[04:17:07] <jganoff> johnament, that's awesome!
[04:17:08] <johnament> jganoff: i would probably say though, we need to make the event route builder have a few more methods
[04:17:40] <jganoff> sure.  I'll try to have that done soon.  I should have some time tomorrow night
[04:38:46] *** johnament has quit IRC
[04:41:21] *** bleathem has joined #seam-dev
[04:46:30] <bleathem> when was jee 5 released?
[04:46:33] <bleathem> 2006?
[04:47:01] <bleathem> Fighting the J2EE FUD !!
[04:47:08] <bleathem> EJB's are not complicated these days
[04:48:47] *** jganoff has quit IRC
[05:13:05] *** lincolnthree has quit IRC
[05:30:00] *** lincolnthree has joined #seam-dev
[05:50:38] *** clerum has quit IRC
[05:51:22] *** lightguard_jp has joined #seam-dev
[05:52:30] <lightguard_jp> Who's still around?
[05:53:03] <stuartdouglas> I am
[05:53:59] <lightguard_jp> stuartdouglas: What's the easiest test case war I can create with Solder to make sure it deploys correctly and stuff basically seems to work?
[05:54:32] <stuartdouglas> for glassfish?
[05:54:38] <lightguard_jp> Yes
[05:55:02] <lightguard_jp> A war with a servlet and Inject some beans from Solder?
[05:55:07] <stuartdouglas> what about running the incontainer tests against GF?
[05:55:11] <lightguard_jp> Maybe make sure a Veto works?
[05:55:19] <stuartdouglas> veto would probably be easiest
[05:55:32] <lightguard_jp> Hm
[05:55:55] <lightguard_jp> Do the resource, el or logging ones make use of things in glassfish?
[05:56:02] <lightguard_jp> If I were to use the in-container tests?
[05:56:26] <lightguard_jp> I've modified Solder to use beans.xml instead of the extensions (you may have seen the pull request)
[05:56:43] <stuartdouglas> I think they do
[05:59:06] <lightguard_jp> Think it'll work with GF 3.0.1 with the 3.1-b37 deployer?
[05:59:22] <lightguard_jp> For incontainer tests
[05:59:32] <stuartdouglas> maybe
[05:59:36] <stuartdouglas> :-)
[05:59:37] <lightguard_jp> k
[05:59:42] <mojavelinux> jason, are the incontainer tests passing?
[05:59:44] <lightguard_jp> I may have to modify the pom to make sure
[05:59:46] <mojavelinux> why don't you just use those
[05:59:47] <stuartdouglas> I am not a GF user
[05:59:56] <lightguard_jp> forgot about the incontainer tests :)
[05:59:58] <mojavelinux> ah
[06:00:07] <mojavelinux> you made the glassfish profile :)
[06:00:08] <mojavelinux> hehehe
[06:00:20] <mojavelinux> and remember, you can run just a single test
[06:00:21] <lightguard_jp> Oh, that's my stuff?
[06:00:29] <lightguard_jp> I don't recall it being merged in
[06:00:35] <mojavelinux> and the nice part about those tests are that they deploy the individual jars in the arquillian archive
[06:00:54] <mojavelinux> of course, you could create a test that just does individual classes
[06:01:06] <lightguard_jp> Running now, see what happens
[06:01:09] <mojavelinux> super
[06:01:13] <lightguard_jp> Bah
[06:01:16] <lightguard_jp> tests skipped
[06:01:18] <mojavelinux> do you have a branch w/ the changes
[06:01:22] <lightguard_jp> Yes
[06:01:23] <mojavelinux> you have to run install
[06:01:30] <mojavelinux> they are executed in the integration-test phase
[06:01:33] <lightguard_jp> I hate maven profiles
[06:01:34] <mojavelinux> or, if you remember that phase name
[06:01:35] <lightguard_jp> grr
[06:01:37] <mojavelinux> you can call it directly
[06:01:44] <lightguard_jp> Thought it was just test
[06:02:08] <mojavelinux> integration-test
[06:02:12] <mojavelinux> I think you can call it verify
[06:02:16] <mojavelinux> there are two test phases
[06:02:17] <mojavelinux> in maven
[06:02:22] <lightguard_jp> 67 passed 18 failed
[06:02:29] <mojavelinux> stuart configured the tests to use the integration-test phase since it comes after the jars are built
[06:02:39] <mojavelinux> try just CoreTest
[06:02:39] <lightguard_jp> Okay
[06:02:39] <stuartdouglas> nope, that was pete
[06:02:45] <mojavelinux> oh, sorry
[06:02:46] <mojavelinux> got it
[06:02:48] <lightguard_jp> That's one of the ones that died
[06:03:01] <stuartdouglas> does anyone know of any situation where ParametisedType.getRawType() will return something other than a Class ?
[06:03:32] <lightguard_jp> Probably have to change the version for the deploy client
[06:03:43] <mojavelinux> I don't think so, I think it's just  matter of whether the class has more information (given it's represented by Type)
[06:03:51] <lightguard_jp> If it's a method ?
[06:03:58] <lightguard_jp> Or a field
[06:04:00] <mojavelinux> so basically, Type means Class with perhaps some extra detail which we'll make you cast to
[06:04:16] <lightguard_jp> Type is a Field, Class or Method
[06:04:18] <mojavelinux> no, you shouldn't have to change any version I don't think
[06:04:22] <mojavelinux> ah, yeah, perhaps
[06:04:24] <lightguard_jp> Maybe one or two others, don't recall.
[06:04:30] <mojavelinux> right, the glassfish version sholud match the server version
[06:05:29] <mojavelinux> i don't think so lightguard_jp (about Type)
[06:05:36] <mojavelinux> the only know subclass of Type is Class
[06:05:39] *** mbg has quit IRC
[06:05:47] <mojavelinux> and it's specialized implementations
[06:05:53] <mojavelinux> Type is the common superinterface for all types in the Java programming language. These include raw types, parameterized types, array types, type variables and primitive types.
[06:06:01] <mojavelinux> it's just a bucket for all the type crap that's in Java
[06:07:20] <lightguard_jp> [#|2011-01-17T22:03:01.567-0700|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=86;_ThreadName=admin-thread-pool-4848(4);|Exception while loading the app|#]
[06:07:27] <lightguard_jp> Those have me a little worried
[06:07:40] <lightguard_jp> Tests are still running according to maven though
[06:07:56] <mojavelinux> so I'm pretty sure the answer to the question is no
[06:08:22] <stuartdouglas> they why did they make it return Type instead of Class ?
[06:08:24] <stuartdouglas> grr
[06:08:40] <mojavelinux> I've utter the very same words at one point, I'm sure of it
[06:08:57] <mojavelinux> ah, lightguard_jp
[06:09:02] <mojavelinux> there is a problem w/ the arquillian adapter
[06:09:09] <mojavelinux> if you see exception while loading the app
[06:09:14] <mojavelinux> that means it failed to deploy
[06:09:24] <mojavelinux> but that adaptor is not pulling the message back to arquillian
[06:09:30] <mojavelinux> the deployment failed at that point
[06:09:38] <lightguard_jp> Caused by: java.lang.RuntimeException: Module startup was interrupted or timed out
[06:09:39] <mojavelinux> you need to take the test archive and manually deploy it to glassfish
[06:09:41] <mojavelinux> using asadmin
[06:09:45] <mojavelinux> to see the error message
[06:09:49] <mojavelinux> yeah, that means nothing
[06:09:54] <lightguard_jp> Bah
[06:10:09] <mojavelinux> I know, it's a pain, that' why we really need a new glassfish-remote adapter
[06:10:17] <lightguard_jp> Okay, how can I get the archive for the Core test or the EL test?
[06:10:20] <mojavelinux> we are stuck between a rock and a hard place
[06:10:34] <mojavelinux> just uncomment the export line in src/test/resources/arquillian.xml
[06:10:36] <mojavelinux> than use
[06:10:50] <mojavelinux> asadmin deploy target/org.****.test.war
[06:10:56] <mojavelinux> and watch the log
[06:11:14] <mojavelinux> or, I think you might be able to stick a debugger in there to trap the error message
[06:11:38] <mojavelinux> you have to weight the time it takes to set it up against how many times you are going to have to do this
[06:12:00] <lightguard_jp> Boo
[06:12:43] <stuartdouglas> actually you can get another ParametisedType using inner classes
[06:12:55] <mojavelinux> oh geez
[06:13:02] <mojavelinux> how did you find that out?
[06:13:15] <stuartdouglas> http://pastebin.com/ppWRxEfz
[06:13:17] <stuartdouglas> this will fail
[06:14:06] <stuartdouglas> hang on, the test is wrong
[06:14:44] <stuartdouglas> nope, I was wrong
[06:15:52] <lightguard_jp> Where do I put my breakpoint?
[06:16:04] <lightguard_jp> After the shrinkwrap return, in the start of the test?
[06:16:59] <mojavelinux> but hang on
[06:17:01] <mojavelinux> let's back up
[06:17:10] <mojavelinux> we don't need to start testing on glassfish right away
[06:17:13] <mojavelinux> restate the problem
[06:17:21] <mojavelinux> we know that using non-bean archives just isn't going to fly
[06:17:42] <mojavelinux> we were walking down that path in the woods, turned out that it isn't a path after all, time to turn back
[06:17:47] <mojavelinux> so we go back to using bean archives
[06:17:56] <mojavelinux> now, in order to do that, we have three tasks
[06:17:58] <lightguard_jp> Does MavenArtifactResolver use snapshots?
[06:18:02] <mojavelinux> 1. add beans.xml to api and impl
[06:18:09] <lightguard_jp> That's done
[06:18:25] <mojavelinux> 2. remove addAnnotatedType calls for the beans
[06:18:29] <lightguard_jp> Done
[06:18:32] <mojavelinux> for the explicit registration of beans
[06:18:38] <mojavelinux> 3. figure out what we need to veto and where
[06:18:55] <mojavelinux> after step 1 and 2, solder will be broken on any app server, including jboss
[06:19:10] <mojavelinux> so, let's work with jboss to figure out what needs to be vetoed...since that's a nice easy arquillian environment to use
[06:19:29] <mojavelinux> once we get that right, then we can throw it at glassfish and it should just work
[06:19:37] <mojavelinux> if it doesn't just work, we can then deal with that specific problem
[06:19:53] <mojavelinux> where are you going to veto beans?
[06:20:09] <mojavelinux> I suppose we can just use @Veto, right?
[06:20:24] <mojavelinux> chances are, there are going to be conflicts we have to resolve
[06:20:27] <mojavelinux> we could also just qualify beans
[06:20:32] <mojavelinux> anything to get them out of the way
[06:20:45] <lightguard_jp> What would we need to veto?
[06:21:05] <mojavelinux> well, look at it this way
[06:21:14] <mojavelinux> using non-bean archives we had about 8 bean classes
[06:21:28] <mojavelinux> now, every class (that's a candidate) is a bean class
[06:21:35] <mojavelinux> so, we might have some head butting
[06:22:20] <stuartdouglas> I can't think of any off the top of my head
[06:22:31] <stuartdouglas> solder was originally a bean archive
[06:22:43] <lightguard_jp> brb
[06:22:49] <mojavelinux> well, the fact is, there are conflicts
[06:23:02] <mojavelinux> which we know
[06:23:08] <mojavelinux> because we've tried this change before and tests failed
[06:23:27] <mojavelinux> not many, but we didn't walk any further...so, that's why I'm saying the first part of #3
[06:23:42] <mojavelinux> is just to run the tests against jboss as remote with changes #1 and #2 and see where we are
[06:23:45] <mojavelinux> so, working on that now ;)
[06:24:20] <mojavelinux> this issue is a PITA...the sooner we tear it off, the better ;)
[06:24:40] <mojavelinux> :'(
[06:25:34] <mojavelinux> Tests run: 83, Failures: 0, Errors: 3, Skipped: 0
[06:27:16] <mojavelinux> actually, it appears I was wrong, it's not conflicts
[06:27:27] <mojavelinux> but its missing beans
[06:27:49] <mojavelinux> either way, we just need to figure them out...we'll get there
[06:28:05] <lightguard_jp> Do you have my pull request?
[06:29:38] <mojavelinux> yep
[06:31:45] <mojavelinux> hmm, so taking the first failure, ElTest
[06:31:51] <mojavelinux> says it can't find Expressions for injection
[06:31:55] <mojavelinux> odd
[06:34:49] <lightguard_jp> Hm
[06:34:52] <lightguard_jp> All of mine passed
[06:34:58] <mojavelinux> interesting, passes on jboss as remote
[06:35:02] <mojavelinux> not on weld embedded
[06:35:13] <lightguard_jp> Yeah, as remote worked for me
[06:37:05] <mojavelinux> so the visibility issue is a problem in weld embedded, perhaps because of how arquillian integrates?
[06:37:32] <mojavelinux> I wonder...since the bean deployment archive is created outside of the weld container
[06:37:35] <mojavelinux> and passed to it
[06:40:03] <mojavelinux> either way, that's an easy bug to reproduce in arquillian
[06:40:07] <mojavelinux> even if it's an arquillian bug :)
[06:40:47] <stuartdouglas> which arquillian container are you using?
[06:41:36] <mojavelinux> Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [ELContext] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject public org.jboss.seam.solder.el.Expressions(ELContext, ExpressionFactory)]
[06:41:36] <mojavelinux> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ELContext] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject public org.jboss.seam.solder.el.Expressions(ELContext, ExpressionFactory)]
[06:41:40] <mojavelinux> the one from weld
[06:41:51] <mojavelinux> so glassfish has a different problem
[06:42:02] <mojavelinux> so, our summary so far of this ElTest, which is one of the problem children :)
[06:42:11] <mojavelinux> 1. works on jboss as :D
[06:42:32] <mojavelinux> 2. fails on weld embedded 1.1.0.Final because of visibility problem across BDA
[06:42:52] <mojavelinux> 3. fails on glassfish remote 3.1-b37 because, I'm tracking it down....
[06:43:18] <stuartdouglas> which arquillian container? se or ee?
[06:44:00] <lightguard_jp> We also have to make sure it runs on glassfish 3.0.1
[06:44:17] <mojavelinux> actually, hold on
[06:44:21] <lightguard_jp> But I imagine when we get it figured out on 3.1-b37 it'll probably be fixed in 3.0.1
[06:44:22] <mojavelinux> #2 might actually be simpler
[06:44:33] <mojavelinux> the deployment is not failing, the injection into the arquillian test is failing
[06:44:45] <mojavelinux> which leads me to believe that it's arquillian that's not seeing things correctly
[06:44:58] <mojavelinux> should change the test to inject Instance<Expressions> so we can inspect more
[06:45:05] <mojavelinux> or use method injection
[06:45:39] <mojavelinux> we are using the arquillian container for weld ee embedded that we've been using in solder for a while now
[06:55:43] <mojavelinux> ah, weld embedded is not processing bean archives added as libraries
[06:55:46] <mojavelinux> in the web archive
[06:56:08] <lightguard_jp> That's the arquillian container problems?
[06:58:28] <mojavelinux> yeah, debugging into that to see what's going on there
[07:00:54] <mojavelinux> ouch, bug
[07:01:01] <mojavelinux> if the library is a FileAsset
[07:01:05] <mojavelinux> then it just skips over it
[07:01:12] <mojavelinux> doesn't look for beans in the jar
[07:01:18] <mojavelinux> assumes it's just a jar of classes
[07:01:23] <mojavelinux> that's an arquillian bug
[07:01:36] <mojavelinux> but, can be fixed in the test just by turning the FileArchive into an AssetArchive
[07:11:45] <lightguard_jp> Is that working at all?
[07:18:24] <mojavelinux> now it's failing because it can't load the class AnnotationInvocationHandler$1
[07:18:24] <mojavelinux> which seems to be a side effect of my importing the JAR as a shrinwrap archive
[07:19:04] *** lincolnthree has quit IRC
[07:19:24] <mojavelinux> looks like a possible bug in shrinkwrap
[07:19:33] <mojavelinux> ahhh
[07:20:32] <mojavelinux> but really this is due to a limitation of the embedded container in arquillian
[07:20:43] <mojavelinux> it should be able to deal with jar files in a web archive that are file references
[07:20:52] <lightguard_jp> Sorry, I've got work problem (yeah, I know) that I have to come up with a solution.  I'd love for it not to be a problem, but knowing the way things typically go, it'll become a problem all because we're too afraid to actually use dependency management *sigh*
[07:24:04] *** oskutka has joined #seam-dev
[07:27:05] <mojavelinux> ah
[07:27:14] <mojavelinux> we seem to be at a real loss here
[07:27:32] <mojavelinux> it's a tragedy that the reference implementation is not giving us any way to move foreard
[07:27:51] <lightguard_jp> For weld 1.0?
[07:27:55] <lightguard_jp> Or the embedded stuff?
[07:28:05] <mojavelinux> I happen to consider this to be an unbelievably critical problem, but the lack of reaction to my post on weld-dev leads me to believe that people just don't think so or care
[07:28:23] <lightguard_jp> :(
[07:28:31] <lightguard_jp> I really hope that's not the case
[07:28:37] <mojavelinux> I'm sure spring is laughing somewhere
[07:34:39] <lightguard_jp> I'm sure the CODI guys are laughing
[07:43:06] <lightguard_jp> mojavelinux: For what it's worth, the wicket example worked on Glassfish 3.1-b36 and b37 with the changes I made in the pull request
[07:43:26] <mojavelinux> using a combined jar?
[07:43:36] <lightguard_jp> Yes
[07:46:17] <mojavelinux> it appears the combined jar is the only way out
[07:46:26] <mojavelinux> there is a circular dependency in solder that we can't break away from
[07:46:37] <mojavelinux> Expressions is in the API but depends on producers in the impl
[07:46:45] <mojavelinux> and this visibility issue of glassfish comes up
[07:46:56] <mojavelinux> during validation, it can't seems to step across archives
[07:47:01] <mojavelinux> what a disaster
[07:47:55] <lightguard_jp> DOH
[07:48:00] <mojavelinux> I seem to be running into a secondary problem that the expressions class doesn't actually work on glassfish
[07:49:16] <lightguard_jp> Deploying the war created in the tests to glassfish the problem is we're bundling up the api, the impl jars and then the same jars in the WEB-INF/classes
[07:49:20] <lightguard_jp> Which also has a beans.xml
[07:49:26] <lightguard_jp> So we have then loaded twice
[07:49:53] <mojavelinux> no, I don't think so, I'm inspecting the war and it looks perfectly correct
[07:50:04] <mojavelinux> the problem is we are breaking a first scientific principal
[07:50:23] <mojavelinux> never try to solve a problem using a bunch of unknowns
[07:50:43] <lightguard_jp> http://pastebin.com/qrZd4aQv
[07:50:47] <lightguard_jp> :)
[07:50:54] <mojavelinux> instead of starting from scratch and building up testing across app servers
[07:50:55] <lightguard_jp> Yeah, we're kind of shooting in the dark
[07:50:59] <mojavelinux> we tested only on jboss as for months
[07:51:04] <mojavelinux> then said, hmm, wonder if glassfish works?
[07:51:09] <mojavelinux> can't do that an expect success
[07:51:22] <lightguard_jp> And we also started tracking weld 1.1
[07:51:26] <lightguard_jp> Which was a bad idea too
[07:51:37] <lightguard_jp> Oh, btw, the wicket module is not portable
[07:51:45] <lightguard_jp> You may have known that though
[07:52:08] <mojavelinux> you must have added another package to the test...because it shouldn't be adding the org.jboss.seam.solder.el package
[07:52:24] <mojavelinux> yeah, the non-portability of wicket is well known
[07:52:29] <mojavelinux> to those working on it
[07:52:32] <mojavelinux> it's a jira
[07:52:39] <lightguard_jp> You're right, I did add it, made the tests pass because those beans weren't being added otherwise
[07:52:54] <lightguard_jp> Shoot
[07:53:36] <lightguard_jp> We need to fix up the tests somehow, and for sure we need get an example working on gf 3.0.1
[07:53:42] * Nik is looking at the JAX-RS 2.0 proposal
[07:53:45] <Nik> "Model-View-Controller (MVC) is a common pattern in Web frameworks, where it is used predominantly by HTML-based applications. Adopting the MVC terminology, JAX-RS resource classes are comparable to controllers. This JSR will specify an MVC architecture compatible with the JAX-RS programing model. Java Server Pages will be specified as one type of view"
[07:53:58] <lightguard_jp> Yeah, I saw that too
[07:54:00] <Nik> that's what we need, more MVC models in EE! ;-)
[07:54:06] <Nik> and JSP support even more important
[07:54:25] <lightguard_jp> I'm curious how they're doing that because specs aren't supposed to compete
[07:54:31] <Nik> JPA 2.1 proposal looked nice, though
[07:54:34] <mojavelinux> it's out of control
[07:54:41] <lightguard_jp> We'll essentially have three competing specs
[07:54:43] <Nik> submitted by Oracle(tm). "We can"
[07:54:48] <lightguard_jp> JAX-RS 2.0, JSP, JSF
[07:54:50] <mojavelinux> the JAX-RS spec is completely going off and doing their own thing at this point
[07:55:12] <mojavelinux> frankly, there needs to be a merge of the Servlet 3 and JAX-RS specs
[07:55:15] <lightguard_jp> JPA 2.1 looks like they're still ignoring flushmode manual
[07:55:21] <mojavelinux> so that we have one decent foundation on which to build
[07:55:29] <mojavelinux> rather that two pretty good ones that have no correlation
[07:55:34] <lightguard_jp> Yeah
[07:55:44] <mojavelinux> so here is where we are with solder at this point
[07:55:46] <lightguard_jp> legos are good, but a common base would be better
[07:55:58] <Nik> two guys from Oracle are spec leads and expert group says "Oracle" :-)
[07:56:01] <mojavelinux> whether beans.xml is in or out, that doesn't get us any closer
[07:56:13] <mojavelinux> the primary issue at this point is that glassFish must used the combined jar
[07:56:15] <lightguard_jp> Nik: Naturally.
[07:56:22] <mojavelinux> because of visibility problems
[07:56:43] <mojavelinux> partially on us for the cyclic dependencies, though legal according to cdi
[07:56:45] <lightguard_jp> Be willing to bet CanDI has similar problems
[07:56:51] <mojavelinux> meaning, we have a more advanced case is all
[07:57:02] *** akazakov has joined #seam-dev
[07:57:06] <mojavelinux> so we mash it together into seam-solder.jar and say that's the one that glassfish uses
[07:57:12] <mojavelinux> now, we have a second probably
[07:57:24] <mojavelinux> wait, backup
[07:57:32] <mojavelinux> so that allows solder to deploy without crashing
[07:57:35] <lightguard_jp> Do we just use the combined jar for everything?
[07:57:37] <mojavelinux> now, functionality
[07:57:48] <mojavelinux> combined jar for everything, what do you mean?
[07:57:52] <mojavelinux> the combined solder jar?
[07:57:54] <lightguard_jp> In all the module poms
[07:57:58] <lightguard_jp> For runtime
[07:58:00] <stuartdouglas> we could just remove the api-impl split
[07:58:01] <mojavelinux> in the examples
[07:58:13] <mojavelinux> sadly, we could
[07:58:35] <stuartdouglas> I don't know how much it  buys with solder, as pretty much all the visible classes form part of the API
[07:58:39] <mojavelinux> but there is a second issue
[07:58:46] <mojavelinux> about 1/4 of the functionality doesn't work in glassfish
[07:58:55] <mojavelinux> jason had the numbers for the tests
[07:59:05] <mojavelinux> for one, the Expressions is broken
[07:59:10] <mojavelinux> I was working on that one
[07:59:11] <lightguard_jp> For 3.0.1?
[07:59:59] <stuartdouglas> hmm, I don't think weld 1.0 fired ProcessAnnotatedType for beans added through the SPI
[08:00:10] <stuartdouglas> and also I think there may have been other SPI issues
[08:00:37] *** bleathem has quit IRC
[08:01:02] <stuartdouglas> I remember ironing out quite a few when I was first working on seam-xml, but I have no idea which version of weld they first went into
[08:01:03] <mojavelinux> 3.0.1 is likely definitely out
[08:01:15] <mojavelinux> at least for the moment
[08:01:25] <mojavelinux> 3.1 looks like a stretch atm
[08:01:35] <mojavelinux> so 3.0.1 isn't even in my sights at this point
[08:02:23] <stuartdouglas> Which GF version are you guys using to test?
[08:02:51] <stuartdouglas> the latest nightly?
[08:03:52] <lightguard_jp> b37
[08:04:05] <lightguard_jp> I think b37 will be the best best
[08:04:09] <stuartdouglas> there is a b38 on the nightly page
[08:04:16] <lightguard_jp> Anything past b37 should work
[08:04:28] <lightguard_jp> b37 had the first bug we found fixed
[08:04:49] <lightguard_jp> Wishing we found this earlier
[08:04:57] <lightguard_jp> We're running up against a lot of clocks
[08:05:12] <stuartdouglas> downloading b38 now
[08:05:34] <mojavelinux> I'm not really sure b38 has anything in it that b37 doesn't, but hey, doesn't hurt if it's available
[08:06:08] <stuartdouglas> not the quickest download...
[08:07:06] <stuartdouglas> I wrote a class file generator over the weekend: https://github.com/stuartwdouglas/classfilewriter
[08:07:56] <mojavelinux> I was just reading that on twitter...sounds like something lincoln might be interested in for forge
[08:08:30] <stuartdouglas> it writes bytecode rather than java, so not sure how relevant it is
[08:08:36] <lightguard_jp> What are we thinking Dan?  Need more examples? Need to get the tests to work?  Which is first?
[08:08:41] <mojavelinux> I know that we really want to get a seam stack beta out this week, but I'm going to play the realistic card and say I Just don't see how
[08:08:54] <mojavelinux> it just isn't going to happen, this problem is big and we are trying to treat it as small
[08:09:03] <mojavelinux> if it turns out to be small, then fine
[08:09:11] <lightguard_jp> I can't release until the solder stuff is figured out
[08:09:18] <lightguard_jp> Which would mean Catch would have to stay at alpha
[08:09:33] <lightguard_jp> Honestly though, it's pretty solid :)
[08:09:36] <mojavelinux> what would be the point of releasing seam at all...so it's not just catch, it's the whole stack
[08:09:41] <lightguard_jp> Alpha in name only :)
[08:09:49] <mojavelinux> right, catch is itself in great shape
[08:10:06] <mojavelinux> but we have a much larger problem with solder because it's going to make it impossible to use anything in seam
[08:10:13] <lightguard_jp> We're shooting for final around March?
[08:10:16] <mojavelinux> if you are on glassfish and maybe resin
[08:10:22] <lightguard_jp> Yeah
[08:10:33] <lightguard_jp> We haven't even tried OWB either
[08:10:38] <mojavelinux> nope
[08:10:49] <lightguard_jp> At least the CODI guys have issues running on Weld too :)
[08:10:55] <mojavelinux> I think we need to go with the highest probability choices at this point
[08:10:59] <lightguard_jp> We're not the only ones apparently.
[08:11:12] <mojavelinux> merge api and impl back together
[08:11:29] <mojavelinux> we don't need beans.xml because we have the fix we need for tht
[08:11:41] <mojavelinux> and according to pete, that was a bonehead problem anyway, so we shouldn't fear it
[08:11:53] <mojavelinux> happening elsewhere
[08:12:11] *** mgencur has joined #seam-dev
[08:12:19] <mojavelinux> and we need to get the tests fixed on glassfish, at least for the important functionality
[08:12:52] <mojavelinux> I'd say EL is important functionality...generic beans stuff perhaps not as critical at this point (for the second solder beta)
[08:12:57] <stuartdouglas> just running them now
[08:13:05] <mojavelinux> great...in the short run
[08:13:21] <mojavelinux> I was able to test the combined jar and impl by using a direct reference to the seam-solder.jar file
[08:13:33] <mojavelinux> the MavenArtifactResolver doesn't allow you to refer to the combined build
[08:14:09] *** akazakov has quit IRC
[08:14:15] <lightguard_jp> I would think using the combined jar in the tests would work on gf
[08:14:17] <mojavelinux> the problem, though, is that you have to build each time...so you may want to first fuse them together....before you get deep into the tests
[08:14:27] <mojavelinux> it works for some tests
[08:14:47] <lightguard_jp> Not everything? :'(
[08:14:58] <mojavelinux> CoreTest is thumbs up
[08:15:10] <lightguard_jp> EL and Logging?
[08:15:41] <mojavelinux> ResourceLoaderTest is thumbs up
[08:16:14] <lightguard_jp> That's good
[08:16:27] <mojavelinux> LoggerInjectionTest is thumbs up
[08:16:29] <lightguard_jp> Broken ones?
[08:17:01] <mojavelinux> UnwrapsTests fails
[08:17:04] <mojavelinux> ElTest fails
[08:17:17] <lightguard_jp> Hrm
[08:17:25] <lightguard_jp> I haven't seen the UnwrapsTest fail yet
[08:17:33] <lightguard_jp> What's going on with those two?
[08:18:06] <mojavelinux> ServiceHandlerTest fails
[08:18:14] <mojavelinux> it depends on what configuration we are talking about
[08:18:38] <mojavelinux> my configuration is no beans.xml, explicit bean registration
[08:18:43] <mojavelinux> combined jar
[08:20:17] <mojavelinux> it's best to run the tests one at a time...because glassfish starts going insane once a test fails
[08:20:29] <mojavelinux> a side effect of the arquillian jsr88 integration
[08:21:01] <lightguard_jp> :(
[08:21:11] <mojavelinux> btw, here's what I have in the Deployments class
[08:21:12] <lightguard_jp> We're not using the deployer they provide?
[08:21:13] <mojavelinux> new File("/home/dallen/.m2/repository/org/jboss/seam/solder/seam-solder/3.0.0-SNAPSHOT/seam-solder-3.0.0-SNAPSHOT.jar"),
[08:21:19] <lightguard_jp> Or it's based on JSR88?
[08:21:43] <mojavelinux> basically, the short answer is that we wrote the glassfish remote container using jsr88 as a quick fix
[08:21:52] <mojavelinux> and it's live past it's shelf life :)
[08:22:04] <mojavelinux> we need a container that uses the REST admin API
[08:22:08] <mojavelinux> because that would be super clean
[08:22:14] <mojavelinux> but it hasn't happened yet
[08:22:37] <lightguard_jp> Yeah, that would be nice
[08:22:43] <mojavelinux> we are hopefully that jason lee is going to take an interest given he understands that API the best and will likely get there a heck of a lot faster ;)
[08:23:05] <mojavelinux> I'll be tracking that container closely of course, because that's my go-to resource for portability validation :)
[08:23:07] <lightguard_jp> He should understand it, he wrote it :)
[08:23:14] <lightguard_jp> Yeah
[08:23:21] <lightguard_jp> Though I'm really liking resin a lot too
[08:23:55] <lightguard_jp> Just don't like that it doesn't offer anything past the web profile
[08:24:07] <lightguard_jp> And the web profile lacks a few really key things
[08:24:16] <lightguard_jp> Like Mail, JAX-RS, JMS, etc
[08:24:31] <lightguard_jp> Boneheaded move by the EG there, IMO
[08:25:14] <stuartdouglas> the solder tests seem to be running really slowly
[08:25:29] <lightguard_jp> Yeah, noticed that too
[08:27:31] <mojavelinux> slowly in generate or against glassfish?
[08:27:51] <mojavelinux> s/generate/general/
[08:28:14] <lightguard_jp> glassfish for me
[08:28:20] <lightguard_jp> Ran pretty quick against jboss
[08:28:22] <lightguard_jp> as
[08:28:35] <stuartdouglas> really slow against GF
[08:29:39] <mojavelinux> yeah, that's because of failures...once glassfish starts to fail
[08:29:46] <mojavelinux> the integration in arquillian basically starts to wait forever
[08:29:56] <mojavelinux> it's not solder
[08:29:59] <mojavelinux> it's jsr88
[08:30:10] <mojavelinux> and the barrier that's in the arq container
[08:30:28] <mojavelinux> basically, jsr88 doesn't report back when the integration is expecting, so it starts waiting forever
[08:30:40] <mojavelinux> which is why you have to execute tests one at a time...otherwise, it just starts to take forever
[08:30:44] <mojavelinux> it's also leaving things deployed
[08:30:59] <mojavelinux> this is the best we've got atm, unforuntately
[08:31:48] <Nik> why did JSR-88 get pruned? OK spec but no-one uses it?
[08:33:03] <mojavelinux> it wasn't finished
[08:33:08] <mojavelinux> then everyone gave up
[08:33:23] <mojavelinux> it wasn't finished in that it didn't handle all deployment cases...major ones that is
[08:33:33] <mojavelinux> like for instance, you can't specify the name of the deployment in a portable way
[08:33:41] <mojavelinux> which is why you can't predict the jndi names
[08:33:53] <mojavelinux> and why you can't test ejbs right now in arquillian on glassfish remote
[08:33:59] <mojavelinux> but that's a story for another day
[08:34:34] <stuartdouglas> you do I up the memory on glassfish?
[08:34:45] <lightguard_jp> How?
[08:34:53] <lightguard_jp> It's in the domain.xml file
[08:35:02] <lightguard_jp> glassfish/domains/domain1/conf/domain.xml
[08:35:02] <stuartdouglas> s/you/how/
[08:35:18] <lightguard_jp> It'll be at the bottom in a bunch of jvm-settings
[08:35:33] <mojavelinux> while I really wanted an api/impl split in solder, I agree that it's just not reasonable at this point, for the record
[08:43:35] <mojavelinux> since i was sounding sort of down earlier, I'm going to part on an up note
[08:44:21] <mojavelinux> what we have here is a case of some breakage...and in the spirit of Holmes on Holmes, no matter what
[08:44:24] <mojavelinux> we are going to make it right
[08:44:29] *** marekn has joined #seam-dev
[08:44:52] <mojavelinux> so, let's just make it right and live with whatever quirks we have to...that's just life at this point
[08:45:12] <mojavelinux> on that note, I need to get to bed for an early morning appt
[08:45:32] <Nik> nite
[08:56:13] *** kpiwko has joined #seam-dev
[09:04:16] <mgencur> sbryzak: ping
[09:23:07] *** epbernard has joined #seam-dev
[09:23:07] *** epbernard is now known as emmanuel
[09:24:38] *** maxandersen has joined #seam-dev
[09:28:56] *** aslak has joined #seam-dev
[09:28:56] *** aslak has quit IRC
[09:28:56] *** aslak has joined #seam-dev
[09:29:22] *** jharting has joined #seam-dev
[09:31:09] *** lightguard_jp has quit IRC
[09:33:01] *** aslak has quit IRC
[09:33:56] *** aslak has joined #seam-dev
[09:33:58] *** aslak has quit IRC
[09:34:28] *** aslak has joined #seam-dev
[09:36:46] *** aslak has quit IRC
[10:06:23] *** akazakov has joined #seam-dev
[10:32:41] *** aslak has joined #seam-dev
[10:45:15] <sbryzak> mgencur: pong
[10:47:51] *** sannegrinovero has joined #seam-dev
[11:04:03] *** shervin_a has quit IRC
[11:14:10] *** shervin_a has joined #seam-dev
[12:15:56] *** pmuir has joined #seam-dev
[12:26:51] *** lukaszlenart has joined #seam-dev
[12:28:46] <lukaszlenart> hi all!
[12:29:00] <lukaszlenart> I have a question regarding seam-faces
[12:29:15] <lukaszlenart> in source I see many listeners
[12:29:16] <lukaszlenart> https://github.com/seam/faces/blob/master/impl/src/main/resources/META-INF/faces-config.xml
[12:29:38] <lukaszlenart> but when I've opened locally seam-faces-snapshot-3
[12:29:52] <lukaszlenart> the faces-confi.xml file is empty
[12:31:39] <lukaszlenart> I'm wondering it has something to do with not working events in JBoss AS 6 Final
[12:32:18] <lukaszlenart> any thoughts ?
[12:53:52] <lukaszlenart> I've added those missing listeners to my local faces-config.xml and events strarted working
[13:03:42] *** kpiwko has quit IRC
[13:04:06] *** kpiwko has joined #seam-dev
[13:29:18] *** sannegrinovero has quit IRC
[14:10:56] *** sannegrinovero has joined #seam-dev
[14:51:05] *** lincolnthree has joined #seam-dev
[14:53:54] *** clerum has joined #seam-dev
[15:02:37] *** mbg has joined #seam-dev
[15:02:39] *** mbg has quit IRC
[15:02:40] *** mbg has joined #seam-dev
[15:04:57] *** igels_ has joined #seam-dev
[15:09:21] *** sannegrinovero has quit IRC
[15:09:21] *** akazakov has quit IRC
[15:12:29] *** jdlee has quit IRC
[15:12:30] *** Nik has quit IRC
[15:12:56] *** lightguard_jp has joined #seam-dev
[15:14:18] *** jdlee has joined #seam-dev
[15:15:19] *** sannegrinovero has joined #seam-dev
[15:23:54] <lightguard_jp> grrr why doesn't the rss feed for seamframework.org seam3 forums work?
[15:24:34] *** lincolnthree has quit IRC
[15:24:34] *** pmuir has quit IRC
[15:24:37] *** mojavelinux has quit IRC
[15:24:37] *** lincolnthree has joined #seam-dev
[15:24:37] *** pmuir has joined #seam-dev
[15:24:38] *** mojavelinux has joined #seam-dev
[15:24:38] *** pmuir has quit IRC
[15:24:38] *** pmuir has joined #seam-dev
[15:38:00] *** tsurdilo has joined #seam-dev
[16:07:56] *** shervin_a has quit IRC
[16:17:45] *** igels_ has quit IRC
[16:18:12] *** akazakov has joined #seam-dev
[16:18:45] *** aslak has quit IRC
[16:26:30] *** oskutka has quit IRC
[16:28:00] *** aslak has joined #seam-dev
[16:28:00] *** aslak has quit IRC
[16:28:00] *** aslak has joined #seam-dev
[16:34:26] *** mojavelinux has quit IRC
[16:36:36] *** lukaszlenart has quit IRC
[16:43:11] *** cbrock has joined #seam-dev
[16:56:00] *** balunasj has joined #seam-dev
[16:56:36] *** balunasj is now known as balunasj_mtg
[17:02:08] *** marekn has quit IRC
[17:20:26] *** jharting has quit IRC
[17:20:41] *** Nik has joined #seam-dev
[17:26:45] *** mgencur has quit IRC
[17:57:40] *** kpiwko has quit IRC
[18:10:53] *** bleathem has joined #seam-dev
[18:16:05] *** balunasj_mtg has quit IRC
[18:26:46] <jose_freitas> lincolnthree, should UIInputContainer (the class which make the p:input tag works) access another component that is outside the context?
[18:27:00] <jose_freitas> morning =)
[18:28:22] <lincolnthree> hi jose_freitas
[18:28:43] <lincolnthree> tbh, i'm not sure, could you describe a little bit?
[18:29:14] <jose_freitas> do you remember how does the tag works?
[18:29:34] <jose_freitas> its main job is to group a label an input and a message
[18:29:54] <jose_freitas> if I use an f:ajax inside the input
[18:30:00] <lincolnthree> there should be an example in the docs
[18:30:04] <lincolnthree> have you taken a look at it?
[18:30:22] <jose_freitas> and this ajax has execute="some_id_outside_input"
[18:30:41] <jose_freitas> should this id be accessed?
[18:31:14] <lincolnthree> http://docs.jboss.org/seam/3/faces/reference/snapshot/en-US/html_single/#UIInputContainer
[18:31:34] <lincolnthree> ah
[18:31:38] <lincolnthree> i believe i know what you are asking
[18:31:50] <jose_freitas> =)
[18:32:11] <jose_freitas> the component is working fine, the problem is when it has to interact with another input
[18:32:31] <jose_freitas> it seems that is not accessing outside the container
[18:33:15] <jose_freitas> it can access main tags like @form, though
[18:33:35] <lincolnthree> http://ocpsoft.com/java/jsf2-java/how-to-jsf-2-0-render-components-outside-of-the-form/
[18:33:41] <lincolnthree> this isn't exactly your situation
[18:33:45] <lincolnthree> but maybe that will help?
[18:35:22] <jose_freitas> I took a look at this article before
[18:35:50] <jose_freitas> yet, the : tip didn't help in this situation
[18:36:11] <lincolnthree> tbh - f:ajax has always seemed fragile to me
[18:36:37] <jose_freitas> indeed
[18:37:35] <jose_freitas> well, I'll keep trying ways of accessing it
[18:37:38] <jose_freitas> thanks
[18:37:41] <lincolnthree> sorry
[18:37:45] <jose_freitas> np
[18:42:04] *** pmuir has quit IRC
[18:47:00] *** maxandersen has quit IRC
[18:52:49] <jose_freitas> yay, it did work with :formid:containerid:componentid
[18:53:00] <lincolnthree> Awesome!
[18:53:35] <jose_freitas> thanks
[18:53:44] <lincolnthree> glad I wasn't completely useless :)
[18:58:11] <jose_freitas> very helpful you were
[19:00:24] <jose_freitas> btw, would like to see another feature implemented in seam-javaee-booking?
[19:00:57] <lincolnthree> I think we'd appreciate that very much
[19:02:40] <jose_freitas> I guess, I couldn't explain myself very well. I meant, beside the features that are already implemented, do you want me to implement another (new) one? I'm implementing for example some handlers from catch now.
[19:13:04] *** pmuir has joined #seam-dev
[19:19:44] <lincolnthree> jose_freitas: ohh you mean are there anyother features we could recommend for you to add?
[19:22:11] <jose_freitas> yes!
[19:23:24] <jose_freitas> I shall kick my english teacher's ass
[19:23:29] <lincolnthree> If mojavelinux were here he'd have lots of good ideas
[19:23:33] <lincolnthree> :-p
[19:23:55] <jose_freitas> just kidding, I don't have a english teacher.
[19:24:21] <jose_freitas> ok
[19:49:32] *** akazakov has quit IRC
[20:07:49] <jbossbot> git [forge] push master 38ee7e5.. Mike Brock class modeling API
[20:07:49] <jbossbot> git [forge] push master bc040d1.. Lincoln Baxter, III Merge branch 'master' of http://github.com/mikebrock/seam-forge
[20:07:49] <jbossbot> git [forge] push master 39fbcda.. Lincoln Baxter, III updated plugin dev chapter
[20:07:49] <jbossbot> git [forge] push master fa5d76e.. Lincoln Baxter, III updated @Option docs for named opts
[20:07:49] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/8853494...fa5d76e
[20:30:46] *** marekn has joined #seam-dev
[20:59:16] *** emmanuel has quit IRC
[21:06:37] *** pmuir has quit IRC
[21:14:53] *** sannegrinovero has quit IRC
[21:36:09] *** cbrock has quit IRC
[21:50:29] *** jdlee has quit IRC
[22:05:17] <aslak> Nik, http://twitter.com/#!/aslakknutsen/status/27470355639566336 :)
[22:06:02] <lightguard_jp> aslak: Awesome
[22:06:12] <lightguard_jp> Are any of those the CDI TCK tests?
[22:06:37] <aslak> lightguard_jp, no
[22:07:40] <aslak> lightguard_jp, there might be equal tests in the tck, but nik ,made a bunch of tests a while ago that has been hanging around in arq with out any use. they all evolve around different deployment types and how cdi inject/lookup ejbs of different types, visability etc
[22:08:33] <lightguard_jp> Cool
[22:25:06] *** kenfinnigan has joined #seam-dev
[22:33:17] *** marekn has left #seam-dev
[22:34:19] *** kenfinnigan has quit IRC
[22:41:16] <Nik> aslak : \o/
[22:50:10] *** balunasj has joined #seam-dev
[22:56:58] *** akazakov has joined #seam-dev
[23:09:15] *** jdlee has joined #seam-dev
[23:09:15] *** jdlee has joined #seam-dev
[23:20:17] *** balunasj has quit IRC
[23:32:25] *** akazakov has quit IRC





top