| Time |
S |
Nick |
Message |
| 01:02 |
|
|
[[thufir]] joined ##javaee |
| 03:58 |
|
|
[[thufir]] joined ##javaee |
| 05:55 |
|
|
tangatools joined ##javaee |
| 05:55 |
|
|
tangatools joined ##javaee |
| 06:58 |
|
|
AlexCzar joined ##javaee |
| 08:49 |
|
|
AlexCzar joined ##javaee |
| 10:52 |
|
|
MegaMatt joined ##javaee |
| 10:58 |
|
|
cheater_3 joined ##javaee |
| 11:06 |
|
AlexCzar |
I can't figure out how to use @MatrixVariables in spring 3.2. I'm using WebMvcConfigurationSupport for configuration, @RequestMapping is just like in the docs: value="/{location}". URL is "/location;lat=41.1;lon=42.2". Spring throws Bad Request (400) error |
| 11:09 |
|
pdurbin |
AlexCzar: what part of the docs are you looking at? |
| 11:11 |
|
AlexCzar |
pdurbin, http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-matrix-variables |
| 11:16 |
|
|
sfisque1 joined ##javaee |
| 11:37 |
|
cheater_3 |
hi. i am trying to migrate an app from jboss 4.2.3 to 6.1.0.Final. it works under 4.2.3. Under 6.1.0.Final I am getting the following issue, i was told it was likely related to java ee. during startup, deployment is broken off with the following error found in server.log: Deployment "vfs:///usr/local/jboss-6.1.0.Final/server/default/deploy/patent.ear" is in error due to the following reason(s): java.lang.IllegalArgumentException: Can't |
| 11:37 |
|
cheater_3 |
my application.xml is very simple and it's found at http://paste.debian.net/61183/ |
| 11:38 |
|
cheater_3 |
i would appreciate any hints on how to resolve this. |
| 11:39 |
|
pdurbin |
cheater_3: your first line was cut off: http://irclog.greptilian.com/javaee/2013-10-24 |
| 11:40 |
|
cheater_3 |
the whole error message: Deployment "vfs:///usr/local/jboss-6.1.0.Final/server/default/deploy/patent.ear" is in error due to the following reason(s): java.lang.IllegalArgumentException: Can't find a deployment unit named .jar at AbstractVFSDeploymentContext 1942861904{vfs:///usr/local/jboss-6.1.0.Final/server/default/deploy/patent.ear} |
| 11:40 |
|
cheater_3 |
that came through complete |
| 11:48 |
|
cheater_3 |
pdurbin: what are your thoughts? |
| 12:22 |
|
pdurbin |
cheater_3: "named .jar"? shouldn't it be foo.jar or something? just .jar? |
| 12:25 |
|
pdurbin |
cheater_3: also, when you /join #wildfly you'll see: "This is the right place to ask about the Wildfly Application Server and the older JBoss Application Server projects." |
| 12:27 |
|
pdurbin |
AlexCzar: anything useful in your logs? |
| 12:27 |
|
AlexCzar |
pdurbin, nope nothing gets logged |
| 12:28 |
|
pdurbin |
AlexCzar: can you turn the logging up to DEBUG or whatever? |
| 12:29 |
|
AlexCzar |
pdurbin, it's set to INFO |
| 12:29 |
|
pdurbin |
AlexCzar: try FINE or higher. DEBUG |
| 12:30 |
|
AlexCzar |
pdurbin, ok, wait a moment |
| 12:31 |
|
pdurbin |
the matrix thing is interesting: http://www.w3.org/DesignIssues/MatrixURIs.html |
| 12:43 |
|
AlexCzar |
pdurbin, the message from log: Missing matrix variable 'lat' for method parameter type [double] |
| 12:44 |
|
AlexCzar |
here is the gist for the code: https://gist.github.com/AlexCzar/e0ba8f82c4317733e210 |
| 12:59 |
|
pdurbin |
AlexCzar: I see "double lat" but where is the value of that variable set? |
| 12:59 |
|
AlexCzar |
pdurbin, From the matrix variable |
| 12:59 |
|
AlexCzar |
check the gist |
| 13:11 |
|
|
sl33k joined ##javaee |
| 13:13 |
|
|
tommmied joined ##javaee |
| 13:23 |
|
|
Naros joined ##javaee |
| 13:29 |
|
|
javaeebot joined ##javaee |
| 13:55 |
|
|
sl33k joined ##javaee |
| 13:56 |
|
pdurbin |
Naros: our Glassfish 4 upgrade doc, just published: https://github.com/IQSS/dvn/blob/develop/doc/platform/upgrade/ee7gf4/README.txt ... in case you see anything interesting in there |
| 13:57 |
|
Naros |
Awesome, thanks i"ll bookmark it |
| 13:57 |
|
pdurbin |
sure. we're not there yet but making progress |
| 14:12 |
|
|
sl33k joined ##javaee |
| 14:12 |
|
|
sl33k left ##javaee |
| 14:25 |
|
|
jieryn_ joined ##javaee |
| 14:26 |
|
cheater_3 |
pdurbin: that's exactly what they say |
| 14:26 |
|
cheater_3 |
what the log says |
| 14:26 |
|
cheater_3 |
it says ".jar" |
| 14:26 |
|
pdurbin |
cheater_3: yes, but why? |
| 14:26 |
|
cheater_3 |
pdurbin: i have no idea :/ |
| 14:27 |
|
cheater_3 |
people who know jboss told me this has little to do with jboss and a lot to do with java ee, but i don't really understand either technology 100% |
| 14:27 |
|
pdurbin |
cheater_3: I'd ask in #wildfly |
| 14:27 |
|
cheater_3 |
i tried asking in #wildfly, they have been helpful in solving other issues, but nobody has an idea on that one |
| 14:29 |
|
pdurbin |
cheater_3: dunno. I use glassfish. try it with glassfish |
| 14:30 |
|
cheater_3 |
i dunno how, i've never used glassfish |
| 14:30 |
|
Naros |
pdurbin: no worries, I'm still in the code rewrite phase of our core API so it'll be a bit before I retry GF4 :P |
| 14:30 |
|
cheater_3 |
i'm sort of trying to minimize the changes in environment, so that i'm not TOO stumped by this |
| 14:31 |
|
pdurbin |
cheater_3: I sympathize |
| 14:31 |
|
pdurbin |
Naros: good luck! |
| 14:31 |
|
cheater_3 |
i'll try asking in #wildfly again, maybe someone else is online |
| 14:31 |
|
Naros |
thank you, I need it. |
| 14:32 |
|
cheater_3 |
but if one of you guys comes up with anything, let me know please |
| 14:32 |
|
Naros |
Rewriting two years of API in < 8 weeks is gonna be tough :P |
| 14:32 |
|
pdurbin |
Naros: get to work! |
| 14:32 |
|
Naros |
:P |
| 14:33 |
|
pdurbin |
:) |
| 14:39 |
|
|
jieryn joined ##javaee |
| 14:43 |
|
|
Quest joined ##javaee |
| 14:46 |
|
cheater_3 |
when rewriting the API, do you have a list of all edge cases that you have encountered during the evolution of the old version? |
| 15:01 |
|
Naros |
We do. The rewrite addresses those by enforcing a standard that works across both normal and edge cases finally. |
| 15:01 |
|
Naros |
At least until we reach that point where another edge case crops up :P |
| 15:02 |
|
Naros |
A majority of the api rewrite was to separate individual chunks of functionality into separate projects rather than being one massive project. |
| 15:03 |
|
Naros |
plus to address some bad package designs too |
| 15:07 |
|
sess |
Guest95242: was thinking of your IP thingy yesterday; i realized the whole thing can be solved using client logic only, where are JSON apis where you just send an ip and get a location back. Free of charge and like 2 lines of code |
| 15:16 |
|
|
AlexCzar joined ##javaee |
| 15:17 |
|
|
sfisque joined ##javaee |
| 15:18 |
|
Guest95242 |
no no. sess we use our custom strategy. very custom to product and its way of communication. the issue is resoled. I R&D yesterday. got some views. and yours helped a lot too. the thing we are using is MaxMind. looks satisfactory to me though. secondly, the columns were varchars, . the BETWEEN statement did accomodated but its made for Range comparison, that is columns should have been ints. thats why index was not used. |
| 15:19 |
|
Guest95242 |
converted to ints and used a COMPOSITE index. now we are good! |
| 15:20 |
|
sess |
Guest95242: custom strategy? how many strategies can exist for determing the country of an IP |
| 15:21 |
|
Guest95242 |
well did you see maxmind? |
| 15:21 |
|
sess |
i have no idea what maxmind is |
| 15:21 |
|
Guest95242 |
it eliminates the dots from ip and converts the ip to 8-9 digit no. theres a start rand and end range. each has a country. |
| 15:21 |
|
Guest95242 |
works pretty wel |
| 15:22 |
|
sess |
if you use an external web service you have no need for that data to start with |
| 15:22 |
|
pdurbin |
javaeebot: lucky maxmind |
| 15:22 |
|
Guest95242 |
no. the db table is the IP table that we downloaded from max mind |
| 15:22 |
|
javaeebot |
pdurbin: http://www.maxmind.com/ |
| 15:23 |
|
sess |
my point is |
| 15:23 |
|
sess |
remove your db table |
| 15:23 |
|
Guest95242 |
sess, all managed inhouse |
| 15:23 |
|
sess |
remove all your sql logic |
| 15:23 |
|
Guest95242 |
am. why? |
| 15:23 |
|
sess |
replace it with a single line of javascript |
| 15:23 |
|
sess |
$.get('http://somegeosite/some-IP', handler) |
| 15:24 |
|
sess |
returns json with location information |
| 15:24 |
|
Guest95242 |
sess, javascript dont run on mobile devices in applications and running it on server is another story |
| 15:24 |
|
sfisque |
sess that would work, except if the client cannot reach that webservice for whatever reason |
| 15:24 |
|
sfisque |
firewall |
| 15:24 |
|
sfisque |
routing |
| 15:24 |
|
sfisque |
trust |
| 15:24 |
|
sess |
what firewall blocks all http traffic |
| 15:25 |
|
sess |
Guest95242: mobile devices does run javascript |
| 15:25 |
|
Guest95242 |
none to my knowledge. we use http our self. even on old mobiles but. there are issues on JS in apps |
| 15:25 |
|
sfisque |
my point is, if his client can see the site that served up the page, it's guaranteed that it can get this data from THAT site |
| 15:25 |
|
sess |
and you could also do this server side |
| 15:25 |
|
sess |
sfisque: so do it server side then |
| 15:25 |
|
sess |
unless the web server is on a closed intranet with no internet enabled |
| 15:25 |
|
Guest95242 |
we just didnt wanted to be depended on a third party service we cant tune up ............. |
| 15:25 |
|
sfisque |
that's another reason |
| 15:26 |
|
Guest95242 |
we == me in this case |
| 15:26 |
|
sess |
well it's a decision then between delying on a trusted 3rd part, or spending thousands of dollars on a custom solution that is 10x slower |
| 15:26 |
|
Guest95242 |
tune/ further customize/ add/ delete features |
| 15:26 |
|
sess |
you could also download their source code and db for free |
| 15:26 |
|
sfisque |
not necessarily sess. there are good reasons to cache data from a webservice. data mining. resiliency. |
| 15:27 |
|
Guest95242 |
our solution is as fast as our application. as its on the same server/db |
| 15:27 |
|
* Guest95242 |
agrees with sfisque on that^ |
| 15:27 |
|
sess |
Guest95242: how long time to fetch the country now*? |
| 15:27 |
|
Guest95242 |
cache is what we were working on |
| 15:27 |
|
sess |
this service i tried did it in like <100ms |
| 15:27 |
|
Guest95242 |
.233ms |
| 15:27 |
|
sess |
without any sort of cache |
| 15:28 |
|
sess |
oh well it's your choice, I just think you are reinventing the wheel |
| 15:28 |
|
Guest95242 |
.233ms is our fastest query in the app itself. so all speed is == .233ms. so we dont bother |
| 15:28 |
|
Guest95242 |
sess, no. we are customizing the wheel. it was made by maxmind though |
| 15:28 |
|
Guest95242 |
we are just using it. |
| 15:29 |
|
sess |
thats just an algorithm |
| 15:29 |
|
sess |
you still need to construct the database, query logic, get the actual data, setup a cache system |
| 15:29 |
|
Guest95242 |
sess, your point of view is nice but things are different here and iam not the only decision maker too :) |
| 15:29 |
|
sess |
etc |
| 15:29 |
|
sess |
sure, i dont know your business |
| 15:29 |
|
Guest95242 |
sess, that has already been made. even when i didnt joined the company |
| 15:29 |
|
Guest95242 |
they dont migrate easily |
| 15:30 |
|
Guest95242 |
and iam not the only decision maker too :) |
| 15:30 |
|
Guest95242 |
nice point though. |
| 15:30 |
|
Guest95242 |
got to hurry now.. |
| 15:30 |
|
Guest95242 |
dinner.. |
| 15:44 |
|
|
SoniEx2 joined ##javaee |
| 16:28 |
|
cheater_3 |
Naros: how do you know you've taken care of all edge cases? |
| 16:28 |
|
Naros |
That's what JUnit test cases validate :P |
| 16:28 |
|
cheater_3 |
so are you using the unit test suite from the old api version? |
| 16:29 |
|
Naros |
The service API remains hardly unchanged, so yes. |
| 16:29 |
|
cheater_3 |
interesting |
| 16:29 |
|
Naros |
The UI requirements aren't changing which is what the service tier dictates. |
| 16:29 |
|
Naros |
So as long as the service gives the UI what it expects, I'm good. |
| 16:30 |
|
cheater_3 |
ok |
| 16:30 |
|
sfisque |
cheater_3 : you can never catch ALL edge cases. if we did, there would never be x.y.Z releases |
| 16:30 |
|
sfisque |
every product would only have X releases with no patches or bug fixes |
| 16:30 |
|
cheater_3 |
i was just wondering how you approached this subject, it's always interesting |
| 16:30 |
|
Naros |
I'm sure there are use cases missed, that's what maintenance is all about :) |
| 16:31 |
|
Naros |
and job security :P |
| 16:31 |
|
sfisque |
and then there are always the interesting "heisenbugs" |
| 16:31 |
|
whartung |
Customers are great for coming up with edge cases. Developers tend to view the world too rationally. |
| 16:31 |
|
* Naros |
agrees with whartung. |
| 16:32 |
|
cheater_3 |
oh i meant old edge cases |
| 16:32 |
|
cheater_3 |
that were solved in the old implementation |
| 16:32 |
|
Naros |
What do you mean my if has to be fuzzy and do this but that specific case, do that and oh by the way, this other condition I should do something entirely unrelated and backward :o |
| 16:32 |
|
cheater_3 |
i was wondering how they carried over to the rewrite, that's all |
| 16:32 |
|
Naros |
In a rewrite, generally old functionality should remain identical unless it's being abolished. |
| 16:33 |
|
Naros |
If the interfaces remain unchanged, that becomes somewhat trivial. |
| 16:33 |
|
Naros |
That's why all our services are derived from interfaces |
| 16:34 |
|
Naros |
Internally they can be changed to do w/e I want without affecting the outside world |
| 16:35 |
|
cheater_3 |
it's just that, quote often tiny edge cases get filed as "bugs", the documentation fails to mention them, and so do tests against the public apis, and so during a rewrite solutions to those edge cases get lost. |
| 16:35 |
|
cheater_3 |
*quite often |
| 16:35 |
|
Naros |
every bug has a test case :P |
| 16:35 |
|
Naros |
that validates that the bug is in fact resolved and addresses the problem. |
| 16:36 |
|
Naros |
at least when it comes to API related stuffs where test cases can be generated |
| 16:36 |
|
Naros |
Otherwise the fix never makes it's way to production. |
| 16:36 |
|
sfisque |
we (the team i work on) just had an interesting revelation. we're moving to wiring our product to an internally developed SSO, and we asked that team, what is the protocol in question (REST, RMI, SOAP, CORBA, etc?) they responded taht they exposed a JSON interface, BUT they assumed internal (e.g. our product) would use Spring Remoting instead. my thought.." so, you decided a third party proprietary api was preferable to using an industry standard? rii |
| 16:37 |
|
* Naros |
rolls eyes. |
| 16:38 |
|
Naros |
An exposed API should honestly NEVER care about the consumption method. |
| 16:38 |
|
sfisque |
yeah. my primary thought, "so, i'm just a contractor, and these trained monkeys are architects…." makes me almost ready to retire from this industry and go pull espresso |
| 16:38 |
|
* sfisque |
hugs naros |
| 16:38 |
|
sfisque |
PREACH ON, BRUTHAH!!! |
| 16:38 |
|
Naros |
yah, overpaid noobs |
| 16:38 |
|
Naros |
the "architects" I mean |
| 16:38 |
|
sfisque |
aye |
| 16:40 |
|
sfisque |
the sad thing is, i've submitted resumes for a couple arch positions around town here, and i always keep running up against the wall of, "so have you done this before".. and my standard answer of "yes, but not in title. i want to actually hold the title that matches what i'm doing", seems to not get me any traction |
| 16:40 |
|
* Naros |
punches MyEclipse in da face! |
| 16:41 |
|
* sfisque |
holds MyEclipse down so naros can get in a few more kicks |
| 16:41 |
|
sfisque |
vicarious enjoyment |
| 16:41 |
|
Naros |
I really hate it when I change a class, bounce the app server and my changes don't happen. I add debug statements and do the same process and be damned if the new code gets executed :E |
| 16:42 |
|
Naros |
yah I'm in the same boat sfisque. |
| 16:42 |
|
Naros |
But we have a lot of "unique" cases we do here that I doubt I'd ever do anywhere else E: |
| 16:43 |
|
cheater_3 |
sfisque: just tell them you have. who cares about the title? it's all about the experience |
| 16:43 |
|
Naros |
All because the flippin upper management says that's how it's gotta be, despite whether it's 'right' or 'wrong'. |
| 16:43 |
|
cheater_3 |
they're asking if you've done this, not if you've done this under a specific title, right? |
| 16:45 |
|
sfisque |
the way they ask, they're looking for actually holding that position. i spend time describing what i've done, but i can tell they're looking for people who've "held the position", sigh |
| 16:45 |
|
sfisque |
i can read it from their language choices during the interview |
| 16:45 |
|
whartung |
ya know what? Back when we were talking SSO and all, we surveyed the landscape, and we chose SAML with all of its warts and such. We could have picked our or, or gone OAuth…but we stuck with SAML. |
| 16:45 |
|
cheater_3 |
sfisque: just lie, they're too stupid to be told the truth |
| 16:46 |
|
whartung |
Know what? We've never been asked for other integrations. |
| 16:46 |
|
whartung |
We did it for ourselves, for our apps |
| 16:46 |
|
whartung |
and when folks see that we have SAML support they're like "Really!??" |
| 16:46 |
|
cheater_3 |
sfisque: if they do find out, you'll have earnt some money, and even if you're fired without references that's beter than being unemployed for just as long |
| 16:46 |
|
whartung |
and off we go doing more SAML integrations. |
| 16:46 |
|
sfisque |
oh, you were asking about the SSO, i was referring to the arch interviews |
| 16:47 |
|
whartung |
I'm talking about the "JSON payload for SSO" |
| 16:47 |
|
whartung |
and I'm like, "WTF?" |
| 16:47 |
|
sfisque |
C3: yeah, but i'm very scrupulous about keeping black eyes off my resume |
| 16:48 |
|
sfisque |
whartung oh yeah. i've no issue with using json (some of our products are heavy client side js, so it makes sense). i'm just flabergasted that they assume all internal products are built on spring and can trivially integrate spring remoting, WHEN we can just use the impl generic JSON endpoints? why!?!? WHY!?!??! WHY!!L:!!:!:L!IIIL!:I:L! |
| 16:49 |
|
cheater_3 |
sfisque: worst case scenario you'll have a gap you don't put on your resume. |
| 16:50 |
|
whartung |
well that's my point. One of the bullet point on the box of REST is "Serendipitous reuse". When you actually use standards, you find that others actually use standards, and suddenly new integrations are available that weren't before. |
| 16:50 |
|
sfisque |
gaps can be a black eye. when you have 20ish years of exp, gaps are red flags |
| 16:50 |
|
whartung |
Like using LDAP on the back for credentials. |
| 16:50 |
|
* sfisque |
nods with whartung |
| 16:50 |
|
sfisque |
preaching to the choir, man. |
| 16:51 |
|
sfisque |
i'm just venting because our east-coast HQ often foists crap on us like this, and it makes my eyeballs twitch |
| 17:06 |
|
|
cem_ joined ##javaee |
| 17:07 |
|
cem_ |
hi pdurbin |
| 17:08 |
|
cem_ |
i'm going to learn database where to start ? |
| 17:11 |
|
sfisque |
javaeebot lucky sql tutorial java |
| 17:11 |
|
javaeebot |
sfisque: http://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html |
| 17:11 |
|
sfisque |
javaeebot lucky sql tutorial complete beginner |
| 17:11 |
|
javaeebot |
sfisque: http://www.sqlcourse.com/ |
| 17:13 |
|
pdurbin |
cem_: are you looking to learn SQL or JPA? |
| 17:13 |
|
cem_ |
what is jpa i want to learn database |
| 17:14 |
|
cem_ |
i dont know sql or jpa |
| 17:14 |
|
sfisque |
i'd recommend sql first, since jpa is just objectified sql |
| 17:14 |
|
cem_ |
where to start is it database ? |
| 17:15 |
|
sfisque |
javaeebot lucky launching configuring javadb |
| 17:15 |
|
javaeebot |
sfisque: http://www.oracle.com/technetwork/java/javadb/securitywhitepaper10-159253.pdf |
| 17:15 |
|
sfisque |
java has a db built into it |
| 17:15 |
|
sfisque |
so you can start there. easier than wrestling with building out a mysql or other instance |
| 17:16 |
|
pdurbin |
or could start with sqlite |
| 17:16 |
|
sfisque |
though that link might not be what we want |
| 17:16 |
|
pdurbin |
javaeebot: lucky sqlite |
| 17:16 |
|
sfisque |
yah sqlite would be good too |
| 17:16 |
|
javaeebot |
pdurbin: http://www.sqlite.org/ |
| 17:16 |
|
sfisque |
javaeebot lucky javadb configure launch -security |
| 17:16 |
|
javaeebot |
sfisque: http://netbeans.org/kb/docs/ide/java-db.html |
| 17:17 |
|
sfisque |
nice and done from a netbeans standpoint too |
| 17:17 |
|
sfisque |
double win |
| 17:17 |
|
* sfisque |
does the double win dance |
| 17:18 |
|
|
balazare joined ##javaee |
| 17:24 |
|
semiosis |
anyone tried visualvm 1.3.6? i can't connect to any local processes except the visualvm itself |
| 17:24 |
|
cem_ |
i'm starting sqlite then javadb :) |
| 17:24 |
|
semiosis |
but 1.3.5 works fine |
| 17:26 |
|
pdurbin |
semiosis: I saw it demo'ed at javaone. seems nice |
| 17:26 |
|
pdurbin |
cem_: good choice |
| 17:26 |
|
semiosis |
pdurbin: well generally visualvm is an excellent tool, but this latest release is a dud afaict |
| 17:26 |
|
pdurbin |
:( |
| 17:34 |
|
sfisque |
semiosis, run it as root, you have to be root to connect via IPC |
| 17:34 |
|
semiosis |
i'll give that a try |
| 17:34 |
|
sfisque |
otherwise you ahve to connect via TCP (treat as remote, use 127.0.0.1 as address) |
| 17:34 |
|
semiosis |
and this is new in 1.3.6? |
| 17:34 |
|
sfisque |
negative |
| 17:34 |
|
semiosis |
um ok |
| 17:35 |
|
sfisque |
it's an arfifact of the underlying OS. shouldnt matter because you cannot connect to another process unless you own the process or are root |
| 17:35 |
|
sfisque |
or the process opens a world/group readable file socket |
| 17:36 |
|
sfisque |
or they set the perms appropriately on shm/sem |
| 17:36 |
|
sfisque |
but those are huge security holes |
| 17:36 |
|
semiosis |
all processes are running as my user |
| 17:36 |
|
sfisque |
that might be a bug or a "change" then |
| 17:36 |
|
semiosis |
ok |
| 17:36 |
|
sfisque |
"a feature" :P |
| 17:36 |
|
semiosis |
when i'm ready to run again in a few min i'll try sudo visualvm |
| 17:36 |
|
sfisque |
it might be part of the flurry of security patches that went in during the last year |
| 17:41 |
|
pdurbin |
Naros: should I do it? follow that readme? install java 7 and glassfish 4? |
| 17:41 |
|
* pdurbin |
only has java 6 installed |
| 17:41 |
|
Naros |
We use Java7 here. |
| 17:41 |
|
Naros |
Have been for months now. |
| 17:42 |
|
pdurbin |
cool |
| 17:42 |
|
semiosis |
sfisque: same hang with sudo as without :( |
| 17:42 |
|
sfisque |
we recently moved to 7. other than having to rev primefaces, our app runs fine on 3.1.2.2 on top of 7 |
| 17:42 |
|
sfisque |
interesting semiosis |
| 17:42 |
|
sfisque |
using openjdk or oracle jdk? |
| 17:42 |
|
semiosis |
either |
| 17:42 |
|
sfisque |
hrm. stumped |
| 17:42 |
|
sfisque |
maybe ##java have an answer? |
| 17:42 |
|
semiosis |
yeah me too. oh well, 1.3.5 is good |
| 17:42 |
|
semiosis |
maybe |
| 17:43 |
|
pdurbin |
good enough |
| 17:43 |
|
sfisque |
1.3.x is pretty ancient. i'm running 1.7.x here |
| 17:43 |
|
sfisque |
which came bundled with oracle jdk7 |
| 17:43 |
|
sfisque |
1.7.0_17 build 120605 |
| 17:44 |
|
cem_ |
what is difference between oraclejdk vs openjdk ? i downloaded java from oracle website |
| 17:44 |
|
pdurbin |
I'm running the Java 6 that Apple provides. When OS X asks, "Do you want me to install Java for you?" But I don't think Apple provides Java 7 |
| 17:44 |
|
sfisque |
open i believe uses "other" libs in place of the com.sun and com.oracle "hidden" imple classes |
| 17:45 |
|
sfisque |
aye, 7 is oracle. pre 7 is apple provided |
| 17:45 |
|
cem_ |
apple fixes security bug for you |
| 17:46 |
|
semiosis |
sfisque: 1.3.x of what? |
| 17:46 |
|
pdurbin |
I guess I'll try this bundle: JDK 7u45 with NetBeans 7.4 |
| 17:47 |
|
semiosis |
sfisque: latest visualvm is 1.3.6 from july of this year |
| 17:47 |
|
semiosis |
http://visualvm.java.net/ |
| 17:59 |
|
whartung |
biggest difference between oracle jdk and open jdk is the oracle jdk works |
| 18:05 |
|
pdurbin |
heh |
| 18:06 |
|
cem_ |
Oracle JDK 7 is built from OpenJDK ? |
| 18:07 |
|
sfisque |
rofl whartung |
| 18:07 |
|
sfisque |
semiosis, i guess what the "bundled" version echos out is the "corresponding jdk version" then |
| 18:07 |
|
sfisque |
which is annoying |
| 18:13 |
|
whartung |
traceroute 216.81.59.173 |
| 18:13 |
|
|
zoot joined ##javaee |
| 18:13 |
|
zoot |
hai |
| 18:16 |
|
sfisque |
traceroute is blocked here, but that ip maps to Epik Networks, Inc. EPIK-NETWORKS (NET-216-81-48-0-1) 216.81.48.0 - 216.81.63.255 |
| 18:17 |
|
sfisque |
16 x24 cidr blocks |
| 18:17 |
|
semiosis |
ok here's a real question for you javaee experts |
| 18:17 |
|
sfisque |
** x/24 |
| 18:18 |
|
sfisque |
the answer is "4" semiosis |
| 18:18 |
|
whartung |
4.2 |
| 18:18 |
|
semiosis |
i have a sql query that takes 0.05 seconds to execute on the mysql command line, but when i use a nativequery in jpa/hibernate it takes 7 seconds |
| 18:18 |
|
semiosis |
why? |
| 18:18 |
|
zoot |
locking? |
| 18:18 |
|
semiosis |
hmmm |
| 18:18 |
|
sfisque |
serialization/deserialization probably |
| 18:19 |
|
sfisque |
and jta boundaries |
| 18:19 |
|
semiosis |
sfisque: the result is a single int, it's a count query |
| 18:19 |
|
sfisque |
have you wired it up in a profiler? |
| 18:19 |
|
semiosis |
yes |
| 18:19 |
|
sfisque |
take the deep dive and see where the time is spent |
| 18:20 |
|
semiosis |
mysql.jdbc.util.ReadAheadInputStream.fill() |
| 18:20 |
|
sfisque |
there you go. it's the driver |
| 18:21 |
|
sfisque |
maybe you need a newer driver? different version? |
| 18:21 |
|
whartung |
ints are expensive... |
| 18:21 |
|
semiosis |
i'm going to tcpdump this |
| 18:21 |
|
sfisque |
lol whartung |
| 18:21 |
|
semiosis |
i suspect the counting is happening in java instead of in the db |
| 18:21 |
|
sfisque |
that would be terrible if so |
| 18:21 |
|
whartung |
no |
| 18:21 |
|
sfisque |
i'm guessing there is a bug in the driver |
| 18:22 |
|
whartung |
if you're using "count", it's not hapening |
| 18:23 |
|
semiosis |
originally i was reporting this count by calling size on the collection, letting jpa/hibernate do its thing, but that took 7 seconds |
| 18:23 |
|
semiosis |
so i replaced that with a jpql namedquery, same 7 seconds |
| 18:23 |
|
semiosis |
then a nativequery... same 7 seconds |
| 18:24 |
|
semiosis |
oooh i'm on to something here... i suspect this may have to do with eager fetching while authenticating the request! |
| 18:25 |
|
sfisque |
dun dun dunnnnnnnnn |
| 18:25 |
|
semiosis |
:) |
| 18:26 |
|
semiosis |
yep |
| 18:26 |
|
semiosis |
ok never mind |
| 18:36 |
|
semiosis |
removed the eager fetch (back to lazy now) and the original jpa count takes 5.5 seconds vs. 0.9s for the native query \o/ |
| 18:37 |
|
zoot |
\o/ |
| 18:37 |
|
whartung |
hiss |
| 18:38 |
|
pdurbin |
zoot is here! |
| 18:38 |
|
zoot |
yay i'm me |
| 18:38 |
|
whartung |
I had a zoot, but it went away after putting some creme on it |
| 18:39 |
|
cem_ |
bye |
| 18:40 |
|
zoot |
whartung: in it* |
| 18:41 |
|
semiosis |
looks like a regular namedquery is just as fast as a nativequery, in this case |
| 18:41 |
|
semiosis |
interesting |
| 18:42 |
|
sfisque |
named queries are precompiled so they should be almost as fast |
| 18:43 |
|
sfisque |
i know jboss and glassfish will precompile them during bootstrapping the war/ear deployment |
| 18:44 |
|
zoot |
they should even be faster than native |
| 18:44 |
|
sfisque |
named queries are still 1 translation layer away. PQL -> SQL. native are zero translations away |
| 18:45 |
|
semiosis |
sfisque: still that translation is probably O(1) so i'm not worried about it |
| 18:45 |
|
sfisque |
of course, but i'd be surprised if Named was faster than Native. i'd argue it will always be a shave slower |
| 18:45 |
|
semiosis |
hmm maybe O(n) when i'm not doing a simple count |
| 18:46 |
|
sfisque |
O(k) |
| 18:46 |
|
sfisque |
:-) |
| 18:46 |
|
semiosis |
zoot: why faster? |
| 18:47 |
|
zoot |
arn't they prepared statements? |
| 18:48 |
|
zoot |
they are sent as non-sql querys to all major dbs |
| 18:48 |
|
semiosis |
i think native queries are as well |
| 18:49 |
|
sfisque |
i would guess that would be an implementation detail (prepared versus precompiled into some intermediary format) of the JPA impl in the container/ear |
| 18:53 |
|
zoot |
Prepared statements are widely supported by major DBMSs, including MySQL,[7] Oracle,[8] DB2,[9] Microsoft SQL Server,[10] and PostgreSQL.[5] Prepared statements are normally executed through a non-SQL binary protocol, for efficiency and protection from SQL injection, but with some DBMSs such as MySQL are also available using a SQL syntax for debugging purposes.[11] |
| 18:53 |
|
zoot |
http://en.wikipedia.org/wiki/Prepared_statement#Software_support |
| 18:54 |
|
zoot |
all i can find on it |
| 19:04 |
|
sfisque |
right but the question is, does the JPA spec require @NamedQuery to be processed into a prepared statement, or are the impl's free to preprocess them however they want (prepared, nothing, intermediary optimized format, etc.) |
| 19:55 |
|
|
Guest95242 joined ##javaee |
| 20:18 |
|
zoot |
now to something else, can a ask my ejb 3.1/ee6 container to process a message at 8:00am or any other time specified for each message? |
| 20:20 |
|
acuzio |
its called a batch service |
| 20:22 |
|
zoot |
isn't that just a timer? |
| 20:22 |
|
pdurbin |
somehow I was thinking "jms timer" |
| 20:23 |
|
acuzio |
it is a timer - a batch service running on time - via cron ; simples |
| 20:24 |
|
zoot |
but timers can only be set at compiletime? |
| 20:24 |
|
acuzio |
what ? |
| 20:25 |
|
whartung |
if you use timers via annotations, yes, that's true |
| 20:25 |
|
zoot |
arent we taling about @schedule? |
| 20:25 |
|
acuzio |
not me |
| 20:26 |
|
whartung |
he's talking about EJB times acuzio |
| 20:26 |
|
whartung |
batch is in JEE 7, |
| 20:26 |
|
acuzio |
whartung: ah |
| 20:26 |
|
zoot |
tell me more |
| 20:26 |
|
whartung |
he's talking JEE6 |
| 20:26 |
|
acuzio |
whartung: got you - i came in half way |
| 20:27 |
|
whartung |
JEE 7 has a new facility that doesn't replace EJB Timers, but rather it's a larger background processing system |
| 20:27 |
|
zoot |
i found something called timerservice in ee6 |
| 20:27 |
|
whartung |
timer service lets you interact with JEE timers |
| 20:27 |
|
whartung |
you can schedule stuff on the fly if you want |
| 20:27 |
|
whartung |
the key take away about JEE timers |
| 20:28 |
|
whartung |
is that if you have a pending timer in the container, it will persist across container restarts. |
| 20:28 |
|
whartung |
HOWEVER |
| 20:28 |
|
whartung |
they do NOT persist across application redeploys |
| 20:29 |
|
whartung |
@scheudle never made a whole lot of sense to me, the use is just too narrow IMHO |
| 20:35 |
|
zoot |
is it possible to get a callback when the application gets redeployed? and manally save them |
| 20:37 |
|
whartung |
there's two gross areas in JEE where you can be notified that that application is "up". |
| 20:38 |
|
whartung |
one is within the web container. If your JEE app has a web app, as the web app is fired up you can hook in to a SessionContextListener. This will get called with the web app is started and when it is shut down. |
| 20:38 |
|
whartung |
in the JEE container, in JEE 6, you can tie in to the lifecycle of the container with a Singleton Session bean, since these have a normal EJB life cycle, and are ensured by the container to "always exist", and there's only 1 of them (being a singleton) |
| 20:39 |
|
zoot |
oh cool, thanks whartung |
| 20:39 |
|
zoot |
whartung++ |
| 20:40 |
|
pdurbin |
there's a reason we keep whartung around |
| 20:40 |
|
whartung |
old school, you would use a customer load-on-startup servlet and leverage it's init() and destroy() method. |
| 20:40 |
|
* whartung |
crawls back in to his box |
| 20:42 |
|
acuzio |
thats not old school |
| 20:43 |
|
acuzio |
JEE and old school haa |
| 20:44 |
|
acuzio |
in my days , we used to scratch on silicon and check if the tides were ok and the moon was in the right quadrant and then send a tiny butterfly fluttering - at the right time it would flip a switch and the service would run |
| 20:44 |
|
whartung |
You had a moon? |
| 20:45 |
|
acuzio |
ha :-) |
| 20:46 |
|
whartung |
we had to reengineer all the servers after the exo-planet impact and having to fight tides and moon phases. Redo the calendar systems was a nightmare... |
| 20:46 |
|
acuzio |
and you chose Julian |
| 20:47 |
|
whartung |
That cursed pope, ruined everything... |
| 20:47 |
|
acuzio |
where do you work whartung ? (what industry ) |
| 20:48 |
|
whartung |
health care -- is there another industry in IT today? |
| 20:48 |
|
acuzio |
Finance |
| 20:48 |
|
whartung |
ah yea |
| 20:48 |
|
whartung |
heard of that |
| 20:48 |
|
whartung |
once.. |
| 20:48 |
|
acuzio |
no wonder you know JEE |
| 20:49 |
|
* pdurbin |
muses about git feature branches: http://irclog.greptilian.com/sourcefu/2013-10-24 |
| 20:49 |
|
acuzio |
in finance at least where in the areas i work in - JEE is a dirty word - for valid reasons |
| 20:49 |
|
whartung |
why so? |
| 20:49 |
|
whartung |
don't hurt yourself pdurbin -- git and branching.../shudder, dannngerous |
| 20:50 |
|
whartung |
(branching is easy…super easy…trivial easy….merging, on the other hand...) |
| 20:50 |
|
acuzio |
pdurbin: use git only if the folks you work with are reasonably clueful |
| 20:50 |
|
acuzio |
whartung: i work in Trading systems - JEE , container managed |
| 20:50 |
|
acuzio |
nope - too slow and too cumbersome |
| 20:50 |
|
whartung |
yea |
| 20:50 |
|
whartung |
that doesn't surprise me |
| 20:51 |
|
whartung |
and it doesn't bother me either |
| 20:51 |
|
acuzio |
the last time i did JEE - i used Orion ; now that was an AppServer worth using - fantastic piece of kit that was |
| 20:51 |
|
whartung |
omg |
| 20:51 |
|
acuzio |
why |
| 20:54 |
|
acuzio |
i still sometimes use things like JPA , JMS but other than Servlets (which i use regularly via REST) - the rest of the stuff is dead to me |
| 20:55 |
|
zoot |
gah |
| 20:55 |
|
zoot |
rest should a forbidden word, like cloud computing |
| 20:55 |
|
zoot |
should be* |
| 20:58 |
|
zoot |
Oracle Corporation acquired license to the source of Orion in 2001 |
| 20:59 |
|
acuzio |
zoot: i know |
| 20:59 |
|
acuzio |
zoot: and no REST should not be a forbidde word |
| 20:59 |
|
zoot |
thats why i have never heard of it :( |
| 20:59 |
|
whartung |
yea, my point about Orion was simply that it's been so long |
| 20:59 |
|
acuzio |
zoot: I was using Orion from around 2002 till about 2004 - at my first job - at oracle |
| 21:01 |
|
whartung |
I don't recall if oracle rebranded orion as their original app server |
| 21:01 |
|
whartung |
but orion was more a servlet container I think rather than a JEE container |
| 21:01 |
|
whartung |
I think REST should be banned from those who aren't actually practicing it. |
| 21:01 |
|
whartung |
when they actually mean "sending stuff over HTTP" |
| 21:01 |
|
acuzio |
nope fully J2EE compliant and ORCL did rebrand it |
| 21:01 |
|
whartung |
ok |
| 21:02 |
|
acuzio |
whartung: re- REST i agree ; sending stuff over http is not REST |
| 21:02 |
|
whartung |
si |
| 21:02 |
|
whartung |
that's my only nit |
| 21:02 |
|
acuzio |
whartung: and as is normal with anything that oracle touches - it became shit |
| 21:02 |
|
whartung |
mind, we do that all the time here…but, such is life |
| 21:02 |
|
whartung |
:) |
| 21:03 |
|
zoot |
rest isn't a protocol, therfore it isn't a word :P |
| 21:03 |
|
acuzio |
the 2 devs who had developed took the boat load of money and basically retired for life |
| 21:03 |
|
whartung |
REST is an architecture |
| 21:03 |
|
whartung |
good for them :) |
| 21:04 |
|
acuzio |
and a pretty good one REST i.e. |
| 21:04 |
|
whartung |
so, what made it so good? what did you like about it? |
| 21:04 |
|
whartung |
orion... |
| 21:04 |
|
zoot |
it was swedish! |
| 21:04 |
|
whartung |
that was such an interesting time |
| 21:04 |
|
whartung |
remember Enhydra? |
| 21:05 |
|
zoot |
wikipedia does |
| 21:05 |
|
whartung |
heh |
| 21:05 |
|
zoot |
http://en.wikipedia.org/wiki/Enhydra_Server |
| 21:06 |
|
whartung |
wow JOnAS is still alive... |
| 21:06 |
|
acuzio |
whartung: it was simple, fast, minimal configuration, worked out of the box and was fully compliant when Weblogic, Websphere were both not and attempting to shove a shit load of crap onto you |
| 21:06 |
|
whartung |
we worked on web logic at the time. |
| 21:07 |
|
acuzio |
I just got lucky that i got into ORCL for my internship and was using Orion during uni so it just sort of nicely blended in |
| 21:07 |
|
acuzio |
WLS was, is and will remain shit |
| 21:08 |
|
zoot |
;DDD |
| 21:10 |
|
acuzio |
Jetty is my choice now - yes i know its not a fully-compliant JEE server but for what i do - its perfect - |
| 21:10 |
|
zoot |
you are doing web? |
| 21:10 |
|
acuzio |
i want to run my code ; not wade through layers of shit to get to my code |
| 21:10 |
|
acuzio |
zoot: yes i do "web" as well |
| 21:11 |
|
zoot |
yea, it kind of sucks since web tends to be bleedingedge |
| 21:11 |
|
zoot |
i'm a WLS user, and have been for the last four years.. |
| 21:11 |
|
acuzio |
its shit |
| 21:13 |
|
zoot |
its war |
| 21:14 |
|
zoot |
phun intended |
| 21:14 |
|
sfisque |
in one ear and out the other. hopeful you want get sars or eat something rarE |
| 21:15 |
|
sfisque |
:P |
| 21:15 |
|
sfisque |
after putting it i a jar :P |
| 21:15 |
|
whartung |
TMI |
| 21:15 |
|
acuzio |
laters |
| 21:15 |
|
whartung |
tt acuzio |
| 21:27 |
|
pdurbin |
whartung: heh. your "WTF JSON payload for SSO" :) |
| 22:50 |
|
|
Guest95242 joined ##javaee |
| 23:17 |
|
sfisque |
has anyone here used spring remoting in a way where the remote side was using spring remoting and on the client side just talked to the underlying protocol (RMI, JAX-RPC, JMS, whatever)? |
| 23:49 |
|
sfisque |
anyone? |
| 23:51 |
|
pdurbin |
aren't java ee and spring at odds? |
| 23:53 |
|
sfisque |
sort of. the issue is the previously mentioned identity service exposes an api via spring remoting. i'd prefer to not pollute our build with spring kruft, and from what i have read, spring remoting is just a wrapper on top of 7 different wire protocols (configurable to which one the service uses). once i find out "how" they are exposing their API, i'd like to (instead of using spring remoting) just talk directly "to the wire" (e.g. JAX-WS, RMI, JMS, whi |
| 23:54 |
|
sfisque |
but i'm not finding any docs on "how to do that". which means, i can either draw on someone's knowledge second hand, OR try it out myself |
| 23:54 |
|
sfisque |
and see what happens |
| 23:54 |
|
pdurbin |
or AMQP or ZeroMQ or whatever |
| 23:55 |
|
sfisque |
right |
| 23:55 |
|
sfisque |
there's 7 from what i saw listed: •Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface). |
| 23:55 |
|
sfisque |
•Spring's HTTP invoker. Spring provides a special remoting strategy which allows for Java serialization via HTTP, supporting any Java interface (just like the RMI invoker). The corresponding support classes are HttpInvokerProxyFactoryBean and HttpInvokerServiceExporter. |
| 23:55 |
|
sfisque |
•Hessian. By using Spring's HessianProxyFactoryBean and the HessianServiceExporter you can transparently expose your services using the lightweight binary HTTP-based protocol provided by Caucho. |
| 23:55 |
|
sfisque |
•Burlap. Burlap is Caucho's XML-based alternative to Hessian. Spring provides support classes such as BurlapProxyFactoryBean and BurlapServiceExporter. |
| 23:55 |
|
sfisque |
•JAX-RPC. Spring provides remoting support for web services via JAX-RPC (J2EE 1.4's web service API). |
| 23:55 |
|
sfisque |
•JAX-WS. Spring provides remoting support for web services via JAX-WS (the successor of JAX-RPC, as introduced in Java EE 5 and Java 6). |
| 23:55 |
|
sfisque |
•JMS. Remoting using JMS as the underlying protocol is supported via the JmsInvokerServiceExporter and JmsInvokerProxyFactoryBean classes. |
| 23:56 |
|
sfisque |
the issue will be , discovering which protocol they have configured their service to use. and then reverse engineering a solution on our side. i'm hoping whichever protocol is used, spring isn't doing any "magic" |
| 23:56 |
|
sfisque |
i'd prefer RMI because that's the most "native" to java and i have a fair amount of xp with it |
| 23:57 |
|
sfisque |
though i have a sneaky suspicion that they have probably leveraged the "spring http invoker" |
| 23:58 |
|
sfisque |
i've never used hessian, and burlap is a "new one" on me |
| 23:58 |
|
sfisque |
i've also used JAX-WS but i doubt the use that one |
| 23:58 |
|
sfisque |
and JMS would be "too tenuous" for this type of service |
