[00:12:48] <arbi> HTTP Status 400 - Request failed, please check the application log or contact the administrator (pmuir at redhat dot com): 'java.lang.NullPointerException, in @'
[00:13:43] <arbi> @RequestParameter seems to be part of the answer (and a getter in the backing bean)
[00:19:53] *** aslak has quit IRC
[00:41:31] *** pj_ has quit IRC
[00:54:37] *** bleathem has quit IRC
[01:02:44] *** mrcl has left #seam-dev
[01:22:54] *** tsurdilo2 has joined #seam-dev
[01:25:28] *** tsurdilo1 has quit IRC
[01:37:32] *** lightguard_jp has quit IRC
[01:50:28] *** bdlink has quit IRC
[01:53:12] *** tsurdilo2 has quit IRC
[03:08:48] *** bdlink has joined #seam-dev
[04:59:45] *** mbg has left #seam-dev
[05:09:23] *** smendenh has quit IRC
[05:35:00] *** clerum has quit IRC
[05:35:34] *** clerum has joined #seam-dev
[05:36:31] *** clerum has quit IRC
[06:32:01] *** lightguard_jp has joined #seam-dev
[08:04:38] *** lightguard_jp is now known as lightguard_jp-zz
[08:09:02] *** jharting has joined #seam-dev
[08:26:25] *** aslak has joined #seam-dev
[08:44:02] *** oskutka has joined #seam-dev
[08:44:17] *** aslak has quit IRC
[08:46:13] *** kpiwko has joined #seam-dev
[08:47:34] *** aslak has joined #seam-dev
[08:51:11] *** shervin_a has joined #seam-dev
[09:06:39] *** adamw1pl has joined #seam-dev
[09:07:49] <adamw1pl> hey, I think there's a mistake in http://docs.jboss.org/arquillian/reference/latest/en-US/html_single/#container.jetty-embedded-7
[09:08:03] <adamw1pl> the group id for jetty-plus should be org.eclipse.jetty
[09:11:30] <aslak> adamw1pl, yea, your right.. doc issue. eager copy and paste i guess
[09:11:40] <aslak> adamw1pl, file a jira please, jira.jboss.org/jira/browse/ARQ
[09:12:29] <adamw1pl> ok
[09:24:31] *** plenyi has joined #seam-dev
[09:43:32] <adamw1pl> any ideas about java.lang.ClassCastException: org.testng.xml.XmlInclude cannot be cast to java.lang.String
[09:43:32] <adamw1pl> 	at org.testng.internal.XmlMethodSelector.setXmlClasses(XmlMethodSelector.java:284)? :)
[09:48:53] <adamw1pl> that's when running from idea .... when running from command line:
[09:48:55] <adamw1pl> java.lang.IllegalStateException: Service org.jboss.arquillian.container.jetty.embedded_7.JettyEmbeddedConfiguration does not implement expected type org.jboss.arquillian.spi.ContainerConfiguration
[09:56:40] *** bdlink_ has joined #seam-dev
[09:57:07] *** bdlink has quit IRC
[10:04:43] *** adamw1pl_ has joined #seam-dev
[10:06:37] *** adamw1pl has quit IRC
[10:06:38] *** adamw1pl_ is now known as adamw1pl
[10:07:06] <adamw1pl> hmm but it does implement this interface ... so sth with classloading :/
[10:09:27] <adamw1pl> any other suggestions for an embedded container where I can deploy a simple servlet? :)
[10:10:31] <aslak> adamw1pl, the testNg stuff is the wrong testng version. use 5.12.1
[10:10:38] <adamw1pl> yeah I am using
[10:10:43] <adamw1pl> guess idea isn't
[10:10:47] <adamw1pl> that's why I tried from command-line
[10:10:52] <adamw1pl> and got the ISE
[10:11:35] <adamw1pl> hum same with jetty 6.1: java.lang.IllegalStateException: Service org.jboss.arquillian.container.jetty.embedded_6_1.JettyEmbeddedConfiguration does not implement expected type org.jboss.arquillian.spi.ContainerConfiguration
[10:11:35] <aslak> adamw1pl, oh right.. hmm you have the whole stacktrace for that?
[10:11:45] <adamw1pl> yeah just a sec
[10:12:11] <adamw1pl> http://pastie.org/1076900
[10:13:29] <aslak> adamw1pl, you building from source?
[10:13:42] <adamw1pl> arq? no, using beta3
[10:13:45] <aslak> ok
[10:14:27] <adamw1pl> I can try snapshot if you have them?
[10:14:37] <aslak> adamw1pl, no
[10:17:52] <adamw1pl> then shuold I try building from source?
[10:17:53] *** thejosh has quit IRC
[10:18:28] <aslak> adamw1pl, i was just thinking you could try something if you had the source etc ready..  but never mind
[10:18:44] <adamw1pl> cloning it now ;)
[10:25:09] <aslak> adamw1pl, seems to be a strange classloader issue.. it isolates the war deployment so that ContainerConfiguraiton and appClassloader ContainerConfiguration is no the same Class, but it's not isolated enough so that the appClassloader ContainerConfiguration SPI config file is not found
[10:25:25] <adamw1pl> classloader issues are the best
[10:25:35] <adamw1pl> argh fetch failed again...
[10:25:55] <adamw1pl> and in jetty there's no jboss-classoading.xml to help you ;)
[10:34:11] <aslak> hmm.. ServiceLoader.load(Class<?> expectedClass) where expectedClass is probably form the appCL, and looking in TCCL for a SPI file which it finds, but when loading the Configuration class from TCCL, it's not the same Class as expectedClass..
[10:35:26] <aslak> the SPI file should only be in appCL..
[10:36:39] <aslak> adamw1pl, please  file a jira on that one..
[10:36:46] <adamw1pl> ok :)
[10:37:02] <adamw1pl> I'm building the source so I can try something out if you'd need
[10:37:10] <aslak> adamw1pl, ok
[10:37:52] <aslak> adamw1pl, it would be to debug the ServiceLoader, see what TCCL is and what it's parents are
[10:38:42] <aslak> looks like appCL is not a parent f TCCL but they share the available resources
[10:38:56] <adamw1pl> TCCL is?
[10:39:10] <aslak> Thread CurrentClassLoader
[10:39:22] <adamw1pl> ah right :)
[10:56:37] *** adamw1pl has quit IRC
[10:57:41] *** adamw1pl has joined #seam-dev
[10:58:42] *** rruss has quit IRC
[10:59:05] <adamw1pl> there it is: https://jira.jboss.org/browse/ARQ-242
[11:00:14] <adamw1pl> any other container you can recommend for a simple servlet testing?
[11:06:11] <adamw1pl> with glassfish v3: SEVERE: PWC1420: Error invoking ServletContainerInitializer com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer
[11:06:11] <adamw1pl> java.lang.NoSuchMethodError: javax.servlet.ServletContext.getServletRegistrations()Ljava/util/Map;
[11:50:05] <adamw1pl> and using the tomcat embedded profile
[11:50:57] <adamw1pl> hmm actually maybe it works ;)
[11:53:24] <adamw1pl> ah no
[11:53:26] <adamw1pl> Caused by: java.lang.IllegalStateException: Error launching test at http://localhost:8080/test/ArquillianServletRunner?outputMode=serializedObject&className=pl.softwaremill.WebDavTest&methodName=shouldBeAbleToCallServlet. Got 400 (Bad Request)
[12:03:16] *** pmuir has joined #seam-dev
[12:04:42] <aslak> adamw1pl, hehe, what servlet api v. do you have to app cl?
[12:05:07] <aslak> adamw1pl, the glassfish issue seem like your getting a 2.5 api in there
[12:06:05] *** adamw1pl has quit IRC
[12:07:18] *** adamw1pl has joined #seam-dev
[12:08:40] *** arbi has quit IRC
[12:45:51] <stuartdouglas> is there a meeting tonight?
[12:56:38] <pmuir> do you have stuff to talk about?
[13:00:37] <stuartdouglas> not really
[13:01:29] <stuartdouglas> I'm just about ready to release alpha 3 for seam-xml but that needs to wait for a weldx release
[13:02:11] <pmuir> ok
[13:02:15] <pmuir> i don't have anything pressing
[13:02:20] <pmuir> i'll send out an email
[13:08:43] *** plenyi has quit IRC
[13:12:46] <adamw1pl> AS6 embedded also doesn't work, throws many CCE and CNFE
[13:13:05] <adamw1pl> and depends on some old shrinkwrap version where the ShrinkWrap.create arguments are in another order
[13:13:17] <adamw1pl> so unfortunately none of the embedded containers work :(
[13:13:41] <aslak> adamw1pl, what is you classpath?
[13:14:16] <adamw1pl> apart from the jboss embedded profile from the manual I have the arquillian-testng artifact
[13:14:37] <adamw1pl> and some of my files
[13:14:52] <adamw1pl> some depending on CDI API
[13:14:54] <adamw1pl> and that's about it
[13:15:04] <adamw1pl> tomcat was nearest to working I guess ;)
[13:16:03] <aslak> adamw1pl, pastebin your pom. and pastebin mvn dependency:tree -P "some profile"
[13:16:34] <adamw1pl> with the jboss profile?
[13:16:46] <adamw1pl> AS6 embedded I mean
[13:18:22] <adamw1pl> and maybe you have an idea what's wrong with the tomcat one? It looked really promising, and was starting up fast
[13:22:28] <aslak> which ever..  tomcat if you like
[13:23:56] <adamw1pl> here's for the jboss one: http://pastebin.com/wqSd5Wa7
[13:23:58] <adamw1pl> impressive ;)
[13:24:56] <adamw1pl> what's weird is that all these containers throw different errors ;)
[13:25:06] <adamw1pl> (glassfish, tomcat, jetty, jboss)
[13:28:37] <adamw1pl> and when using tomcat: (notice the shrinkwrap dep is alpha-11 not alpha-9): http://pastebin.com/NTs9PSAb
[13:31:54] <aslak> adamw1pl, jboss embedded m3 pulls in shrinkwrap alpha9 it seems
[13:33:08] <adamw1pl> yeah ... and with tomcat? why the 400 bad request?
[13:33:12] <adamw1pl> brb, lunch
[13:34:43] <aslak> adamw1pl, probably the context-root your using. try naming your archive test.war
[13:40:12] *** smendenh has joined #seam-dev
[14:09:56] *** adamw1pl has quit IRC
[14:29:42] *** adamw1pl has joined #seam-dev
[14:34:18] *** lightguard_jp-zz has quit IRC
[14:58:06] <adamw1pl> aslak: tomcat embedded seems to work after context-path change :)
[14:58:17] <aslak> adamw1pl, good..
[14:58:28] <aslak> adamw1pl, some hardcoded stuff in there..
[14:58:42] <adamw1pl> heh yeah, no idea why I changed the archive name ;)
[14:59:16] <adamw1pl> another error in the doc is that it says that by default tomcat runs on 9090 :)
[15:04:45] <adamw1pl> even chaning the port in the config worked :)
[15:05:47] <adamw1pl> now I only have to figure out why my app isn't found when opening the URL ;)
[15:10:14] *** lightguard_jp has joined #seam-dev
[15:18:43] <aslak> adamw1pl, not found? it's being undeployed after the test is done
[15:18:58] <adamw1pl> heh no, that's sth wrong with my servlet
[15:19:09] <adamw1pl> arquillian works :)
[15:19:36] <aslak> aa ok
[15:22:49] *** tsurdilo has joined #seam-dev
[15:26:48] *** cwash has joined #seam-dev
[15:34:52] *** balunasj has joined #seam-dev
[15:34:52] *** balunasj has quit IRC
[15:34:52] *** balunasj has joined #seam-dev
[15:41:19] *** rruss has joined #seam-dev
[15:41:19] *** rruss has quit IRC
[15:41:19] *** rruss has joined #seam-dev
[15:42:59] *** clerum has joined #seam-dev
[15:49:20] <adamw1pl> finally works, good time to close the day, thanks a lot for the help aslak :)
[15:50:03] *** jganoff has joined #seam-dev
[15:51:02] <aslak> adamw1pl, good, no prob
[15:56:07] <pmuir> hi everyone
[15:56:12] <pmuir> time for the meeting to start
[15:56:19] <pmuir> we'll give people 5 mins to assemble
[15:56:30] <lightguard_jp> Good moring / evening to all
[15:56:57] <pmuir> afternoon for me ;-)
[15:57:48] <clerum> good morning
[15:58:16] <lightguard_jp> Ah, true.
[15:58:36] <lightguard_jp> Only ~7 hours from me Pete
[15:58:41] <lightguard_jp> I forgot :)
[16:01:15] *** mgencur has joined #seam-dev
[16:02:42] <pmuir> Ok, I actually don't have any topics to discuss today - stuart has made good progress with persistence
[16:03:02] <pmuir> and we are getting the ducks in a row for a release of that (mainly need to document weld extensions)
[16:03:06] <pmuir> btw, good point
[16:03:16] <pmuir> stuart, did you alter seamxml for the new generic beans?
[16:03:44] <stuartdouglas> not yet
[16:04:03] <stuartdouglas> is that all finished in weldx now?
[16:05:14] <pmuir> basically
[16:05:35] <pmuir> i can't support disposer methods yet (bug in Weld I just fixed, so once we get Beta1 out and integrated)
[16:05:45] <pmuir> and validation needs tightening up
[16:06:08] <stuartdouglas> I'll have a look at that this weekend
[16:06:11] <pmuir> great
[16:06:39] <pmuir> anyone else have stuff they want to discuss?
[16:07:09] * lightguard_jp raises hand
[16:07:37] <lightguard_jp> I'll be ready for an Alpha of the exception handling stuff as soon as I get the maven poms in place and some docs
[16:07:50] <lightguard_jp> I also looked at faces-tester from Jason Lee
[16:08:20] <lightguard_jp> Not quite sure if it'll do what we want.  He's basically doing the same thing servlet container does to bootup JSF, but doing it manually.
[16:08:42] <lightguard_jp> I'm thinking all we really need is the renderer which just requires a FacesContext
[16:08:45] <pmuir> would be a start right?
[16:08:51] <lightguard_jp> If I'm wrong some one please tell me.
[16:08:54] <pmuir> yes, that would be ideal
[16:09:09] <pmuir> but requires a redesign of Mojarra or MyFaces :-(
[16:09:15] <lightguard_jp> It could be. But I really don't think we need to go to all the trouble of creating everything.
[16:09:31] <lightguard_jp> Couldn't we just create a FacesContext and invoke the correct phase manually?
[16:10:30] <pmuir> how do we create a FacesContext?
[16:10:44] <pmuir> (btw the exception handling stuff sounds good, looking forward to seeing it)
[16:11:10] <lightguard_jp> That's the part I'm not sure about.  May depend on what the render phase actually needs
[16:11:26] <lightguard_jp> If it doesn't need a request then we may be able to just do some bare minimum stuff
[16:11:42] <lightguard_jp> Just create our own impl of FacesContext with what we need
[16:11:46] <pmuir> ah
[16:11:51] <pmuir> i see, no, I don't think that will work
[16:12:01] <pmuir> we need stuff like all the tag libraries loaded
[16:12:08] <pmuir> the ExternalContext etc.
[16:12:20] <lightguard_jp> Well crap
[16:12:23] <pmuir> I've tried that before
[16:12:27] <lightguard_jp> Ah
[16:12:32] <pmuir> and it's quite a lot of work to get all the bits you need
[16:12:40] <lightguard_jp> blast
[16:13:16] <lightguard_jp> Looks like either facestester or jsf-test would work then.  I guess the question then becomes do we want a mocking library as a dependency.
[16:14:22] <lightguard_jp> The more I dig into it, the better it seams to just use JSF to create the docs if you're already in a JSF environment :(
[16:14:41] *** adamw1pl has quit IRC
[16:15:46] <pmuir> hmm
[16:16:10] <pmuir> ok, so maybe we should plough on with the creating the object model stuff
[16:16:26] <pmuir> as that is clearer
[16:16:29] <pmuir> wdyt?
[16:16:45] <lightguard_jp> I think clerum already has a Velocity based approach working
[16:16:56] <lightguard_jp> Or at least a prototype
[16:17:00] <clerum> right
[16:17:25] <pmuir> ok, clerum where is that code?
[16:17:28] <pmuir> we can do a quick review now
[16:17:46] <clerum> grabbing a link
[16:17:49] <pmuir> (anyone else who wants to talk about other issues, please speak up now, otherwise we'll stay on this topic)
[16:18:04] <clerum> http://github.com/codylerum/seam-mail
[16:18:09] <clerum> it works under velocity
[16:18:29] <clerum> mojavelinux was curious about freemarker as well and I dug into it a bit
[16:18:59] <clerum> but veolcity is definitily easier in how it can chain it's contexts
[16:19:36] *** thejosh has joined #seam-dev
[16:19:37] <clerum> http://github.com/codylerum/seam-mail/blob/master/impl-base/src/main/java/org/jboss/seam/mail/templating/velocity/SeamCDIVelocityContext.java
[16:20:14] <clerum> as far as if we want to be able to grab beans by name from within velocity without having to explicity add them to the context
[16:20:53] <clerum> I haven't been able to loook at this in the last two weeks however...
[16:21:17] <clerum> pmuir: did you get a chance to check with the legal folks about itext
[16:21:25] <pmuir> ah yes
[16:21:40] <pmuir> they advised us to avoid if possible
[16:21:49] <clerum> k
[16:21:56] <clerum> http://pdfbox.apache.org/ looks like it might be a viable option
[16:21:58] <pmuir> the AGPL itself isn't a problem, but they were uncomfortable about the extensions that iText has to it
[16:22:05] <pmuir> ok, do you want to look into that a bit?
[16:22:10] <clerum> I can yes.
[16:22:19] <clerum> itext has been going down an odd path the last couple years
[16:22:54] *** rruss has quit IRC
[16:23:18] <clerum> but it seems like an open source project where there is one dev and he increasingly wants to make money off it....like pulling all the docs and examples off the website. so I would be happy to investigate an alternative
[16:23:46] <lightguard_jp> clerum: With the MailMessage class, wouldn't body(...) make more sense than setHTML setText, etc ?
[16:23:53] *** arbi has joined #seam-dev
[16:24:00] <arbi> Sorry, your request could not be completed. Too many users are currently active on our website. Please try again later.
[16:24:07] <arbi> re: sfwk.org
[16:24:15] <clerum> as in textBody, htmlBody?
[16:24:42] <clerum> there are different mimetypes that have to be set depending on html or text or html if it has inline attachments
[16:24:55] <lightguard_jp> Sure.
[16:25:01] <clerum> or html with text alternatives
[16:25:12] <lightguard_jp> I'm just thinking body makes more sense when you already have subject, from, to, etc
[16:25:49] <clerum> yeah HtmlBody or TextBody
[16:25:54] <clerum> that works
[16:26:38] <lightguard_jp> Then you could do addAlt or addAltBody
[16:26:48] <pmuir> yup
[16:26:49] <lightguard_jp> or just altBody
[16:27:00] <pmuir> ok, i think that looks pretty reasonable
[16:27:47] <clerum> it's still pretty rough and just started getting the api/impl sorted out
[16:27:55] * jganoff raises hand
[16:28:05] <lightguard_jp> Also wondering if the generic is more complicated than it needs to be, or if you even need generics for the interface
[16:28:10] <pmuir> ok, well I think you are going in the right direction
[16:28:34] <pmuir> it's to get around the builder return type
[16:28:36] <clerum> all that was put in place
[16:28:50] <clerum> to get the .to().from().send();
[16:29:03] <pmuir> in general, I think it's better to not have that
[16:29:09] <clerum> :-)
[16:29:13] <pmuir> and redeclare methods on sub interfaces with the correct return type
[16:29:15] <lightguard_jp> Couldn't you just return a MailMessage?
[16:29:21] <pmuir> it's a pita for you as a dev
[16:29:25] <pmuir> but easier for the end user
[16:29:28] <clerum> right
[16:29:38] <clerum> dan was wanting
[16:29:44] <clerum> that style
[16:29:59] <clerum> but it definitly complicates things
[16:30:06] <pmuir> who for?
[16:30:18] <clerum> dev
[16:30:25] <clerum> maybe the user for looking at the api docs as well
[16:30:54] <jganoff> Question about how to implement alternate @Resource injection, to support JMS destination lookup in environments where @Resource isn't implemented
[16:31:02] <clerum> can't just return mailmessage
[16:32:21] <stuartdouglas> I would look for @Resource in ProcessAnnotatedType, and if found add an interceptor binding to the bean
[16:32:35] <pmuir> clerum: why not?
[16:32:47] <stuartdouglas> and in the @PostConstruct method of the interceptor lookup the resources and set the field values
[16:32:55] <jganoff> stuartdouglas: thanks, I needed some direction to get started :)
[16:32:57] <pmuir> right now, it's a horrible to try to declare that
[16:33:23] <pmuir> if you don't care about the subtypes
[16:33:37] <stuartdouglas> or you could wrap the InjectionTarget in ProcessInjectionTarget
[16:33:51] <stuartdouglas> which is probably a better way to do it
[16:34:21] <jganoff> stuartdouglas: is there a way to tell if @Resource wont be able to fulfil the injection?
[16:34:31] <jganoff> stuartdouglas: I don't want to wrap it unless absolutely necessary
[16:34:42] *** jharting has quit IRC
[16:35:00] *** rruss has joined #seam-dev
[16:35:20] <clerum> pmuir: the issue was that some methods are on one interface and some one another and depending on the order of the .to().from().send(); style command you could lose visibility
[16:35:44] <pmuir> clerum: right, you have to override every method on every sub interface to return the correct thing
[16:35:59] <clerum> that was the other option
[16:36:13] <stuartdouglas> I don't think there is a 'proper' way to do it, your going to have to resource to things like examining JNDI and the classpath to discover information about the environment
[16:36:16] <clerum> to duplicate everything..rather than extend the interfaces
[16:36:27] <pmuir> you can still extend it
[16:36:28] *** oskutka has quit IRC
[16:36:32] <lightguard_jp> clerum: Would a runtime exception (SeamMailException) be better, or is it only used internally?
[16:36:35] <pmuir> you just have to override every builder method
[16:37:07] <clerum> right...everything that is on the base level
[16:37:08] <pmuir> jganoff: what do you do if @Resource doesn't work?
[16:37:10] *** mbg has joined #seam-dev
[16:37:14] <clerum> to, from, etc
[16:37:19] <pmuir> yep, that is the "standard" soln to this problem
[16:37:38] <clerum> and I went the complicated route :)
[16:37:38] <jganoff> pmuir: nothing, that's what I'm starting to look at
[16:37:58] <pmuir> yeah, i mean, not how do you handle it at the weld level
[16:38:01] <pmuir> but at the jms level
[16:38:07] <pmuir> how do you find the right thing...
[16:38:38] <pmuir> clerum: also i agree with lightguard_jp SeamMailException should probably be dumped
[16:39:02] <pmuir> I mean, it certainly should be unchecked
[16:39:16] <jganoff> pmuir, I'd need the JNDi connection info to do a remote lookup
[16:39:30] <jganoff> pmuir, not 100% sure how to specify that yet
[16:39:46] <pmuir> and you can use IAE/ISE in all the places I can see
[16:39:59] <pmuir> so i don't think we need it
[16:40:18] <pmuir> jganoff: ok
[16:40:21] *** bdlink_ has quit IRC
[16:40:28] <stuartdouglas> why not have it that it they provide the JNDI info via seam-xml then it performs the @Resource injection target wrapping?
[16:40:46] <stuartdouglas> that way you don't have to try and discover anything
[16:40:47] <clerum> ok
[16:40:53] <pmuir> stuartdouglas: can you write out a quick pastebin example?
[16:40:59] <pmuir> of what it would look like?
[16:41:18] <clerum> rather than throwing it up just make it runtime unchecked
[16:41:34] <stuartdouglas> what info would it need to contain? It would just be a standard bean with @Veto and fields for the JNDI properties
[16:42:16] <lightguard_jp> clerum: Right
[16:42:19] <stuartdouglas> then you would check in ProcessAnnotatedType if it has been installed, if it is enable injection target wrapping for @Resource
[16:42:38] <stuartdouglas> this will need weld 1.1 though
[16:42:46] <pmuir> clerum: also, better to use existing exceptions - that is why the jdk has them...
[16:42:57] <lightguard_jp> clerum: Looking at Attachment.java in impl, not sure the use of the private static methods, why not just do what they're doing in the constructors?
[16:42:59] <jganoff> stuartdouglas: hrm, so a general purpose JNDI resource definition bean?  and just check for its existence
[16:43:11] <pmuir> stuartdouglas: i don't think we treat @Resource as an IT
[16:43:40] <stuartdouglas> I'm taking about wrapping the InjectionTarget of the bean that contains the @Resource
[16:43:52] *** bdlink has joined #seam-dev
[16:44:03] <stuartdouglas> and in the inject method look up the resource manually and set the field value
[16:45:01] <clerum> duplicated code
[16:45:18] <stuartdouglas> jganoff: thats what I want thinking. You wouldn't need this bean in environments where @Resource worked would you?
[16:45:20] <clerum> is why I did it
[16:45:44] <pmuir> stuartdouglas: ok
[16:46:03] <jganoff> stuartdouglas: correct.  However, defining it could change the behavior in an environment when @Resource would normally work for destinations..
[16:46:16] <jganoff> stuartdouglas: If that's desired..
[16:47:30] <stuartdouglas> thats true, I would put a big red warning in the dons saying 'only use this in non EE envirments'
[16:47:48] <jganoff> pmuir, wdyt about that?
[16:48:25] *** arbi has quit IRC
[16:48:37] <lincolnthree> I like that approach. Sane requirement or an override if not necessary.
[16:49:27] <pmuir> I don't quite understand what this will look like for a user... I follow stuarts approach for the impl
[16:49:38] <pmuir> would like to see some example XML/java code for what the user does
[16:51:01] <stuartdouglas> it could be as simple as <jms:HandleResourceProducers/>
[16:51:31] <stuartdouglas> but it would probably need some configuration in there for the jndi properties
[16:51:57] <stuartdouglas> and if the bean is installed seam-jms knows that it has to handle @Resource injection itself
[16:52:05] <pmuir> ah, I was assuming you were proposing a more generic thing
[16:52:11] <pmuir> for all resource producers, not just jms
[16:52:29] <stuartdouglas> no, although that would be good
[16:52:46] <stuartdouglas> but I think that all the resource types would be handled differently
[16:52:53] <pmuir> yes
[16:52:55] <pmuir> I agree
[16:53:00] <stuartdouglas> so they should probably go in their respective modules
[16:53:09] <pmuir> that is what I assumed you were proposing - a generic configuration dialect for that
[16:53:22] <pmuir> well, they don't really have "respective modules"
[16:53:36] <pmuir> there are lots of things you can @Resource that doesn't have a seam module
[16:54:07] <stuartdouglas> we probably do need a generic thing then
[16:54:28] <pmuir> e.g. @Resource(name="foo") String string;
[16:54:33] <stuartdouglas> what about splitting this off into it's own module, that you then only include if you need it?
[16:54:35] <pmuir> yup, I think that would be interesting to explore
[16:54:42] <pmuir> sounds good
[16:54:58] <pmuir> actually
[16:55:03] <pmuir> are we maybe just going overboard here
[16:55:09] <pmuir> will alternatives not deal with this for us
[16:55:13] <pmuir> for the jms case
[16:55:25] <stuartdouglas> how?
[16:55:33] <pmuir> you just declare an alternative with a producer on it that knows how to do when not in an EE env
[16:56:33] <stuartdouglas> that requires opening up the seam-jms.jar and modifying beans.xml
[16:56:43] <pmuir> no it doesn't
[16:56:50] <pmuir> i got another meeting
[16:56:55] <pmuir> gotta dash
[16:57:05] <pmuir> biab - jganoff you around for a while?
[16:57:13] <stuartdouglas> It's 1:00am, so I'm going to bed
[16:57:20] <lincolnthree> gnight stuart
[16:58:37] *** stuartdouglas is now known as stuartdouglas_aw
[17:02:49] <clerum> pmuir: I got a question or two on how we would handle pdf templating when your back
[17:03:03] <clerum> I'll be around for the next 10 hours or so
[17:04:37] *** shervin_a has quit IRC
[17:07:31] *** pmuir_ has joined #seam-dev
[17:07:45] *** pmuir has quit IRC
[17:22:08] *** mgencur has left #seam-dev
[17:36:11] *** arbi has joined #seam-dev
[17:41:30] *** pmuir_ is now known as pmuir
[17:45:29] *** pmuir has quit IRC
[18:03:40] *** jganoff has quit IRC
[18:06:26] *** jganoff has joined #seam-dev
[18:07:21] *** kpiwko has quit IRC
[18:18:17] *** bleathem has joined #seam-dev
[18:36:39] <bleathem> Would someone be able to tell me the IRC channel for Arquillian?
[18:37:05] <lincolnthree> #jbosstesting
[18:37:36] <bleathem> lincolnthree: thanks.  I'm the only one in there :(
[18:37:46] <lincolnthree> not according to my screen
[18:37:48] <lincolnthree> im in there too
[18:37:49] <lincolnthree> i see you
[18:37:50] <bleathem> Thought I might have had the wrong channel
[18:37:50] <lincolnthree> say something
[18:38:21] <lincolnthree> did you see those messages?
[18:39:16] <bleathem> Yeah, my client is messed up.  brb.
[18:39:29] *** bleathem has quit IRC
[18:39:38] *** bleathem has joined #seam-dev
[18:50:23] *** bdlink has quit IRC
[19:05:36] *** pmuir has joined #seam-dev
[19:15:32] *** mbg is now known as mbg|lunch
[19:21:21] <lightguard_jp> pmuir: Is there any mandate or decision about testing seam modules using other langs or tools?
[19:21:44] <pmuir> how do you mean?
[20:08:55] <jganoff> pmuir, let's talk later, busy at work but I got your messages
[20:09:11] <pmuir> which ones
[20:09:20] <jganoff> regarding the jndi configuration
[20:09:58] *** rruss is now known as rruss|away
[20:09:58] <pmuir> ok
[20:12:42] *** tsurdilo has quit IRC
[20:15:47] *** tsurdilo has joined #seam-dev
[20:16:07] *** bdlink has joined #seam-dev
[20:25:16] *** cwash has quit IRC
[20:38:17] *** rruss|away has quit IRC
[20:53:01] <lightguard_jp> pmuir: Sorry, company picnic.  spock specifically, groovy in general
[21:01:48] *** mbg|lunch is now known as mbg
[21:03:20] <pmuir> lightguard_jp: how much of a learning curve does this have?
[21:04:33] <lightguard_jp> Spock doesn't seem too bad, reading about it right now.  It's a Spec driven test idea similar to RSpec if you're familiar with it.  Reads quite a bit like English
[21:04:46] <lightguard_jp> http://code.google.com/p/spock
[21:06:04] *** jganoff has quit IRC
[21:06:24] <pmuir> just bear in mind you won't be the only person working on this stuff
[21:06:42] <pmuir> so i would say avoid deviation unless necessary
[21:07:07] <lightguard_jp> Makes sense
[21:08:37] <pmuir> i.e. its the "what happens when lightguard_jp falls under a bus" argument
[21:08:56] <lincolnthree> :-o
[21:09:01] *** jganoff has joined #seam-dev
[21:09:33] <lightguard_jp> :)
[21:10:05] <pmuir> otoh if you can see it bringing a lot of value then convince us
[21:10:06] <pmuir> :-)
[21:10:35] <lightguard_jp> Probably just stick to arquillian and java, maybe groovy if things start looking ugly
[21:32:39] <bleathem> Can I get Arquiullian to load a war from the classpath (to test the EJB's in it), rather than building the jar with Shrinkwrap?
[21:33:11] <lightguard_jp> bleathem: Wrong window
[21:33:18] <bleathem> oops, sorry
[21:34:45] *** rruss has joined #seam-dev
[21:34:50] *** rruss has quit IRC
[21:34:50] *** rruss has joined #seam-dev
[21:45:31] *** stuartdouglas_aw is now known as stuartdouglas
[22:25:19] <Nik> there is no way of knowing what entity manager a loaded entity comes from, right?
[22:25:35] <Nik> playing around with a s:convertEntity.
[22:26:23] <lightguard_jp> Nik: You could iterate all of them an call contains (I think).
[22:26:32] <lightguard_jp> But to go from entity to em, no
[22:26:36] <lightguard_jp> At least not that I know of
[22:26:43] <Nik> in Seam2 the SMPC entityManager to use was named "entityManager" or conffed in components.xml, what would be the approach in seam3?
[22:27:26] <pmuir> default to @Inject Instance<EntityManager> em;
[22:27:31] <pmuir> instance.get();
[22:27:44] <pmuir> or if the person specifies a qualifier instance.select().get()
[22:28:24] <Nik> or @Inject @SeamManaged Instance<EntityManager>
[22:28:35] <Nik> or what was it called in the persistence module?
[22:28:57] <pmuir> @SeamManaged isn't a qualifier
[22:30:29] <Nik> but keeping it to one entitymanager per converter is probably enough, I think
[22:31:45] <Nik> leaving out orm.xml integration and @version checking for now
[22:31:59] <Nik> no nested conversation simplifies implementation, too(?)
[22:41:10] <pmuir> i don't think so
[22:43:33] <Nik> the Seam 2 ManagerEntityWrapper looks a bit intimidating
[22:50:37] <Nik> do we have a page scope in any module? the seam 2 EntityIdentifierStore appears to have been pagescoped
[23:02:32] *** jganoff has quit IRC
[23:10:14] *** rruss has quit IRC
[23:15:59] *** bleathem has quit IRC
[23:30:57] *** aslak has quit IRC





top