| Time |
S |
Nick |
Message |
| 00:14 |
|
|
dnkstation joined ##javaee |
| 00:23 |
|
|
trollolol joined ##javaee |
| 00:49 |
|
|
cem_ joined ##javaee |
| 00:56 |
|
|
cem_ joined ##javaee |
| 00:56 |
|
cem_ |
konnichiwa sfisque |
| 00:57 |
|
cem_ |
added new feature to the bot . |
| 01:00 |
|
cem_ |
so on uploading file when i usejava.io.tmpdir getting tomcat dir rather wanted system directory how to do it ? |
| 01:23 |
|
cem_ |
anyone uses twitter here |
| 01:23 |
|
cem_ |
?? |
| 01:39 |
|
sfisque |
cem_ in a contained env there are two tmp dirs. there is the one that is jvm level , and the container defines its own tmp dir for things like file upload, serializing objects, etc. |
| 01:42 |
|
cem_ |
sfisque what is the best practise to do , should save in db or tmp folder ? |
| 01:45 |
|
cem_ |
well to define it correctly |
| 01:46 |
|
cem_ |
as a user1 uploads the file , store in tmp folder then do db operation <save> or directly do save ? |
| 01:46 |
|
sfisque |
depends. if you need "query/search/referntial integrity, put it in a db or other artificial repo (ldap, nosql, etc.) otherwise serialize to file is fine. just be warned that file i/o in an EJB is verbotten. use a JCA adapter (there are several that will handle file i/o in a proper transaction) |
| 02:13 |
|
cem_ |
javaeebot`: lucky part |
| 02:13 |
|
javaeebot` |
cem_: http://www.thefreedictionary.com/part |
| 02:13 |
|
cem_ |
javaeebot`: lucky part javaee 7 |
| 02:13 |
|
javaeebot` |
cem_: http://docs.oracle.com/javaee/7/tutorial/doc/ |
| 02:14 |
|
cem_ |
:( |
| 02:32 |
|
cem_ |
how to check the user who is uploading the file is uploaded whole file ? |
| 02:32 |
|
cem_ |
i know manually we can do it |
| 02:39 |
|
sfisque |
is the size of the file sent in the http post payload (i forget if it is) |
| 03:33 |
|
|
cem_ joined ##javaee |
| 03:36 |
|
* cem_ |
the chrome shows how uploading progress |
| 03:36 |
|
* cem_ |
strike how :! |
| 03:38 |
|
cem_ |
apart from type and disposition you dont get anything from part sfisque |
| 03:49 |
|
cem_ |
k found the solution cool! |
| 03:57 |
|
|
[[thufir]] joined ##javaee |
| 04:46 |
|
sfisque |
what was the solution? |
| 05:06 |
|
|
[[thufir]] joined ##javaee |
| 05:10 |
|
cem_ |
there is 2 possiblites either go for frontend aka using jquery or using applet |
| 05:12 |
|
sfisque |
you shouldnt need that. you can check the Content-Length of the "part" in the multipart payload |
| 05:17 |
|
cem_ |
sfisque: since we get request after multipart processing is completed so during the progress |
| 05:18 |
|
sfisque |
oh, you're only interested in the length before the payload is delivered… aka client side. gotcha |
| 05:18 |
|
cem_ |
there is no way to get it as per server side on 3.0 servlet |
| 05:18 |
|
cem_ |
S |
| 05:22 |
|
cem_ |
whole payload is not sent all at once |
| 05:25 |
|
cem_ |
its still client and server |
| 05:29 |
|
sfisque |
if you're encoding is "chunked", each chunk has a byte length that preceeds the chunk payload |
| 05:29 |
|
sfisque |
i'm reading through rfc 2616 now |
| 05:32 |
|
cem_ |
for multipart/form-data its different RFC 2388 |
| 05:39 |
|
cem_ |
i'm going to sleep :) |
| 05:40 |
|
sfisque |
g'nite |
| 05:43 |
|
|
dangertools joined ##javaee |
| 05:43 |
|
|
dangertools joined ##javaee |
| 05:55 |
|
cem_ |
sfisque: what type of thing u have did with servlet and jsp ? <for what all the things you have used> |
| 05:57 |
|
sfisque |
i have not needed to do what you're doing. if you're trying to intercept byte counts from the client stream, you're working in a realm that is proprietary which i tend to avoid if possible. |
| 05:59 |
|
cem_ |
sfisque: what type of requirement you have faced ? |
| 06:00 |
|
cem_ |
can you share with me :) |
| 06:00 |
|
cem_ |
i'll try to do my best |
| 06:02 |
|
cem_ |
if all of you like to share it would be nice |
| 06:04 |
|
cem_ |
i'll see the board ,later bye |
| 07:10 |
|
|
Quest joined ##javaee |
| 07:37 |
|
|
neuro_sys joined ##javaee |
| 09:10 |
|
|
AartBluestoke1 joined ##javaee |
| 09:23 |
|
|
AartBluestoke1 joined ##javaee |
| 09:40 |
|
|
[[thufir]] joined ##javaee |
| 09:44 |
|
|
AartBluestoke1 joined ##javaee |
| 09:53 |
|
|
semiosis joined ##javaee |
| 10:08 |
|
|
AlexCzar joined ##javaee |
| 11:18 |
|
|
drspockbr joined ##javaee |
| 12:13 |
|
|
drspockbr1 joined ##javaee |
| 12:15 |
|
|
drspockbr2 joined ##javaee |
| 12:34 |
|
neuro_sys |
oh man, I wasn't able to pull this off. lol |
| 12:34 |
|
neuro_sys |
http://commons.apache.org/proper/commons-beanutils/apidocs/org/apache/commons/beanutils/converters/AbstractConverter.html |
| 12:58 |
|
|
[[thufir]] joined ##javaee |
| 13:43 |
|
sess |
doing some large design work and would like to get some input: I got an java EE6 application packaged in an EAR that contains a jar with all EJBS, and a WAR with servlets etc. Now we would like to add a web service module that has a dependancy on the EJB JAR. Since JARs in the root of an EAR does not share classloader (in JBoss at least), just adding a new module there wouldn't work. My solution would be to split the EJB jar into ejb-impl a |
| 13:43 |
|
sess |
does that sound solid? |
| 13:43 |
|
sess |
Couldn't think of any other alternative without putting the web service inside the EJB module |
| 13:45 |
|
sess |
wrong channel even, aimed for ##java |
| 13:47 |
|
Quest |
any one used github? |
| 14:06 |
|
|
AlexCzar joined ##javaee |
| 14:12 |
|
pdurbin |
sess: let us know what they say :) |
| 14:15 |
|
|
drspockbr joined ##javaee |
| 14:22 |
|
|
phionov joined ##javaee |
| 14:31 |
|
sess |
no response :( |
| 14:31 |
|
sess |
gonna try it at least |
| 14:36 |
|
|
Naros joined ##javaee |
| 15:25 |
|
|
Naros joined ##javaee |
| 15:43 |
|
|
semiosis joined ##javaee |
| 15:45 |
|
pdurbin |
bah! "No, the <f:viewParam> does not support nor handle a single parameter with multiple values" -- http://stackoverflow.com/questions/17275130/is-there-a-way-to-make-fviewparam-handle-lists-of-values/17276832#17276832 |
| 15:48 |
|
sfisque |
sess, that's close to what i did in the past. i had a stub.jar that had the entities and interfaces, an impl jar that had the real ejbs and a third jar that had webservices that cross called into the ejbs ( stub consumed by both, impl consumed by ws) |
| 15:48 |
|
pdurbin |
I was hoping to do something like this with Solr for facets (multiple "fq" in f:viewParam): fq=type_s%3Atype1&fq=author%3Aauthor1 |
| 15:49 |
|
sfisque |
how is fq defined in the backing bean? |
| 15:49 |
|
pdurbin |
sfisque: <f:viewParam name="fq" value="#{SearchPage.facetQuery}"/> |
| 15:50 |
|
pdurbin |
but technically, I don't think it's a facet query... Solr calls it a filter query, I think |
| 15:50 |
|
sfisque |
no, in the backing bean |
| 15:51 |
|
pdurbin |
sfisque: oh, right now it's just a single value (private String facetQuery) but I'm thinking through how I might want to change it |
| 15:52 |
|
sfisque |
has to be a collection or array |
| 15:52 |
|
sfisque |
if you're multiply referencing |
| 15:52 |
|
pdurbin |
sfisque: sure, on the backing bean side, but viewParam can only have one value, I think |
| 15:53 |
|
pdurbin |
only one value for "fq" I mean |
| 15:53 |
|
sfisque |
i thought you were doing multiple f:vp's… that would necesitate an aggregate to store them in |
| 15:53 |
|
pdurbin |
here. here's a real world Solr URL that has more than one "fq" ... http://localhost:8983/solr/collection1/select?q=*%3A*&fq=type_s%3Adatasets&fq=authorstring_s%3A%22Dr.+Sparrow%22&wt=json&indent=true&facet=true |
| 15:54 |
|
pdurbin |
if that helps :) |
| 15:54 |
|
sess |
sfisque: it's very hard to separate an API module this late though |
| 15:54 |
|
sess |
because the API has so much ties to the implementation |
| 15:55 |
|
sfisque |
ah, so you cannot modify the underlying bean? |
| 15:55 |
|
pdurbin |
sfisque: underlying? you must be talking to sess |
| 15:55 |
|
sfisque |
oh, yeah, mixed up convos' in my head.. sry |
| 15:56 |
|
sess |
sfisque: I can modify anything |
| 15:56 |
|
sess |
but there is a large EJB module |
| 15:56 |
|
sfisque |
pdurbin >>> god |
| 15:56 |
|
sfisque |
:P |
| 15:56 |
|
sess |
if you split it into impl and API, you still need access to a lot of classes from both modules |
| 15:56 |
|
pdurbin |
? :) |
| 15:56 |
|
sess |
which would have to be moved |
| 15:56 |
|
sfisque |
prove it… modify the dna of that squirrel over there.... |
| 15:56 |
|
* sfisque |
points to a defenseless squirrel |
| 15:57 |
|
|
tangatools joined ##javaee |
| 15:58 |
|
|
tangatools joined ##javaee |
| 16:19 |
|
|
neilus joined ##javaee |
| 16:19 |
|
|
sheenobu joined ##javaee |
| 16:21 |
|
|
tangatools joined ##javaee |
| 16:21 |
|
|
Naros joined ##javaee |
| 16:21 |
|
|
drspockbr joined ##javaee |
| 16:21 |
|
|
AartBluestoke1 joined ##javaee |
| 16:21 |
|
|
rektide_ joined ##javaee |
| 16:21 |
|
|
whartung joined ##javaee |
| 16:21 |
|
|
oO0Oo- joined ##javaee |
| 16:21 |
|
|
kinabalu joined ##javaee |
| 16:21 |
|
|
Fubar^ joined ##javaee |
| 16:21 |
|
|
javaeebot` joined ##javaee |
| 16:21 |
|
|
SoniEx2 joined ##javaee |
| 16:21 |
|
|
sfisque joined ##javaee |
| 16:21 |
|
|
book` joined ##javaee |
| 16:21 |
|
|
Bombe joined ##javaee |
| 16:21 |
|
|
sess joined ##javaee |
| 16:21 |
|
|
balo joined ##javaee |
| 16:21 |
|
|
acuzio joined ##javaee |
| 16:21 |
|
|
liecno joined ##javaee |
| 16:21 |
|
|
Lappro joined ##javaee |
| 16:21 |
|
|
balazare joined ##javaee |
| 16:21 |
|
|
wicketn01b joined ##javaee |
| 16:21 |
|
|
ibaca joined ##javaee |
| 16:21 |
|
|
ChanServ joined ##javaee |
| 16:22 |
|
|
sheenobu joined ##javaee |
| 16:26 |
|
|
rektide joined ##javaee |
| 16:28 |
|
|
pdurbin joined ##javaee |
| 16:36 |
|
|
neilus joined ##javaee |
| 16:44 |
|
|
rektide joined ##javaee |
| 16:49 |
|
pdurbin |
hmm, I got disconnected |
| 16:50 |
|
pdurbin |
I was trying to say that in this non-JSF app you can have "key_f" in the URL as many times as you want: http://labs.adsabs.harvard.edu/adsabs/search/?q=*&key_f=atmosphere&key_f=plasmas&key_f=waves |
| 16:50 |
|
pdurbin |
I'm assuming key_f is for "keywords facet" |
| 17:10 |
|
pdurbin |
what I'm going for here is bookmarkable search URLs |
| 17:50 |
|
sfisque |
how so? if you're calling against the interfaces and you have the pojos in hand, why would you need to directly reference the impl? that's the whole point of ejb. impls get proxied via the interfaces. |
| 17:51 |
|
sfisque |
that was for sess |
| 17:54 |
|
whartung |
I got to dabble with my first "no interface" session bean this weekend |
| 17:54 |
|
sfisque |
fun! |
| 17:55 |
|
sfisque |
good for code consolodation, bad for separating api from impl |
| 17:55 |
|
whartung |
yea, it was nice. |
| 17:55 |
|
whartung |
yup |
| 17:57 |
|
whartung |
I liked having the session bean as part of the war |
| 18:12 |
|
sfisque |
aye for a small app, it's a nice convenience. |
| 18:13 |
|
whartung |
my first attempt at CDI even worked \o/ |
| 18:13 |
|
sfisque |
:-) |
| 18:13 |
|
whartung |
and it worked in Stripes, the web framework I use (after plugging in a small extension) |
| 18:14 |
|
whartung |
so I was able to Inject a simple bean that had an EJB reference to a my no-interface EJB…and the container FELL FOR IT!! |
| 18:14 |
|
sfisque |
be aware though, that you lose "true clustering" with the non-interface bean (no remote exposure) |
| 18:14 |
|
sfisque |
lolz |
| 18:15 |
|
sfisque |
aka, each container's pool of those beans are local only and cannot be shared via rmi |
| 18:18 |
|
whartung |
yup -- I'll risk it sfisque :) |
| 18:18 |
|
sfisque |
:-) |
| 18:18 |
|
|
AlexCzar joined ##javaee |
| 18:21 |
|
|
Quest joined ##javaee |
| 18:21 |
|
Quest |
any one used github with idea? |
| 18:27 |
|
|
slpetroff joined ##javaee |
| 18:33 |
|
semiosis |
Quest: regularly |
| 18:33 |
|
semiosis |
works just like any other remote git repo in idea |
| 18:35 |
|
Quest |
good to hear. you use IDE tools to commit, checkout etc/ |
| 18:35 |
|
Quest |
? |
| 18:36 |
|
Quest |
it seems that at the first when I try to upload my project with option VCS > import into version control > share project on github. it creats the repo on the git hub (cross checked on website) but then it says "push failed: fatal: repository 'https://github.com/username/ttmaven.git/' not found" semiosis |
| 18:37 |
|
semiosis |
i never use idea to create a new git repo. i always init & set remote with the git cli |
| 18:37 |
|
semiosis |
so i just use idea for clone, push/pull, commit, branch, and merge |
| 18:37 |
|
semiosis |
and fetch |
| 18:38 |
|
semiosis |
also stash, cherry pick, log review, ... |
| 18:38 |
|
semiosis |
ok so lots, but never init |
| 18:40 |
|
Quest |
semiosis, ok, after you create an empty repo on github and init it locally. how do you push the premade project files to that remote repo? |
| 18:40 |
|
Quest |
I mean by the idea |
| 18:42 |
|
semiosis |
git remote add origin <url>; git push origin master |
| 18:43 |
|
Quest |
git init, git remote add origin url . thats understandable by cli but after that how to push the project files by the IDE idea? |
| 18:44 |
|
semiosis |
Quest: one of two ways... when you are committing in idea, hover over the commit button, choose commit & push... this brings up the push dialog. or if you already have commits that you have not pushed, you can just choose Push from the VCS menu |
| 18:45 |
|
semiosis |
http://www.jetbrains.com/idea/webhelp/git-push-dialog.html |
| 18:46 |
|
Quest |
ok, what should be the very next step after git init, git remote add origin url . |
| 18:49 |
|
Quest |
No tracked branch configured for branch master. To make your branch track a remote branch call, for example, git branch --set-upstream master origin/master |
| 18:49 |
|
|
neuro_sys joined ##javaee |
| 18:49 |
|
|
neuro_sys joined ##javaee |
| 18:53 |
|
semiosis |
i just gave that to you! |
| 18:53 |
|
semiosis |
git remote add origin <url>; git push origin master |
| 18:54 |
|
semiosis |
or theres a checkbox in the idea push dialog |
| 18:54 |
|
semiosis |
or idk |
| 18:55 |
|
Quest |
yes, it says push current branch to alternative branch. origin / master. theres not other checkbox in git>push dialog |
| 18:55 |
|
Quest |
and when I push , it says nothing to push |
| 18:58 |
|
semiosis |
sorry this is way beyond the scope of just using idea. sorry i'm too busy to teach you git right now. there are lots of good refs on the web |
| 18:58 |
|
semiosis |
maybe someone else can help |
| 18:58 |
|
pdurbin |
and there's #git |
| 18:58 |
|
Quest |
no problem! |
| 18:59 |
|
Quest |
ya. cli git is ok to me but not with idea |
| 19:10 |
|
pdurbin |
huh. so with JAX-RS you can definitely use the same parameter... "list" appears 3 times: http://example.com/services/echo?list=Hello&list=Stay&list=Goodbye ... example from http://stackoverflow.com/questions/13750010/jersey-client-how-to-add-a-list-as-query-parameter/13750116#13750116 |
| 19:13 |
|
pdurbin |
I tested it and it works just fine: @QueryParam("list") final List<String> inputList |
| 19:24 |
|
whartung |
grr -- can't put an MDB in JEE lite |
| 19:24 |
|
sfisque |
sigh |
| 19:25 |
|
sfisque |
war packaging is not EE-Lite |
| 19:25 |
|
sfisque |
EE-Lite is a container spec |
| 19:25 |
|
sfisque |
not a bundling spec |
| 19:25 |
|
whartung |
ooh -- so maybe I can put an MDB in a war |
| 19:25 |
|
sfisque |
no you cant |
| 19:25 |
|
whartung |
you just like to tease me |
| 19:25 |
|
sfisque |
reduced packaging doesnt give you everything |
| 19:26 |
|
sfisque |
it gives you "enough" to be dangerous |
| 19:26 |
|
sfisque |
one sec |
| 19:26 |
|
sfisque |
javaeebot lucky java ee spec ejb 3.1 reduced packaging |
| 19:26 |
|
whartung |
"no" |
| 19:26 |
|
whartung |
lol |
| 19:26 |
|
sfisque |
oh it's renamed? |
| 19:27 |
|
sfisque |
i missed that memo |
| 19:27 |
|
whartung |
javaeebpt` ? |
| 19:27 |
|
whartung |
javaeebot` |
| 19:27 |
|
sfisque |
javaeebot` lucky java ee spec ejb 3.1 reduced packaging |
| 19:27 |
|
javaeebot` |
sfisque: http://www.oracle.com/technetwork/articles/javaee/javaee6overview-part3-139660.html |
| 19:27 |
|
whartung |
yea, that's what I'm looking at |
| 19:28 |
|
sfisque |
simplified packaging |
| 19:28 |
|
sfisque |
is their name for it |
| 19:28 |
|
whartung |
yea |
| 19:28 |
|
sfisque |
in the actual pdf of the spec, they list the differences between "ear" deploy and "war" deploy |
| 19:28 |
|
sfisque |
in a handy chart |
| 19:29 |
|
sfisque |
iirc, mdb's are lost, in addition to a few other things (no remote interfaces) |
| 19:29 |
|
sfisque |
i think timers are lost too |
| 19:29 |
|
whartung |
yea, no mobs, no remotes, no timers |
| 19:29 |
|
whartung |
mobs were the Big Bummer to me |
| 19:30 |
|
sfisque |
havent dabbled too much with mdbs, but i like my timers and @Asynch |
| 19:30 |
|
whartung |
really? MDBs are the bomp |
| 19:30 |
|
sfisque |
i'm sure they are, just havent had a big need for them yet |
| 19:30 |
|
whartung |
you may use Asynch for some of that |
| 19:31 |
|
sfisque |
everyone uses json over web now instead of messaging…. blech |
| 19:32 |
|
whartung |
well, to be honest, that's not awful -- it's clever in its way. |
| 19:32 |
|
whartung |
One example is Google App Engines messaging service |
| 19:32 |
|
whartung |
you basically just send it a URL to "subscribe" |
| 19:32 |
|
whartung |
and it POST messages to it |
| 19:32 |
|
whartung |
then, there's another URL you POST to to queue the messages |
| 19:32 |
|
whartung |
so, all you have to write are web endpoints |
| 19:33 |
|
whartung |
amazon has a similar service |
| 19:33 |
|
sfisque |
aye but how does that work if you want to do messaging "inside" your cloud and not on the public pipelines |
| 19:33 |
|
whartung |
oh sure, I was simply pointing out the idiom. |
| 19:34 |
|
whartung |
OpenMQ has a HTTP interface as well, so do most of the dominant queues me thinks |
| 19:34 |
|
whartung |
I could just have a native JSM client living in a thread. |
| 19:34 |
|
sfisque |
aye and REST and blah blah blah. i'm still hunting for an MQ that has an IRC bridge/gateway. you'd think someone in the last 20 years would have solved that problem |
| 19:35 |
|
whartung |
Camel doesn't have an IRC bridge? |
| 19:35 |
|
sfisque |
camel is not an MQ it's just a rule processor |
| 19:35 |
|
whartung |
no, but you could stick an IRC endpoint on to a pipeline fed by a queue…same thing. |
| 19:36 |
|
whartung |
"cloes enough" |
| 19:36 |
|
whartung |
assuming you're already using it, that is |
| 19:36 |
|
sfisque |
not atm. i'm trying to keep this thing lean, i dont want to just haphazardly throw techs and libs at it |
| 19:36 |
|
whartung |
yup |
| 19:36 |
|
sfisque |
very little "gee whiz" in this thing so far |
| 19:36 |
|
sfisque |
except for primefaces :-) |
| 19:38 |
|
whartung |
where the JCA IRC connector! :) |
| 19:55 |
|
|
[[thufir]] joined ##javaee |
| 20:09 |
|
|
cem_ joined ##javaee |
| 20:14 |
|
cem_ |
hello Quest san |
| 20:14 |
|
cem_ |
can i pm you |
| 20:14 |
|
cem_ |
? |
| 20:40 |
|
sess |
sfisque: the thing is, most objects are in the EJBmodule, including parameters and return values, it's not just pure EJBs |
| 20:41 |
|
sess |
in the end, we kept the service layer as a single module and included the whole thing, apparently EJBs in the lib folder does not deploy |
| 20:41 |
|
sess |
which is a good thing |
| 20:50 |
|
sfisque |
right sess, but you can have one ejb module consume another at build time, and then drop them both into the ear. you can have N many ejb modules in an ear, just like you can have N many war files bundled |
| 20:51 |
|
sess |
I dont see how having multiple jars in the ear would help me |
| 20:51 |
|
sess |
regardless, I got a decent solution in the end |
| 20:52 |
|
sess |
the stub variant would be fine IF the domain objects were seperated from the service layer, which they aren't |
| 20:55 |
|
|
trollolol joined ##javaee |
| 20:56 |
|
sfisque |
i guess the real question is, what problem are you trying to solve? |
| 20:57 |
|
Quest |
cem_, sure |
| 21:02 |
|
sess |
sfisque: seperating web service logic from the rest of the application without making the seperated parts too bloated |
| 21:03 |
|
sfisque |
bundled inside same ear or outside? |
| 21:03 |
|
sess |
both options are acceptable |
| 21:04 |
|
sfisque |
using jax-ws or another impl? |
| 21:04 |
|
sess |
jax-ws |
| 21:04 |
|
sess |
or well, whatever jboss uses, which I think is jax-ws |
| 21:05 |
|
sess |
JBossWS, jax-ws is an api of course |
| 21:05 |
|
sfisque |
you should be able to just bundle up the ejb's that are annotated as webservices into their own jar. as long as they're inside the same ear, they should be able to consume all the bits they need. (all containers implement jax-ws, but there are other api/impls like axis, etc.) |
| 21:06 |
|
sess |
sfisque: jars inside EARs in jboss does not share class loader by default |
| 21:06 |
|
sess |
and I'm reluctant to enable that, felt like a dirty fix |
| 21:07 |
|
sfisque |
that sounds like a bug, imo. which version of jboss? that would defeat the whole purpose of bundling into an ear |
| 21:07 |
|
sess |
otherwise, that was the absolute first idea I had and the first thing I tried |
| 21:07 |
|
sess |
sfisque: you're perhaps thinking of library folders in EARs |
| 21:07 |
|
sess |
rather than top level jars |
| 21:08 |
|
sfisque |
unless the different classloaders were federated so resources are shared |
| 21:08 |
|
sfisque |
no, that sounds totally like a bug |
| 21:08 |
|
sess |
https://docs.jboss.org/author/display/AS72/Class+Loading+in+AS7 |
| 21:08 |
|
sess |
it's clearly intended |
| 21:08 |
|
sess |
Ear deployments are multi-module deployments. This means that not all classes inside an ear will necessarily have access to all other classes in the ear, unless explicit dependencies have been defined |
| 21:08 |
|
sess |
perhaps it can be defined in some configuration file that jar x should get access to jar y though |
| 21:09 |
|
sess |
EAR class loading contains the interesting parts |
| 21:10 |
|
sess |
I was afraid that the service layer would get access to the web layer if the flag mentioned was set, though I read now that the WAR file is always in its own CL |
| 21:10 |
|
sess |
so in my case it would be fine really i guess |
| 21:12 |
|
sfisque |
sometimes i think the jboss team is bipolar. their solution to the "everything on the same classloader" in 4.x and back is to now put everything on individual CL's. begs the question of WTF is an ear for then? |
| 21:12 |
|
sfisque |
might as well just deploy everythying separate |
| 21:12 |
|
sess |
the EAR modules shares the same lib folder at least |
| 21:12 |
|
sess |
but yeah it's a bit confusing |
| 21:12 |
|
|
weyer joined ##javaee |
| 21:13 |
|
sfisque |
meaningless. any well designed Eapp is going to consume mostly what the container provides. |
| 21:13 |
|
sess |
this is better than the old jboss versions at least, I've actually managed to switch from OC4J to Jboss 7 without a SINGLE class conflict |
| 21:13 |
|
sfisque |
either natively or via osgi/jca |
| 21:14 |
|
sfisque |
dropping crap in the /lib dir is a war hack because servlet containers provide almost nothing |
| 21:14 |
|
sess |
hack? Where would you put common dependencies otherwise? |
| 21:15 |
|
sess |
I assume you mean the deployed EAR lib folder, not the application server lib folder |
| 21:16 |
|
sfisque |
both. depending on the deployment fabric (very few apps are going to co-exist in the same container these days for scalability issues) no one wants to tune inter-app conflicts for resources when you're clustering dozens or more containers |
| 21:17 |
|
sfisque |
so all the inter deps are going to be within the same app structure anyway |
| 21:18 |
|
sfisque |
i'm seeing more and more of the 1 app / 1 container (or less if its clustered 1/n) |
| 21:19 |
|
sess |
we go for the 1 container, ALL THE APPS route |
| 21:19 |
|
sess |
because HP support costs too much :D |
| 21:19 |
|
sfisque |
ouchie |
| 21:19 |
|
sfisque |
you running websphere on HP (guessing) |
| 21:20 |
|
sfisque |
or have they finally entered the econtainer fray? |
| 21:20 |
|
sess |
nah, Jboss 5 |
| 21:20 |
|
sess |
..EAP |
| 21:20 |
|
sess |
used to be jboss 4 community |
| 21:20 |
|
sfisque |
5 was a nice upgrade to 4.2. |
| 21:20 |
|
sfisque |
almost all of my apps were drop in ready |
| 21:21 |
|
sess |
the upgrade took us like 9 months |
| 21:21 |
|
sfisque |
i'm finding 7.1 has some….. wrinkles |
| 21:21 |
|
sess |
mostly due to issues with an IBM plugin that we "needed" that it turned out we didn't need.. |
| 21:21 |
|
whartung |
we do several apps per server |
| 21:21 |
|
sfisque |
and i'm hoping wildfly is just a drop in upgrade from 7.1 |
| 21:21 |
|
sess |
should have just gotten jboss 7 while we were at it |
| 21:22 |
|
sfisque |
where i'm at currently they deploy 1 app / tomcat and we're 1 app / N glassfish cluster |
| 21:22 |
|
sess |
as long as large frameworks in the container are used, drop in upgrade will most likely not worked |
| 21:22 |
|
sess |
switching major versions of hibernate servlet versions has issues sometimes |
| 21:23 |
|
sfisque |
our product is the "black sheep" because we chose glassfish rather than doing spring on tomcat |
| 21:23 |
|
whartung |
heresy |
| 21:24 |
|
sess |
lol glassfish in production |
| 21:24 |
|
sfisque |
the way i like it! |
| 21:24 |
|
sess |
worst decision I ever made |
| 21:24 |
|
sess |
or well not made by me |
| 21:24 |
|
sess |
it was the only java EE 6 container that existed by the time one of my projects started |
| 21:24 |
|
sfisque |
GF has been fine, excepting that our NOC are completely EE noobz |
| 21:24 |
|
sfisque |
if it's not tomcat, they blow a fuse or two during deployments or troubleshooting |
| 21:25 |
|
sfisque |
and dont get me started on the "wonderful" spring code that we get out of our offshore teams |
| 21:25 |
|
sess |
offshore produces the best code! |
| 21:25 |
|
sfisque |
23458304583053058 interfaces |
| 21:25 |
|
whartung |
what problems did you have sess ? |
| 21:25 |
|
sfisque |
oh sorry, 823453953 interfraces and 234583058 abstract classes |
| 21:26 |
|
sess |
whartung: it did a lot of random weird stuff causing it to crash |
| 21:26 |
|
sess |
granted, i was a rookie at that time |
| 21:26 |
|
sess |
the config ui was instable as hell aswell |
| 21:26 |
|
sfisque |
config ui in GF? |
| 21:26 |
|
sess |
sfisque: we used to handle our applications production deployment until it got outsourced to india and HP |
| 21:27 |
|
sess |
we'd do it in 20 minutes |
| 21:27 |
|
sess |
they take like 4 hours |
| 21:27 |
|
sess |
and fail mostly |
| 21:27 |
|
sfisque |
yah that sounds about what we see ehre |
| 21:27 |
|
sfisque |
***here |
| 21:27 |
|
sess |
im not quite sure why people that have no idea about out application should handle the deployments... and even the sql scripts they want to handle aswell |
| 21:28 |
|
sfisque |
if we dont give them slides on how to deploy datasources (jdbc/jms/etc.) it's like showing a dog a card trick |
| 21:28 |
|
sess |
a missing ; somewhere, and they return it, crying |
| 21:28 |
|
whartung |
we have our own deployment system works pretty well |
| 21:28 |
|
whartung |
one thing we also have is our own SQL manager subsystem |
| 21:28 |
|
sess |
once they opened an sql script in the wrong encoding |
| 21:28 |
|
whartung |
each apps updates its own DB on deploy |
| 21:28 |
|
sess |
and blamed us in front of the customer :/ |
| 21:28 |
|
sfisque |
ouchies |
| 21:29 |
|
sfisque |
wipro? |
| 21:29 |
|
sfisque |
:P |
| 21:29 |
|
whartung |
wipro? |
| 21:29 |
|
sfisque |
a notorious indian outsource house |
| 21:29 |
|
whartung |
o |
| 21:29 |
|
sfisque |
lets just say, questionable ethics |
| 21:29 |
|
whartung |
not if you're Indian :) |
| 21:29 |
|
whartung |
it's funny |
| 21:30 |
|
sfisque |
no i mean they get slapped often for "bad stuff" |
| 21:30 |
|
sfisque |
well, i guess, over there, they're probably heros |
| 21:30 |
|
whartung |
whenever i hear an Indian anecdote, we get "Not sure if others experience the same thing or not", and of course all of these anecdotes are the same |
| 21:31 |
|
sfisque |
though not specific to any region, i do have an adage that i offer up on the subject… if you pay high school wages, you get high school code |
| 21:31 |
|
sfisque |
doesnt matter if it's alabama, russia, or whereever |
| 21:33 |
|
whartung |
shouldn't matter what you pay them. If they agree to do the work for the price quoted, they should do the work. |
| 21:34 |
|
whartung |
the whole "but I only get paid X" attitude is plain wrong. |
| 21:39 |
|
sfisque |
the price isnt really driven by that.. it's the same as offshoring fabrics or assembly-line. price of local economy. sometimes i actually lament choosing enterprise java as a niche. i should have gone embedded. less outsourcing of that |
| 21:40 |
|
sfisque |
but i made my bed and now i have to compete in an industry where there are devs who make as little as 1/10 what we're paid here in ameria |
| 21:40 |
|
whartung |
yea |
| 21:40 |
|
sfisque |
**america |
| 21:40 |
|
whartung |
you need to switch your expertise to bailing out companies who pay 1/10th the going rate to get their systems developed :D |
| 21:41 |
|
sfisque |
that's pretty much what my career has become :P |
| 21:42 |
|
sfisque |
but the heroic 60hr work weeks only hold water when you're 25 and single :-/ |
| 21:43 |
|
sfisque |
ah so jboss 7+ has this: |
| 21:43 |
|
sfisque |
<subsystem xmlns="urn:jboss:domain:ee:1.0" > |
| 21:43 |
|
sfisque |
<ear-subdeployments-isolated>false</ear-subdeployments-isolated> |
| 21:43 |
|
sfisque |
</subsystem> |
| 21:43 |
|
sfisque |
so you can have a shared CL inside an er |
| 21:43 |
|
sfisque |
**ear |
| 21:43 |
|
whartung |
"shared CL"? |
| 21:44 |
|
sfisque |
and you can also register dependencies in the manifest: |
| 21:44 |
|
sfisque |
Portability |
| 21:44 |
|
sfisque |
The Java EE specification says that portable applications should not rely on sub deployments having access to other sub deployments unless an explicit Class-Path entry is set in the MANIFEST.MF. So portable applications should always use Class-Path entry to explicitly state their dependencies. |
| 21:44 |
|
sfisque |
which has been around for sometime and isnt new |
| 21:45 |
|
sfisque |
shared classloader. instead of one CL per jar, you can tell the deployer framework to setup dependency visibility i guess |
| 21:45 |
|
sfisque |
using that xml stub |
| 21:45 |
|
sfisque |
sort of a hybrid of what jboss 4.x did. |
| 21:50 |
|
whartung |
yea |
| 21:50 |
|
whartung |
gf has a flat CL for the entire EAR (for good and evil) |
| 21:50 |
|
sfisque |
aye |
| 21:50 |
|
sess |
sfisque: yeah I was pondering using that flag |
| 21:50 |
|
sess |
im not sure if it's recommended or not |
| 21:51 |
|
whartung |
IMHO, that's a hole in the spec. That the containers can "use what they like" as far as the CL hierarchy is concerned. definitely portability issues there |
| 21:53 |
|
sfisque |
i guess the concept is, you have no guarantee that the ear is going to reside in the same jvm. from what i've read, the container is free to bootstrap however it wants, so you "could" get a container that has 1 jvm for the EJB container, 1 for the servlet container, and 1 for jca adapters |
| 21:53 |
|
sfisque |
since it's "not specified" you can't assume it, even though in practice, it's pretty much all one jvm |
| 21:54 |
|
sess |
lazy spec is lazy |
| 21:54 |
|
sfisque |
gnu is not unix |
| 21:54 |
|
sfisque |
or rather gnu's not unix |
| 21:54 |
|
whartung |
it most certainly is not |
| 21:54 |
|
sfisque |
>.< |
| 21:55 |
|
whartung |
I should just go over to OpenBSD and live off of fork(2) and fifo(3) |
| 21:56 |
|
sfisque |
its a shame C cant be wired up with reflection. would be interesting to have EEContainers where you can deploy apps/libs written in C/C++ |
| 21:57 |
|
whartung |
Obj-C yo |
| 21:57 |
|
whartung |
\o/ |
| 21:57 |
|
whartung |
the point is |
| 21:57 |
|
sfisque |
does OC have instrumentation to effect runtime reflection |
| 21:57 |
|
whartung |
just use the f'n OS |
| 21:58 |
|
whartung |
you processes as you abstraction |
| 21:58 |
|
sfisque |
but but but but WORM |
| 21:58 |
|
sfisque |
;-D |
| 21:58 |
|
whartung |
WORM? |
| 21:58 |
|
sfisque |
Write Once Run Many |
| 21:58 |
|
sfisque |
that was the java mantra in the mid 90's |
| 21:58 |
|
whartung |
oh, yes |
| 21:58 |
|
sfisque |
or WORA sometimes |
| 21:58 |
|
sfisque |
write once run anywhere |
| 21:59 |
|
whartung |
no, the ONE thing Java has got right, the ONE thing folks that don't use it do not appreciate, is that we are the ONE eco system that actually CAN distribute binaries without tearing our hair out. |
| 21:59 |
|
sfisque |
true |
| 22:00 |
|
whartung |
I swear nobody has reusability like we do. CPAN is a cruel hoax. |
| 22:00 |
|
sfisque |
though we have the same issues as C. just moved the problem. instead of "which libs in /usr/lib" we have "which version of jvm" |
| 22:00 |
|
sfisque |
writing ansi-C is like writing java 1.2 |
| 22:00 |
|
whartung |
yes, it relies on the JVM being ported. The version, eh, less so. Only recently has versioning started to become an issue |
| 22:00 |
|
sfisque |
oh contrare |
| 22:01 |
|
semiosis |
pdurbin: whartung called CPAN a cruel hoax! |
| 22:01 |
|
sess |
id rather upgrade 1 VM than 100 libs |
| 22:01 |
|
sfisque |
1.0 -> 1.1 broke all sorts of crap. same for 1.1 -> 1.2 |
| 22:01 |
|
sfisque |
1.3 -> 1.4 was painless |
| 22:02 |
|
whartung |
yea, but it's been pretty darn stable since 1.3 |
| 22:02 |
|
sfisque |
it's gotten "better" with each release as far as backward compat. if you draw a line at 1.3 |
| 22:02 |
|
whartung |
they learned at 1.2 that breaking old stuff sucks for folks who actually spend money on this stuff. |
| 22:02 |
|
semiosis |
whartung: on that note, i cant understand all the crap people give maven. it blows every other dependency manager out of the water, and does lots of other useful stuff on top of that |
| 22:02 |
|
sfisque |
aye that |
| 22:03 |
|
whartung |
I agree semiosis ( O.O ) my primary complaint on maven is it's black magic. But all dependency managers suffer a poisoned dependency pool. |
| 22:04 |
|
pdurbin |
whartung: I'll deal with you later. (thanks, semiosis) |
| 22:04 |
|
semiosis |
hahaha |
| 22:05 |
|
whartung |
I went and fetched wget for my MacPorts the other day. The number of dependencies it had were legion. One of them, for some awful rason, was perl5. I need Perl 5 to get wget (!!!) "Thanks a lot" |
| 22:05 |
|
sfisque |
my only real complaint with maven is you have to build your sandbox "their way" or you spend untold hours reconfiguring (aka it's hard to move an existing project onto maven unless you get lucky and its already laid out that way). other than that, it's pretty neat. |
| 22:05 |
|
sess |
that's the main strength of maven |
| 22:05 |
|
sess |
having the same layout in all projects is great |
| 22:06 |
|
sfisque |
unless your project is doing funky stuff during build time. for boilerplate, it's awesome |
| 22:06 |
|
semiosis |
the first year i worked with maven i wondered what they meant by "software comprehension" |
| 22:06 |
|
sess |
it's also good because it prevents you from doing funky stuff :) |
| 22:06 |
|
whartung |
maven's double benefit today is universal IDE project file |
| 22:06 |
|
sfisque |
tell that to the sales guys who sell this stuff with "bonus work" |
| 22:06 |
|
sess |
oh god yes |
| 22:06 |
|
sess |
instant generated project file |
| 22:07 |
|
sess |
with all libs correctly setup, and sources downloaded with 1 click |
| 22:07 |
|
cem_ |
Quest san disappeared |
| 22:07 |
|
sfisque |
he's been very "in/out" lately, from what i've seen |
| 22:09 |
|
cem_ |
what is difference in perl and perl 6 channel ? other then version |
| 22:09 |
|
sfisque |
perl 6 is a major rewrite, no? |
| 22:09 |
|
whartung |
perl channel is for people trying to actually get work done |
| 22:09 |
|
sfisque |
ROFL |
| 22:10 |
|
sfisque |
has 6 actually debuted? i know it got pushed back a bajillion times |
| 22:10 |
|
sfisque |
javaeebot` lucky perl 6 release |
| 22:10 |
|
javaeebot` |
sfisque: http://www.perl6.org/archive/faq.html |
| 22:11 |
|
sfisque |
man perl 6 has been baking for over a decade, i think |
| 22:11 |
|
whartung |
yup |
| 22:11 |
|
sfisque |
it's the duke nukem of development |
| 22:11 |
|
sfisque |
:P |
| 22:16 |
|
|
sess joined ##javaee |
| 22:55 |
|
cem_ |
u ppl are really awesome :D |
| 22:59 |
|
whartung |
no, just me. |
| 23:03 |
|
sfisque |
\o/ |
| 23:28 |
|
sfisque |
i wish netbeans had a rar/sar project type, so that i didnt have to twiddle the ant script |
| 23:30 |
|
pdurbin |
oh. sorry about the javaeebot` rename. it must have gotten disconnected |
| 23:30 |
|
semiosis |
javaeebot`: reconnect |
| 23:30 |
|
javaeebot` |
semiosis: Error: "reconnect" is not a valid command. |
| 23:30 |
|
semiosis |
meh |
| 23:31 |
|
pdurbin |
there |
| 23:35 |
|
* sfisque |
smacks javaeebot around the head and shoulders |
| 23:36 |
|
pdurbin |
heh. glassfish in production FTW |
| 23:42 |
|
pdurbin |
I dunno, I still say Perl and CPAN is just fine. Oh, and Perl 6 runs on the JVM now: http://irclog.perlgeek.de/perl6/2013-11-03#i_7806041 |
| 23:42 |
|
* whartung |
hates our core library |
| 23:42 |
|
whartung |
do nothing war is 37M |
| 23:42 |
|
sfisque |
36mb of spring interfaces and 1mb of xml? |
| 23:42 |
|
sfisque |
:P |
| 23:43 |
|
whartung |
every time I've had to get something from CPAN, something, somewhere, gets completely horked -- converting from "oh boy! a package I can use" "I give up, I don't need to know this much perl" |
| 23:44 |
|
whartung |
let's learn the inner delicacies and intricacies of the "easy to use" dependency manager... |
| 23:45 |
|
whartung |
"oh, and don't forget, you need to compile all of the crap in C…we use libC_xyz_123.a.qed…what do you use?" |
| 23:45 |
|
* whartung |
slams head on desk |
| 23:53 |
|
|
weyer joined ##javaee |
| 23:54 |
|
sfisque |
anyone have good or bad things to say about using pircbot as the core of a JCA irc adapter? |
| 23:54 |
|
whartung |
no, don't know anything about it |
| 23:54 |
|
sfisque |
it seems very clean and lean as far as API is concerned |
