Time |
S |
Nick |
Message |
00:28 |
|
|
sfisque joined ##javaee |
00:28 |
|
|
manulite joined ##javaee |
00:29 |
|
|
sfisque1 joined ##javaee |
02:34 |
|
|
kobain_ joined ##javaee |
04:59 |
|
|
sfisque joined ##javaee |
07:24 |
|
|
joshua_j_ joined ##javaee |
07:45 |
|
|
SoniEx2 joined ##javaee |
10:45 |
|
|
SoniEx2 joined ##javaee |
11:00 |
|
|
Quest joined ##javaee |
11:00 |
|
Quest |
it seems strange that iam using spring controllers and cannot use HttpSession nor import javax.servlet.http is available |
11:45 |
|
|
SoniEx joined ##javaee |
11:49 |
|
Quest |
nevermind |
13:54 |
|
|
wlfshmn joined ##javaee |
14:22 |
|
|
tjsnell joined ##javaee |
14:22 |
|
|
tjsnell was kicked by ChanServ: User is banned from this channel |
14:27 |
|
|
JavaProf joined ##javaee |
14:45 |
|
|
EnderMoney joined ##javaee |
14:45 |
|
|
Naros joined ##javaee |
14:45 |
|
|
EnderMoney joined ##javaee |
14:54 |
|
|
kobain joined ##javaee |
15:47 |
|
|
connor_goodwolf joined ##javaee |
15:47 |
|
|
connor_goodwolf was kicked by ChanServ: User is banned from this channel |
15:48 |
|
|
dross joined ##javaee |
15:49 |
|
|
sfisque left ##javaee |
15:51 |
|
dross |
interesting ban list. Everyone on the channel ban for ##javaee is a silicon valley player who works from Yahoo! to Gartner. You people must be jealous or mad. |
15:55 |
|
|
thrustcore joined ##javaee |
15:55 |
|
|
thrustcore left ##javaee |
15:56 |
|
|
raulsh joined ##javaee |
16:02 |
|
whartung |
there's a ban list? |
16:02 |
|
dross |
/b |
16:04 |
|
Quest |
dross, are you tjsnell? |
16:04 |
|
Quest |
dross, ask the operators to delete banlisted users if they want |
16:04 |
|
whartung |
/b doesn't do anything for me. |
16:05 |
|
Naros |
I haven't banned anyone (perhaps someone else has). |
16:05 |
|
whartung |
me neither |
16:05 |
|
Quest |
your free to manage the channel as you please |
16:09 |
|
|
topriddy joined ##javaee |
16:09 |
|
raulsh |
/mode <channelname> b |
16:11 |
|
Naros |
there are 4 active bans far as I can tell. |
16:11 |
|
|
whartung left ##javaee |
16:11 |
|
|
whartung joined ##javaee |
16:12 |
|
|
Naros left ##javaee |
16:12 |
|
|
Naros joined ##javaee |
16:14 |
|
* Naros |
goes back to work debugging. |
16:20 |
|
* Naros |
smack ChanServ. |
16:26 |
|
whartung |
with? |
16:26 |
|
|
Guest80863 joined ##javaee |
16:26 |
|
whartung |
WTH? |
16:27 |
|
Sircle |
sorry, bad command. |
16:27 |
|
Naros |
o.O |
16:27 |
|
Sircle |
IRC is not my expertise |
16:34 |
|
|
tjsnell joined ##javaee |
16:35 |
|
Quest |
tjsnell, we have a bit non strict and friendly atmosphere here. |
16:38 |
|
|
moli joined ##javaee |
16:38 |
|
|
moli left ##javaee |
16:45 |
|
|
SoniEx2 joined ##javaee |
16:45 |
|
|
SoniEx2 joined ##javaee |
16:46 |
|
|
dross left ##javaee |
17:50 |
|
|
sfisque joined ##javaee |
18:14 |
|
|
acuzio joined ##javaee |
18:25 |
|
* tjsnell |
eyes acuzio |
18:26 |
|
* acuzio |
eyes tjsnell |
18:26 |
|
Quest |
acuzio, is here to learn. |
18:26 |
|
acuzio |
yes yes from the masters |
18:26 |
|
tjsnell |
he's a trouble maker |
18:26 |
|
acuzio |
ha ., so says tjsnell |
18:27 |
|
acuzio |
Quest: did you know tjsnell was once banned from count them - 3 channels just for swearing |
18:27 |
|
tjsnell |
really!? |
18:27 |
|
tjsnell |
which ones? |
18:27 |
|
acuzio |
well one of them was ##swearing |
18:28 |
|
acuzio |
now imagine getting banned for swearing in ##swearing - how bad would it have to be Quest |
18:28 |
|
Quest |
:) |
18:28 |
|
tjsnell |
I was quite proud |
18:28 |
|
acuzio |
keep an eye on tjsnell Quest he is a troublemaker |
18:28 |
|
acuzio |
a few years ago he was masquerading under a different nick |
18:29 |
|
tjsnell |
we have a reciprocal agreement on bans |
18:29 |
|
tjsnell |
dross! |
18:29 |
|
acuzio |
you do |
18:29 |
|
acuzio |
whats the reciprocal agreement ? |
18:29 |
|
acuzio |
you ban me and i will unban you ? |
18:29 |
|
Quest |
as long as java is in context. and no personal comments are passed. iam fine with everybody. |
18:29 |
|
acuzio |
:-) |
18:29 |
|
tjsnell |
if I'm banned here quest is banned in java :) |
18:29 |
|
Quest |
and mostly the ops do the banning. not me. |
18:29 |
|
acuzio |
clearly - |
18:29 |
|
tjsnell |
mostly? |
18:29 |
|
Quest |
tjsnell, it doesnt matters to me. did you know? |
18:30 |
|
tjsnell |
I didn't care |
18:30 |
|
acuzio |
the rest of the time , chanserv bans tjsnell |
18:30 |
|
acuzio |
they know he is a troublemaker |
18:30 |
|
Quest |
tjsnell, you are unbanned not because I wanted to go to #java . and lets stop the war of #java vs ##javaee |
18:30 |
|
acuzio |
there is a war ? |
18:31 |
|
Quest |
tjsnell, i welcomed you and all because they wanted to talk about java. and javaee. that was the sole reason. |
18:31 |
|
tjsnell |
not since ##java users stopped getting spam invite requests :) |
18:31 |
|
sfisque |
does anyone use java in a non-ee context anymore (besides android) |
18:31 |
|
acuzio |
sfisque: the majority of the usage is in a non-ee context |
18:31 |
|
sfisque |
commercially, i would think that is not the case. i was talking professionally, not hobbiest |
18:31 |
|
Quest |
acuzio, i thought majority was in javaee |
18:31 |
|
* Quest |
agrees with sfisque |
18:32 |
|
acuzio |
sfisque: i am talking commercially and professionally |
18:32 |
|
* acuzio |
agrees with Godzilla |
18:32 |
|
Quest |
i thought android and javaee were dominant |
18:32 |
|
SoniEx2 |
ever heard of minecraft? |
18:32 |
|
acuzio |
^^ |
18:32 |
|
sfisque |
one app |
18:32 |
|
SoniEx2 |
and I think towns also counts... |
18:33 |
|
SoniEx2 |
http://www.townsgame.com/ |
18:33 |
|
tjsnell |
2! |
18:33 |
|
acuzio |
Quest: your thinking is incorrect - JavaEE specifically Servlets, JSP , EJB's have been pretty discredited since around 2005. Most of the core server work in Finance, and in companies like G,FB, Twitter etc is in Java- thats not EE |
18:33 |
|
sfisque |
oh my i can see the tidal wave coming |
18:33 |
|
acuzio |
where |
18:34 |
|
* sfisque |
was being facetious |
18:34 |
|
tjsnell |
his east window |
18:34 |
|
acuzio |
why |
18:34 |
|
acuzio |
isnt that the direction where the sun is supposed to be |
18:35 |
|
sfisque |
how is FB ( a web app) not EE? |
18:35 |
|
tjsnell |
it's in php |
18:35 |
|
tjsnell |
PHPish |
18:35 |
|
acuzio |
a specialised version of PHP |
18:35 |
|
acuzio |
the server work i meant was on their messaging side |
18:35 |
|
sfisque |
so now we've deviated out of my original point |
18:35 |
|
acuzio |
thats not EE |
18:35 |
|
acuzio |
Thats proper Java - |
18:35 |
|
SoniEx2 |
so this is twitter: https://github.com/twitter |
18:35 |
|
sfisque |
and its' not java, either |
18:36 |
|
acuzio |
sfisque: its not ? what is it then ? |
18:36 |
|
SoniEx2 |
java and scala everywhere |
18:36 |
|
sfisque |
acuzio just said it was php |
18:36 |
|
sfisque |
now you're telling me they using java messaging, which is EE |
18:36 |
|
acuzio |
sfisque: the website generation is not the only part of FB - |
18:37 |
|
acuzio |
sfisque: now its not "EE" messaging - |
18:37 |
|
acuzio |
tjsnell: life is too short for this |
18:37 |
|
tjsnell |
:) |
18:37 |
|
sfisque |
what other messaging is there, unless they rolled their own, but i would be surprised at that (easier to find devs if you use standard facilities) |
18:37 |
|
sfisque |
(in java that is) |
18:38 |
|
tjsnell |
amqp |
18:38 |
|
tjsnell |
0mq |
18:38 |
|
tjsnell |
stomp |
18:38 |
|
acuzio |
and yes they did roll their own |
18:40 |
|
acuzio |
tjsnell: do you watch seinfeld ? |
18:40 |
|
tjsnell |
some |
18:40 |
|
acuzio |
tjsnell: Bizarro World |
18:43 |
|
Sircle |
Quest: you are not answering the phone nor on skype. Where are you. call me right away. |
18:44 |
|
Quest |
Sircle, Link problem sir (voip and internet), coming to you in 5. |
18:46 |
|
acuzio |
Can i ask a JavaEE question here ? |
18:48 |
|
acuzio |
hello - anyone here |
18:52 |
|
acuzio |
Can someone answer my question please ? |
18:52 |
|
acuzio |
DOes this mean that if Quest leaves everyone in the channel just shuts up - is that the rule ? |
18:55 |
|
tjsnell |
I never shutup |
18:57 |
|
SoniEx2 |
tjsnell: you also never respect another person's preferences |
18:59 |
|
SoniEx2 |
I like my immutable primitives as "public final" |
19:00 |
|
acuzio |
immutable primitives ? |
19:00 |
|
acuzio |
Whats that sfisque |
19:00 |
|
acuzio |
sorry sfisque i meant SoniEx2 |
19:00 |
|
SoniEx2 |
well any primitive field that I want immutable |
19:01 |
|
acuzio |
sorry do you mind ., giving me an example |
19:01 |
|
SoniEx2 |
https://github.com/SoniEx2/NBX-API/commit/1517348cffad23f01bae20531fa6b6dcdfb93a31 |
19:02 |
|
acuzio |
ah i see |
19:02 |
|
SoniEx2 |
primitive values = byte short int long float double boolean char |
19:02 |
|
acuzio |
If you have it as public final then why do you have getters for them ? |
19:02 |
|
SoniEx2 |
well data types not values |
19:06 |
|
acuzio |
sure |
19:06 |
|
acuzio |
but if you have it as public final then why do you have getters for them ? |
19:09 |
|
SoniEx2 |
... the red lines are removed lines, the green lines are added lines... if you're red-green colorblind... well there are "+"s and "-"s before the lines... |
19:10 |
|
acuzio |
Oh you removed them |
19:10 |
|
acuzio |
i am seeing this on a small screen - so didnt see the width or even the color actually |
19:10 |
|
acuzio |
well done SoniEx2 |
19:10 |
|
acuzio |
so whats the reason for actually using public final |
19:11 |
|
SoniEx2 |
KISS |
19:11 |
|
acuzio |
Aw thats nice but no |
19:12 |
|
SoniEx2 |
aka Keep It Simple, Stupid |
19:12 |
|
acuzio |
oh .... i see |
19:12 |
|
acuzio |
i thought you wanted to give me a kiss |
19:12 |
|
acuzio |
so how does a public final keep it simple, stupid |
19:13 |
|
SoniEx2 |
"public final" instead of 3 lines long methods |
19:14 |
|
acuzio |
but thats not keeping it simple - thats reducing typing |
19:16 |
|
SoniEx2 |
well you use obj.something instead of obj.getSomething() |
19:16 |
|
acuzio |
again typing , isn't it |
19:17 |
|
SoniEx2 |
and the JIT doesn't have to look up the method and stuff |
19:17 |
|
acuzio |
what ? |
19:18 |
|
SoniEx2 |
ask tjsnell |
19:18 |
|
acuzio |
but i thought he didnt agree with public final |
19:21 |
|
SoniEx2 |
yeah he told me to use private fields and getters aka how I was doing it before |
19:22 |
|
acuzio |
yes - but i want to know why you use public final and you said KISS and JIT - but its all typing and JIT i dont understand - public final means JIT doesnt have to look up method and stuff- really ? |
19:22 |
|
SoniEx2 |
do you even know what the JIT is? |
19:22 |
|
acuzio |
i might know |
19:22 |
|
acuzio |
what do you think it is ? |
19:23 |
|
SoniEx2 |
http://en.wikipedia.org/wiki/Just-in-time_compilation |
19:23 |
|
acuzio |
Ok to use your words "JIT doesn't have to look up the method and stuff" - explain that for me please |
19:27 |
|
SoniEx2 |
basically if I use public final fields the JIT doesn't have to look up and process the methods |
19:27 |
|
acuzio |
How do you know that ? |
19:27 |
|
SoniEx2 |
... ¬_¬ |
19:27 |
|
acuzio |
¬_¬ ... |
19:28 |
|
whartung |
when something is marked "final", the JVM can assume it will not change and act upon that assumption |
19:28 |
|
whartung |
such as caching, etc. |
19:28 |
|
acuzio |
but thats not what he said |
19:29 |
|
SoniEx2 |
well there's that too... |
19:30 |
|
acuzio |
yes but has anyone checked what happens when a variable is not marked final and the value of the variable is never changed , what does the compiler do ? |
19:30 |
|
sfisque |
the only effect i can see of final upon the JITC's activities is static pooling. classes that are final will not have any subclasses, so they can be compiled once and stored without having to worry about virtualized calls through from subclasses. final fields can be statically pooled as well because, as has been mentioned, they are analogous to C's "const" |
19:31 |
|
sfisque |
but this all begs the question. why are we considering what the JITC does, because we have very little control over it |
19:31 |
|
sfisque |
the JITC is platform and implementation specific and offers no "promises" outside of it's scope |
19:32 |
|
acuzio |
sfisque: "as has been mentioned" - where has that been mentioned |
19:32 |
|
sfisque |
whartung indicated it |
19:32 |
|
acuzio |
really - he did - i dont see where he said C and where he said const |
19:33 |
|
sfisque |
final int x; // this variable, once assigned will/can NEVER change during the lifetime of the enclosing object |
19:33 |
|
acuzio |
but that was not the question - i am trying to see why public final is better than standard private final and getter |
19:33 |
|
sfisque |
unless it's inside of a method. then it changes semantics |
19:33 |
|
sfisque |
it isnt |
19:34 |
|
acuzio |
well SoniEx2 indicated it was |
19:34 |
|
tjsnell |
what!? I never respect someones preferences |
19:34 |
|
tjsnell |
you base that on your one use case? |
19:34 |
|
sfisque |
public final allows undesirable side effects in your inheritence chane |
19:34 |
|
acuzio |
in fact he has been arguing that it is better - |
19:34 |
|
tjsnell |
easy on the personal attacks here please |
19:34 |
|
acuzio |
tjsnell: you stink |
19:34 |
|
tjsnell |
weekly shower tonight |
19:34 |
|
|
kobain joined ##javaee |
19:34 |
|
acuzio |
that might explain it |
19:35 |
|
sfisque |
public int x; // a subclass can change that value without any gating in the super class. |
19:35 |
|
tjsnell |
two fishing trips on this one, it all adds up |
19:35 |
|
sfisque |
public void setX() // a subclass can only change the value thorugh the semantics allowed by the superclass |
19:35 |
|
sfisque |
assuming X is private |
19:35 |
|
acuzio |
and dont tell me you have also been actually catching fish tjsnell |
19:35 |
|
sfisque |
if x is protected, all bets are still off |
19:36 |
|
acuzio |
what if x is in danger , are all bets still off |
19:36 |
|
sfisque |
basically if the variable is purely a value and does not represent some form of "state through transition", then exposing it as public is not much of an issue, but still qualifies as a "code smell". |
19:37 |
|
acuzio |
code smell is tjsnell's smell i take it |
19:37 |
|
* sfisque |
sighs |
19:37 |
|
sfisque |
never mind :-/ |
19:38 |
|
tjsnell |
~sfique++ |
19:38 |
|
acuzio |
~tjsnell-- for the stink |
19:38 |
|
acuzio |
tjsnell: once a trouble maker always a troublemaker |
19:41 |
|
SoniEx2 |
... not sure if troll or a 10 y/o who codes... |
19:44 |
|
SoniEx2 |
sfisque: you... do something... |
19:46 |
|
SoniEx2 |
btw, reflection doesn't care about final fields: http://i.imgur.com/KuxomZd.png |
19:47 |
|
sfisque |
it does. notice the method is "altering" the accessibility of the field. if you alter the accessibility, you're basically telling java you "want to break the rules" |
19:48 |
|
sfisque |
any properly secured jvm will balk at that method and hit the catch block with a security violation exception |
19:51 |
|
SoniEx2 |
well idk what the minecraft launcher really does but I don't think it uses a security manager... |
19:52 |
|
SoniEx2 |
and about the first statement... well that's why it's a hack... |
19:52 |
|
tjsnell |
haha |
19:53 |
|
tjsnell |
I should've known |
19:56 |
|
SoniEx2 |
(btw by "statement" I meant what you said) |
20:35 |
|
|
tjsnell joined ##javaee |
20:39 |
|
|
joshua_jandyco joined ##javaee |
20:42 |
|
|
tjsnell joined ##javaee |
21:11 |
|
|
Quest joined ##javaee |
21:18 |
|
|
Naros joined ##javaee |
22:57 |
|
sfisque |
conceptual design question for my fellow EE folks. i have a process that is driven by a cluster of SLSBs and CDI beans. i'm moving part of the workflow to an Asynch method which does not have a CDI injection context (hence the CDI beans will NPE on me). as such i'll have to redesign part of the workflow but i'm trying to figure out how do do this without a massive regression footprint (several of the supporting SLSBs inject t |
22:58 |
|
sfisque |
anyone encounter a similar problem and have a good "pattern" that worked well for them? |
23:01 |
|
whartung |
why does an async method not have a CDI context? |
23:02 |
|
sfisque |
why? i do not know. but it does not (at least as of EE6 on GF 3.1.2.2). whether that changed with EE7 or GF4, i do not know, but i would hope it has. |
23:03 |
|
whartung |
that just seems really weird to me. |
23:03 |
|
sfisque |
i'm guessing, it's because CDI has "context" and asynch threads are coming from the worker pool and have no "context" (aka, they fire whenever and have no "session" construct) |
23:04 |
|
whartung |
I mean, why can't it create the instance f the bean when you invole the async mehtod, and then actually call the method later. Don't see why it would be any different from a SLSB in that regard, but what do I know -- I have not used CDI |
23:04 |
|
sfisque |
no, the issue is SLSBa calls method in SLSBb. SLSBb has an injected instance of CDIa, which fails to inject because SLSBa method is now @Asynch |
23:05 |
|
sfisque |
remember, SLSB's have no true "this". this points to the entire pool and so you cannot "hold" onto instances the way a SFSB or CDI bean can |
23:13 |
|
sfisque |
i mean, i could explicitly set all the SLSBs taht inject the CDI bean, but the issue becomes blurry with injections that are several levels deep ( SLSBa -> SLSBb -> SLSBc -> SLSBd , where b, c, and d each inject one or more CDI beans.) hence why i'm spending time just "daydreaming" various patterns to make this cleaner |
23:18 |
|
whartung |
oic |
23:19 |
|
whartung |
wow. |
23:19 |
|
whartung |
still no excuse for the context to be "gone" when the async invoked. I dunno. |
23:19 |
|
sfisque |
yah. lets just say the "product" is a mish-mash of technologies that i "inherited" |
23:19 |
|
whartung |
yea |
23:21 |
|
sfisque |
i might have to end up building some "parallel" objects that mimic the CDI beans, but are either SL/SFSBs or similarly discoverable via JNDI |
23:21 |
|
whartung |
why would an MDB have context to invike an SLDB and a Async bean call not |
23:21 |
|
whartung |
this is … disappointing |
23:22 |
|
sfisque |
injecting ejbs works fine. it's CDI beans that fail |
23:23 |
|
whartung |
gah! |
23:23 |
|
whartung |
That's a "why is't that the same thing now anyway" rant. |
23:24 |
|
sfisque |
i'm still guessing it's because the worker pool is disconnected from the web container in such a way that there is zero concept of a "session", which is what CDI beans (at least the app/sess/conversation - scoped ones) are tied to |
23:25 |
|
whartung |
yea |
23:25 |
|
whartung |
ok |
23:25 |
|
whartung |
I can see it for "some" of the scopes |
23:25 |
|
whartung |
but for a local scope it should work |
23:25 |
|
whartung |
but for session, yea, no bueno |
23:26 |
|
sfisque |
ejb scope (local/remote) is very different from CDI context scope (request/conversation/session/application) |
23:26 |
|
sfisque |
one is ejb-container based, the other is web-container based |
23:26 |
|
sfisque |
or "servlet container" i should say |
23:26 |
|
whartung |
yea |
23:28 |
|
sfisque |
this is one of "those things" that has cemented my career as "the solution guy". except this one is quite a dinger and it's going to take some brain time to come up with "the elegant solution" |
23:29 |
|
whartung |
well, arguably, "why are you using session pertinent objects in an async method anyway" |
23:29 |
|
whartung |
it's kind of a dark side of the session model |
23:32 |
|
sfisque |
i know. trust me. the issue is, we're doing background processing of an uploaded file, and some of the slicing/dicing requires information that comes from "who uploaded it" |
23:32 |
|
whartung |
can't you pass that in as an argument to the method? Post injection? |
23:33 |
|
sfisque |
and in the spirit of "reuse" rather than writing all sort of redundant methods, we're using existing code. |
23:33 |
|
sfisque |
aye W, but again, the issue arises with deep call chains |
23:33 |
|
whartung |
si |
23:33 |
|
whartung |
but it's a curious downside to CDI |
23:33 |
|
sfisque |
whatever these beans do, it has to work in an injectable context as well as asynch |
23:34 |
|
sfisque |
well, CDI beans really have not business in EJB.s different tiers. CDI beans are the replacement for JSF MBs |
23:34 |
|
whartung |
it's one of those "yea, they're just pojos" but, "Umm, yea, but they're really not…" |
23:34 |
|
sfisque |
yub |
23:36 |
|
sfisque |
i might split the CDI bean into several parts. the parts i need can be moved to SFSBs and injected back into the CDI bean as well as my Asynch call chain. the problem is, i'll have to manage the session'ing because SFSBs don't have a "session" context like CDI beans do since they're not servlet aware. |
23:37 |
|
whartung |
yea, youll have to come up with a derivative session instance and pass it around |
23:37 |
|
whartung |
or.. |
23:37 |
|
whartung |
can you play with the CDI context within a SLSB? |
23:37 |
|
whartung |
I mean, I know you can call the infrastrcture to perform injection on random objects. |
23:37 |
|
whartung |
can you tie int to that at the SLSB tier and do it "manually"? |
23:38 |
|
sfisque |
sort of. i can have it "in hand" before i dive into the Asynch method, and maybe plug it into a ThreadLocal or JDNI |
23:38 |
|
sfisque |
***JNDI |
23:39 |
|
sfisque |
i'll have to daydream some…. i like this part, but its hard to explain to "the boss" that you're designing, which amounts to lots of sitting back and thinking without producing code |
23:39 |
|
whartung |
just desing in a textfile in the ide -- whats' the difference :) |
23:40 |
|
sfisque |
doesnt work like that for me. i have to get that 1000 yard stare and actually "visually" conceptualize in my head (like the objects become tangible things and i see their connections and how they interact in "space/time (process/container/etc.)) |
23:41 |
|
sfisque |
sort of like 3d UML in my head |
23:41 |
|
whartung |
well, stare and type make ticky noises on the keyboard |
23:42 |
|
sfisque |
lolz |
23:42 |
|
sfisque |
anywho, on that note, i'm off to "la la land" to design. code strong! |
23:42 |
|
whartung |
kk take care |
23:42 |
|
whartung |
drive safe |