[06:21:02] *** magesh has joined #weld-dev
[07:09:54] *** magesh1 has joined #weld-dev
[07:12:48] *** magesh has quit IRC
[08:21:54] *** ge0ffrey has joined #weld-dev
[08:39:53] *** maschmid has joined #weld-dev
[08:44:59] *** struberg has joined #weld-dev
[08:47:17] *** mkouba has joined #weld-dev
[09:13:56] *** kevinpollet has joined #weld-dev
[09:22:17] *** kevinpollet has quit IRC
[09:40:01] *** jharting has joined #weld-dev
[09:40:20] *** epbernard has joined #weld-dev
[09:41:07] *** epbernard is now known as emmanuel
[10:30:38] *** oskutka has joined #weld-dev
[10:52:47] *** pmuir has joined #weld-dev
[10:52:50] *** pmuir has quit IRC
[10:52:50] *** pmuir has joined #weld-dev
[11:05:12] *** pchowaniec has joined #weld-dev
[11:16:20] <struberg> pmuir ping re CDI-142
[11:16:21] <jbossbot> jira [CDI-142] Clarify behaviour of specializing beans across bean archive boundaries [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-142
[11:16:42] <struberg> it's indeed not a problem with the BeanManagers
[11:17:18] <struberg> it's solely about that you cannot @Specialize @ApplicationScoped beans in a WAR IF we say that @ApplicationSCoped is 1 per EAR
[11:17:40] <struberg> thus it's depending on how we solve CDI-29
[11:17:41] <jbossbot> jira [CDI-29] Method of accessing contexts regardless of active state [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/CDI-29
[11:17:48] <struberg> oops wrong one
[11:18:09] <struberg> CDI-129
[11:18:10] <jbossbot> jira [CDI-129] Clarify behaviour of @ApplicationScoped in EARs [Open (Unresolved) Clarification, Major, Pete Muir] https://issues.jboss.org/browse/CDI-129
[11:19:29] <pmuir> struberg: in my opinion there is no need to interlink the issues at all
[11:19:42] <pmuir> but we can disagree on that it's fine
[11:19:51] <struberg> heh :)
[11:19:53] <pmuir> I don't really see why we can't solve this generally
[11:20:00] <pmuir> without this consideration
[11:20:04] <struberg> but you see my point in 142?
[11:20:07] <pmuir> it's just an impl detail
[11:20:17] <pmuir> not really, I think you are making a lot of assumptions
[11:20:25] <struberg> oki, I give you an example
[11:20:32] <struberg> EAR with webapp1 and webapp2
[11:20:40] <struberg> EAR contiains @ApplicationScoped MailService
[11:20:59] <struberg> webapp2 contains @Specializes MyOtherMailService extends MailService
[11:21:18] <struberg> now we use @Inject MailService in webapp1 and webapp2, what do they get?
[11:21:46] <struberg> the MailService is in an EAR shared ejb-jars JAR
[11:22:07] <stuartdouglas> This was the reason why I originally created the issue, I thought that the spec should have a line that allows the bean visibility to be promoted in those circumstances
[11:22:12] <struberg> the server has class isolation between webapp1 adn webapp2
[11:22:55] <struberg> yes, stu, I think it doesnt work out witouth either a) removing the classloader isolation -> kawumms a bummer
[11:23:06] <stuartdouglas> struberg: no, it can still work
[11:23:14] <struberg> b) disallowing @Specializes for EAR shared beans in WARs
[11:23:14] <stuartdouglas> MailService must be shared anyway
[11:23:44] <struberg> c) interpret @ApplicationScoped 1 per webapp (as currently in the spec)
[11:23:58] <struberg> the MailService class is shared of course
[11:24:12] <struberg> but the contextual instances are NOT
[11:24:20] <struberg> so no 1 instance per EAR anymore
[11:24:57] <stuartdouglas> I think c) is out
[11:25:13] <struberg> I think C is the only possible way without breaking backward compat with the spec
[11:25:16] <stuartdouglas> but there is also the option of allowing @Specialized beans to be promoted above their visibility
[11:25:21] <struberg> c) is clearly the specced atm
[11:25:32] <stuartdouglas> c) breaks backwards compatibility more than any of the others
[11:25:41] <struberg> only in weld
[11:25:51] <struberg> candi and owb implemented it this way
[11:25:56] <struberg> and weld in standalone as well
[11:26:20] <struberg> so we have 3 impls against 1 ^^
[11:26:24] <struberg> + the spec wording
[11:28:15] <struberg> stu still waiting for solving the riddle of my example ;)
[11:29:12] <stuartdouglas> Just add a line that says that specialised beans can be promoted to the visibility of the bean they are specializing
[11:29:47] <struberg> and what does that mean?
[11:30:04] <struberg> HOW do you promote the visibility if the underlying Class is not shared?
[11:30:59] <struberg> there is NO WAY to to make MyOtherMailService from webapp2/WEB-INF/classes visible to webapp1
[11:31:11] <struberg> at least not for a sane EE server setup
[11:31:23] <struberg> ok, you can go the route of JBossAS4 and drop all isolation
[11:31:45] <struberg> and then again my colleague will do a failure in his webapp staling the whole server including the seam2 based admin gui
[11:31:53] <struberg> thats just *peeep*
[11:32:16] <stuartdouglas> you don't need to, because webapp2 will only refer to the parent class which is shared
[11:32:29] <stuartdouglas> the fact that the actual implementation is not visible should not matter
[11:33:18] <struberg> that would just blow up with NoClassDefFound errors internally
[11:33:23] <stuartdouglas> no
[11:33:37] <struberg> + adding 1 webapp which specializes a bean will change the behaviour of ALL the EAR
[11:33:39] <stuartdouglas> The classes in webapp2 only refer to the shared classes
[11:33:41] <struberg> dont like that
[11:34:05] <stuartdouglas> in that case then it should be disallowed
[11:34:15] <stuartdouglas> which I am also fine with
[11:34:27] <stuartdouglas> I don't really think it is a valid use case anyway
[11:34:39] <struberg> what is the actual argument against c) once again?
[11:34:56] <struberg> that would perfectly solve the problem
[11:35:16] <struberg> introducing an @EarScope where we only allow @Specializes in shared ear jars
[11:36:04] <struberg> but I'm d'accord that it must be disallowed otherwise
[11:36:13] <struberg> making @Specializes in EARs basically useless ...
[11:36:26] <struberg> for @ApplicationScoped beans
[11:38:38] <stuartdouglas> struberg: with your application scoping what happens if there are no wars in the ear, is there no application scope?
[11:39:15] <stuartdouglas> I honestly don't see how you can read the spec to be other that the application scope being shared between all wars
[11:39:43] <struberg> the current spec says this
[11:39:55] <struberg> all non servlet related applications get their own app context
[11:40:01] <struberg> they live in the 'ear' application
[11:40:36] <struberg> > 2.4.1. Built-in scope types
[11:40:36] <struberg> > The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7,
[11:40:36] <struberg> > ?Context management for built-in scopes? represent the standard scopes defined by
[11:40:36] <struberg> > the Java Servlets specification.
[11:40:59] <struberg> and the Java Servlets spec perfectly defines it as not-shared between webapps
[11:41:59] *** emmanuel has quit IRC
[11:49:09] *** alesj has joined #weld-dev
[11:51:59] <pmuir> sorry guys, am in meetings this week so a bit async
[11:52:03] <pmuir> will read this in a min
[11:53:05] <struberg> sure no prob
[11:59:16] *** kevinpollet has joined #weld-dev
[12:14:51] <struberg> funny, deep winter in the alps
[12:15:18] <struberg> colleague just called that he doesn't come to vienna because he got 20 cm of snow on the streets ^^
[12:17:57] *** epbernard has joined #weld-dev
[12:17:57] *** epbernard is now known as emmanuel
[12:20:18] <pmuir> yes, we have a fundamental lack of shared understanding of the way app scope works
[12:20:25] <pmuir> I will write a proposal for this after j1
[12:20:33] <pmuir> weld standalone doesn't support ears
[12:20:35] <pmuir> so that isn't relevant
[12:21:34] <pmuir> but stuart is right about specialization - I think you would end up with different instances in each war - thats the way I see it
[12:21:48] <struberg> yup
[12:22:04] <pmuir> let's write up a full proposal based on stuart's approach
[12:22:08] <pmuir> which is this ;-)
[12:22:13] <pmuir> (I think)
[12:22:18] <pmuir> and then we can comment
[12:22:20] <struberg> but then we are back on having 1 intance per webapp basically
[12:22:28] <pmuir> as right now we don't necessaruly have a full understanding
[12:22:32] <pmuir> only in the specialization case
[12:22:36] <pmuir> which I think is correct
[12:22:45] <struberg> it's also for Interceptors etc
[12:22:49] <struberg> not only @Specializes
[12:23:12] <struberg> @Alternatives
[12:23:14] <struberg> as well
[12:24:13] <struberg> they may only work if they are defined in a BDA which has a visibility which maches the scope which gets used
[12:24:34] <struberg> so all scopes > 1 per webapp need to be careful
[12:24:41] <struberg> pmuir, agree?
[12:25:08] <struberg> we can even generalize that wording probably
[12:26:12] <struberg> matching the allowedness of @Specializes, @Alternatives, of a scope with the class visibility
[12:26:53] *** kevinpollet has quit IRC
[12:27:26] *** magesh1 has quit IRC
[12:31:02] *** magesh has joined #weld-dev
[12:40:24] <struberg> which version of arquillian is the one we should use atm?
[12:40:28] <struberg> (released version)
[12:50:19] <pmuir> right yes
[12:50:27] <pmuir> this is relevant for all types, not just specializes
[12:55:31] <struberg> I just realized that CDI-142 might either be misnamed or we moved to another issue while discussing
[12:55:33] <jbossbot> jira [CDI-142] Clarify behaviour of specializing beans across bean archive boundaries [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-142
[12:55:47] <struberg> "across bean archive boundaries" is actually not a problem
[12:56:06] <struberg> but "accross visibility boundaries" is
[12:58:19] <pmuir> we can generalize that to across bean archive boundaries :-)
[12:58:28] <struberg> nope
[12:58:30] <struberg> imo not
[12:58:41] <pmuir> of course you can
[12:58:44] <struberg> a jar is a bean archive according to the spec
[12:58:59] <struberg> but 2 JARs inside WEB-INF/lib are no problem
[12:59:15] <pmuir> that covers both cases when you have lack of visibility and when you don't
[12:59:20] <struberg> so it has only to do with very special BDAs
[12:59:27] <pmuir> right
[12:59:37] <struberg> we dont have any problems if we have full visibility
[12:59:39] <struberg> imo
[12:59:41] <pmuir> so when you consider across bean archives you need to cover all edge cases
[12:59:52] <pmuir> anyway, this is just semantics
[12:59:57] <pmuir> add a note to the issue :-)
[13:00:11] <struberg> yup, but important to clarify if we like to talk about the same thing ;)
[13:00:14] <struberg> yup will do
[13:00:30] <pmuir> yes
[13:04:10] <struberg> done
[13:04:30] <pmuir> ty
[13:04:35] <struberg> did I ever mention that I hate EAR scenarios? ;)
[13:05:03] <pmuir> we all do ;-)
[13:05:10] <struberg> heh I bet :D
[13:07:31] <struberg> btw, how does weld or AS7 handle @ApplicationScoped beans which are NOT in shared ejb-jars
[13:07:41] <struberg> but only in a shared EAR folder
[13:08:03] <struberg> (without ejb-jar.xml)
[13:08:12] <struberg> imo this must not be shared isn't?
[13:09:03] <pmuir> it just depends on the class visibility IIRC
[13:09:16] <pmuir> but I can't remember tbg
[13:09:18] <pmuir> tbh
[13:09:42] <struberg> I would also need to read the EJB spec again
[13:09:56] <struberg> but I remember that websphere didnt share jars without an ejb-jar.xml
[13:10:05] <struberg> so they got loaded via the webapp classloaders
[13:10:30] <struberg> that would be perfectly fine then
[13:13:02] <pmuir> yeah, in weld we just try to follow class visibility whereever possible
[13:13:16] <pmuir> let me check
[13:17:30] <alesj> pmuir: we did that in AS6, AS7 is a bit more strict on what's visible
[13:18:13] <alesj> but i guess, if jars don't see eachother, bean archives shouldn't either
[13:18:18] <alesj> stuartdouglas: ^
[13:28:29] <pmuir> yes, it should isolate them *I think*
[13:28:30] <struberg> alesj +1
[13:28:32] <pmuir> but we should check this
[13:29:34] <struberg> the problem is that the EE spec still doesn't bindinly define class visibility
[13:29:43] <struberg> but still only has it as 'suggenstion'
[13:29:48] <stuartdouglas> In AS7 bean visibility exactly mirrors module visibility
[13:30:09] <stuartdouglas> so if you have relaxed ear isolation on or not affects what is visible
[13:30:24] <struberg> stu is there a difference between jars found in an ear .lib with and without ejb-jar.xml in as7?
[13:30:47] <struberg> or alesj ^
[13:30:58] <stuartdouglas> ears in lib should not really have an ejb-jar
[13:31:15] <stuartdouglas> or rather jars in a lib
[13:31:16] <struberg> ? thought they need to if they contain EJBs
[13:31:29] <stuartdouglas> you should not have ejb's in the lib dir of an ear
[13:31:37] <stuartdouglas> they should be somewhere else in the ear
[13:31:42] <struberg> where to place them?
[13:31:54] <struberg> definitely not in the WARs I hope ;)
[13:32:16] <stuartdouglas> if you place them in the root the server discovers them, otherwise you can put them anywhere and list them in applciation.xml
[13:32:41] <stuartdouglas> You can have ejb-jar in a war :-)
[13:33:01] <struberg> yes, but they wont get shared then I assume, isn't?
[13:33:01] *** kevinpollet has joined #weld-dev
[13:33:10] <stuartdouglas> no, they won't be shared
[13:33:19] <struberg> kk thanks
[13:33:21] <stuartdouglas> the actual spec requires class-path entries between ejb-jars
[13:33:42] <struberg> in MANIFEST.MF? still for EJB-3.1?
[13:33:42] <jbossbot> jira [EJB-3] Hibernate Annotations 3.0beta1 incompatible with Hibernate 3.0.5 [Closed (Rejected) Bug, Blocker, Unassigned] https://hibernate.onjira.com/browse/EJB-3
[13:33:48] <stuartdouglas> AS7 supports this, but it also allows a relaxed visibility mode
[13:34:07] *** mathieuancelin has joined #weld-dev
[13:34:07] <stuartdouglas> yes, its in the EE6 platrom spec
[13:34:11] <stuartdouglas> not the ejb spec
[13:34:13] <alesj> pre-AS7 it was relaxed, visible by default
[13:34:16] <struberg> kk
[13:34:43] <stuartdouglas> struberg: it does not say that they can't see each other, it just says that portable applications should not rely on them being able to see each other
[13:34:45] <struberg> I just remember that JBoss4 and 5 had no visibility isolation at all ;)
[13:34:47] <alesj> stuartdouglas: do we need some flag now, to make this again visible by default, w/o manifets.mf entries?
[13:36:23] <stuartdouglas> AS7 has a server level setting, and it can also be set on a per server basis
[13:36:49] <pmuir> struberg: mkouba and I are just talking about the CDI TCK - and that we can extract some tests from weld and seam that actually test cdi really
[13:36:52] <stuartdouglas> in the default config the setting is set to relaxed
[13:37:07] <pmuir> struberg: do you have such stuff in owb? if so, would you like us to look at taking some for the tck?
[13:37:12] <struberg> sure we have
[13:37:19] <struberg> in OWB we have about 600 unit tests
[13:37:23] <stuartdouglas> I would like to see more bean archive visibility tests
[13:37:38] <pmuir> mkouba: ^^^ :-)
[13:37:39] <struberg> how far is the test setup using arquillian for the new CDI TCK?
[13:37:42] <pmuir> we were just saying that
[13:37:45] <pmuir> struberg: it's done
[13:37:49] <struberg> fine
[13:37:49] <pmuir> all using arquillian
[13:37:58] <stuartdouglas> awesome
[13:38:12] <struberg> +1
[13:39:44] <pmuir> now that we are on arquillian mkouba can focus on adding the tests we need
[13:40:00] <pmuir> the easiest way to start is to move all the stuff we have scattered into the tck
[13:40:06] <pmuir> and then identify weak spots
[13:40:28] <pmuir> once we have more resources allocated for weld (working on it) we can start on 1.1 tests
[13:44:24] *** kevinpollet_ has joined #weld-dev
[13:45:41] <pmuir> struberg: can mkouba ask you for help finding the tests to look at in owb to add to the tck + ask about how they work etc.
[13:46:26] <struberg> sure
[13:46:30] <mkouba> struberg: just looking for OWB source code...
[13:46:45] <pmuir> great
[13:47:00] <pmuir> ok, mkouba that should give you a good bit of stuff to work on :-)
[13:47:16] <mkouba> struberg: 404 Not Found on download links...
[13:47:23] <struberg> https://svn.apache.org/repos/asf/openwebbeans/trunk
[13:47:31] <mkouba> struberg: great, thanks
[13:47:37] <struberg> svn co with http or https
[13:48:03] <struberg> seems our web servers are down ^^
[13:49:40] *** kevinpollet_ has quit IRC
[13:50:35] <struberg> mkouba our tests are some times a bit archaic
[13:50:51] <struberg> the way we bootstrap our test containers
[13:51:24] <struberg> if you have questions then ping me
[13:51:52] <mkouba> struberg: ok, thanks
[13:53:50] <jbossbot> git [core] push master 8348138.. Marek Schmidt fix arquillian-jbossas-{managed|remote}-6 versions
[13:53:51] <jbossbot> git [core] push master URL: http://github.com/weld/core/compare/fe766b0...8348138
[14:04:52] *** jharting has quit IRC
[14:05:26] <pmuir> struberg: mkouba: even we can't take code we can take problem areas etc.
[14:09:33] *** maschmid has quit IRC
[14:09:43] <struberg> sure
[14:09:55] <struberg> the test code itself is not so benefical
[14:10:06] <struberg> but I guess the test beans we have for them is
[14:10:12] <struberg> the scenarios
[14:12:33] <mkouba> pmuir: struberg: ok, I understand
[14:13:29] *** pmuir has quit IRC
[14:16:27] *** kevinpollet_ has joined #weld-dev
[14:25:28] *** rmartinelli has joined #weld-dev
[15:15:25] *** kevinpollet_ has quit IRC
[15:26:42] *** maschmid has joined #weld-dev
[15:27:21] *** jharting has joined #weld-dev
[15:51:55] *** magesh has quit IRC
[15:54:30] *** rruss has joined #weld-dev
[16:05:40] *** magesh has joined #weld-dev
[16:11:59] *** mbg has joined #weld-dev
[16:18:27] *** oskutka has quit IRC
[16:30:00] *** magesh has left #weld-dev
[16:32:20] *** pmuir has joined #weld-dev
[16:32:20] *** pmuir has quit IRC
[16:32:20] *** pmuir has joined #weld-dev
[16:36:08] *** magesh has joined #weld-dev
[16:39:32] *** magesh has left #weld-dev
[16:40:20] *** pmuir has quit IRC
[17:03:43] *** oskutka has joined #weld-dev
[17:05:08] *** pmuir has joined #weld-dev
[17:05:08] *** pmuir has quit IRC
[17:05:08] *** pmuir has joined #weld-dev
[17:08:16] *** oskutka has quit IRC
[17:08:46] *** pmuir has quit IRC
[17:10:25] *** pchowaniec has left #weld-dev
[17:16:54] *** oskutka has joined #weld-dev
[17:17:18] *** oskutka has quit IRC
[17:23:45] *** mkouba has quit IRC
[17:26:38] *** jharting has quit IRC
[17:27:37] <struberg> folks, where can I report a corrupted jboss repo?
[17:29:57] <struberg> https://repository.jboss.org/nexus/content/groups/public/org/jboss/arquillian/protocol/arquillian-protocol-servlet-3/1.0.0-SNAPSHOT/
[17:29:58] <struberg> is missing the jar
[17:29:58] <struberg> which used to be there...
[17:30:20] <maschmid> struberg: https://issues.jboss.org/browse/JBBUILD
[17:30:31] <maschmid> well, snapshots can disappear
[17:30:35] <maschmid> usually when they are very old and not updated anymore...
[17:33:33] <maschmid> struberg: where does the dependency on that coming from?
[17:34:30] *** sbryzak has joined #weld-dev
[17:34:30] *** sbryzak has joined #weld-dev
[17:35:42] *** sbryzak has quit IRC
[17:35:46] <maschmid> struberg: I think that project has moved, it is probably just   org.jboss.arquillian.protocol:arquillian-protocol-servlet
[17:37:29] <maschmid> it seems it is just one module for all the versions...
[17:41:30] *** kevinpollet has quit IRC
[17:43:41] *** mathieuancelin has left #weld-dev
[17:47:40] *** sbryzak has joined #weld-dev
[17:47:47] *** sbryzak has joined #weld-dev
[17:52:39] <struberg> oki maschmid will check
[17:54:08] <maschmid> struberg: latest snapshot for that would be 1.0.0-Final-SNAPSHOT   (the 1.0.0-SNAPSHOT is an old one)
[17:54:21] <maschmid> *1.0.0.Final-SNAPSHOT
[17:54:30] <maschmid> https://repository.jboss.org/nexus/index.html#nexus-search;quick~arquillian-protocol-servlet
[17:55:02] <struberg> but it seems this comes from within another arquillian dependency
[17:55:08] <struberg> as a transitive dependency ^^
[17:58:52] <maschmid> Arquillian 1.0.0-SNAPSHOTs are obsolete, thery are probably all 1.0.0.Final-SNAPSHOT now
[17:59:09] <struberg> omg
[17:59:21] <struberg> then please move them to an own snapshots repo ;)
[17:59:43] <maschmid> You should not depend on a snapshot anyway... they can do anything :)
[18:00:39] <struberg> is there a release arquillian? ;)
[18:02:00] <maschmid> lots of alphas, betas and CRs... it is safe to depend on any of those...
[18:02:16] <struberg> nah
[18:02:27] <struberg> last time i checked only the snapshot did work
[18:02:47] <struberg> and the release numbers are pretty much confusing tbh
[18:02:58] <maschmid> so try to find the nearest release from the date of the latest working snapshot :)
[18:12:06] *** alesj has quit IRC
[18:17:06] *** cbrock has joined #weld-dev
[18:18:26] *** maschmid has quit IRC
[18:20:42] *** kevinpollet has joined #weld-dev
[18:46:58] *** kevinpollet has quit IRC
[18:47:22] *** alesj has joined #weld-dev
[18:47:56] *** alesj has quit IRC
[18:48:08] *** alesj has joined #weld-dev
[18:54:20] *** kevinpollet has joined #weld-dev
[19:07:58] *** emmanuel has quit IRC
[19:38:17] *** epbernard has joined #weld-dev
[19:38:18] *** epbernard is now known as emmanuel
[20:14:35] *** ge0ffrey has quit IRC
[22:03:42] *** rmartinelli has quit IRC
[22:13:42] *** rruss has quit IRC
[22:17:54] *** alesj has quit IRC
[22:18:25] *** alesj has joined #weld-dev





top