Time |
S |
Nick |
Message |
00:56 |
|
|
Maziz joined ##javaee |
00:58 |
|
|
sfisque joined ##javaee |
01:01 |
|
|
sfisque1 joined ##javaee |
03:57 |
|
|
caverman joined ##javaee |
05:21 |
|
|
SoniEx2|2 joined ##javaee |
07:19 |
|
|
neuro_sys joined ##javaee |
07:26 |
|
|
neuro_sys joined ##javaee |
07:30 |
|
|
neuro_sys joined ##javaee |
07:31 |
|
|
caverdude joined ##javaee |
08:06 |
|
|
bSchoeck joined ##javaee |
08:08 |
|
|
bSchoeck left ##javaee |
08:09 |
|
|
bSchoeck joined ##javaee |
08:10 |
|
|
dreamworker joined ##javaee |
08:10 |
|
dreamworker |
Hi |
08:18 |
|
|
dreamworker_ joined ##javaee |
08:19 |
|
|
Quest joined ##javaee |
08:21 |
|
|
SoniEx2|2 joined ##javaee |
08:23 |
|
|
SoniEx2|3 joined ##javaee |
09:45 |
|
onr |
Java 8 |
10:22 |
|
pdurbin |
oh good: https://twitter.com/arungupta/status/359958938726313984 |
12:22 |
|
|
amitev joined ##javaee |
12:22 |
|
|
amitev left ##javaee |
13:29 |
|
|
Naros joined ##javaee |
14:27 |
|
|
kobain joined ##javaee |
15:00 |
|
|
Quest joined ##javaee |
16:03 |
|
|
caverdude joined ##javaee |
17:28 |
|
Quest |
hi, any person that used plain java ee 6 / latest ? to do all that is done in spring / struts/ other frameworks? |
17:28 |
|
whartung |
huh? |
17:29 |
|
sfisque1 |
that's our entire product. zero spring |
17:29 |
|
sfisque1 |
all EE6 |
17:29 |
|
Quest |
sfisque1, wow |
17:29 |
|
whartung |
I've been doing this for 12 years, I've never used spring. |
17:29 |
|
sfisque1 |
well, there is "some" spring but that's because camel comes with all sorts of baggae |
17:29 |
|
sfisque1 |
***baggage |
17:29 |
|
Quest |
whartung, wow.......... |
17:30 |
|
whartung |
yea who knew you actually CAN use this stuff out of the box... |
17:30 |
|
Quest |
people mostly say me that the latest java ee 6 is modern and not old legacy problematic anymore. and the same things can be done with javaee that could be done with spring or struts |
17:30 |
|
sfisque1 |
lol W |
17:31 |
|
Quest |
you agree ^? |
17:31 |
|
sfisque1 |
TBH, there is nothing outdated about EE. the only thing that EE6 brings is annotations and injection. other than that, it's the same facilities that have been in play in form or another over the last 14 years |
17:31 |
|
whartung |
yea |
17:31 |
|
Quest |
sfisque1, well the old versions got people away and afraid. I think you were the person who said that earlier |
17:31 |
|
whartung |
it adds some deployment options |
17:32 |
|
sfisque1 |
aye Q. pre- EE5, EE suffered "xml hell", similar to what spring suffers now |
17:32 |
|
sfisque1 |
or XMhelL |
17:33 |
|
sfisque1 |
:P |
17:33 |
|
Quest |
whartung, sfisque1 so how do you do all that , that is done in spring, spring mvc, spring AOP (most important), and spring security in java ee? you would have to use some persistnatce framework like hibernate in either spring or javaee though. |
17:33 |
|
Quest |
sfisque, xml hell? you mean lack of annotations? |
17:33 |
|
whartung |
JEE5 + comes with a JPA implementation |
17:33 |
|
sfisque |
u use whatever the container gives you and u just target the APIs |
17:34 |
|
Quest |
whartung, jpa implementation. what kind of? whats the name? |
17:34 |
|
whartung |
the difference between ejb2 and ejb3 are mostly the addition of annotations which reduced the XML considerably and the addition of JPA |
17:34 |
|
sfisque |
i mean you had to configure EVERYTHING via XML and it was voluminous. with EE5 we got the double bang of annotation + configuration via convention |
17:34 |
|
whartung |
with the addition of JPA, Entity Beans were deprecated |
17:34 |
|
Quest |
sfisque, oh |
17:35 |
|
whartung |
Glassfish uses Eclipselink. JBoss uses Hibernate I imagine. |
17:35 |
|
sfisque |
yup |
17:35 |
|
Quest |
what different is the javaee implementation of JPA than from hibernate? |
17:35 |
|
whartung |
Weblogic uses Eclipselink (since it's oracle) |
17:35 |
|
whartung |
dunno was websphere uses |
17:35 |
|
sfisque |
websphere uses eclipselink but can support hibernate |
17:35 |
|
whartung |
ok |
17:36 |
|
sfisque |
glassfish can support hibernate as well, via osgi bundle |
17:36 |
|
sfisque |
from my experience in V4 and V5, jboss was (is?) pretty much married to hibernate |
17:36 |
|
Naros |
Hibernate just provides you with a more feature rich set of APIs than JPA. |
17:36 |
|
sfisque |
dunno if they fixed that in 6/7 |
17:37 |
|
Naros |
You can do the same in both, but sometimes Hibernate offers you extensions not found in JPA |
17:37 |
|
whartung |
yea, we use Eclipselink specific stuff in our code. |
17:37 |
|
sfisque |
aye but if you start down that route, you're polluting the code with driver specific dependencies |
17:37 |
|
whartung |
yup |
17:37 |
|
whartung |
don't care :) |
17:37 |
|
whartung |
we never have had much interest in porting our apps off of Glassfish |
17:38 |
|
whartung |
and nowadays with most of our installs being VMs, it's even less important. |
17:38 |
|
sfisque |
lol. aye, just saying for Q's benefit. obviously, if you are making a deliberate decisiion, one hopes it's well justified :=D |
17:38 |
|
Naros |
Ofc. |
17:38 |
|
whartung |
we mostly use it for the Criteria api, because we're on JPA 1, and don't have JPA's Criteria API. But after looking at it, I like Els better anyway |
17:38 |
|
sfisque |
as for entity beans being deprecated, i missed that meeting, when did that happen? |
17:39 |
|
Quest |
Naros, oh so we dont need any framework like hibernate in a Java EE ? |
17:39 |
|
sfisque |
oh, yah JPA2 is a world of improvement |
17:39 |
|
sfisque |
get moved upto GF 3.x (or 4) if you can |
17:40 |
|
whartung |
they're actually optional in the latests release I believe, and by deprecated I mean they were discouraged. I don't think anyone would consciously choose an EB over a JPA Entity unless forced to. |
17:40 |
|
whartung |
yea, we're moving to 3 as we speak have one project already moved |
17:40 |
|
sfisque |
negative Q, you just don't "write against it". you write against JPA and the pPersistenceContext loads the driver that is registered in the EAR/Container (hibernate, eclipselink, etc.) |
17:40 |
|
whartung |
when the rest move up, we'll start playing with JPA 2 |
17:40 |
|
Quest |
sfisque, polluting? so there might be migration issues? |
17:40 |
|
sfisque |
so you are still "using" the ORM, but hyou're using not "wired to it" if you use the JPA api |
17:40 |
|
sfisque |
yes Q |
17:42 |
|
Naros |
That's why we use the entity manager provided by JPA and just allow the ORM to sit behind the EM |
17:42 |
|
sfisque |
you will like JPA2 W. it's very nice. though be careful of edge cases. i found out that eclipselink has a NASTY copy/paste bug in it's coalesce() method |
17:42 |
|
Naros |
that way if we have special need cases to use the ORM's API we can, but we often prefer the JPA API |
17:43 |
|
Naros |
Also just as an FYI Quest. IIRC, Hibernate 4.3 is moving to JPA 2.1. |
17:44 |
|
sfisque |
well, i gotta bounce. TT y'all L8r. code strong! |
17:44 |
|
Naros |
likewise, lunch time. |
18:08 |
|
|
Quest joined ##javaee |
18:08 |
|
|
caverdude joined ##javaee |
18:10 |
|
Quest |
whartung, Naros so how do you do all that , that is done in spring, spring mvc, spring AOP (most important), and spring security in java ee? you would have to use some persistnatce framework like hibernate in either spring or javaee though. |
18:11 |
|
Quest |
are there built in things in javaee or it would be the old fashioned way? |
18:11 |
|
onr |
bana java ogretin kitapsizlar |
19:09 |
|
Naros |
Quest: My focus isn't solely JavaEE. My area of expertise is with those frameworks because that is the environment I've been exposed to and develop within for the last 13 years. |
19:10 |
|
Naros |
So how to do things without Spring, MVC, AOP, Spring Security in a pure JavaEE world isn't something I can help you with because it isn't a world I live and breath daily. |
19:10 |
|
Quest |
hm |
19:11 |
|
Quest |
but as far as i see, to accomplish those, theres not prebuilt machnism in javaee. you have to reinvent the wheel? |
19:11 |
|
Quest |
brb |
19:11 |
|
Quest |
I wonder what whartung had to say about it. (if he is not busy) |
19:12 |
|
Naros |
It's much like in the C++... The argument to use boost, versus the c++ stdlib, versus rolling your own. |
19:13 |
|
Naros |
*C++ World |
19:18 |
|
* Quest |
have no idea abou tc++ |
19:19 |
|
Quest |
Naros, by the way, have you used spring security? |
19:19 |
|
Naros |
Yes, we use it heavily |
19:19 |
|
Quest |
would it be not difficult for you to copy paste me the config? |
19:20 |
|
Quest |
assumed that the auth is through database |
19:21 |
|
Naros |
Our app uses a two-way authentication scheme. |
19:21 |
|
Quest |
hm |
19:21 |
|
Quest |
want to share what kind of? |
19:21 |
|
Naros |
Validates username from DB, if user is flagged as LDAP then credentials are authenticated via Active Directory, otherwise it proceeds with a DB password encryption validation. |
19:22 |
|
Naros |
Because our users can be both NT domain users and non-NT domain users. |
19:22 |
|
Quest |
hm. then that config would be of less use to me as it would go over my head |
19:22 |
|
Naros |
The basics are the same. |
19:22 |
|
Naros |
let me see what i can paste. |
19:23 |
|
Quest |
I think http://www.mkyong.com/spring-security/spring-security-form-login-using-database/ would be fine for basic auth. |
19:23 |
|
Quest |
Naros, ok |
19:28 |
|
Naros |
if you aren't using LDAP tho, you may need to tweak |
19:28 |
|
Quest |
ok |
19:29 |
|
Naros |
http://pastebin.com/JnvDfamF |
19:30 |
|
Naros |
The idea is we define some http patterns and specify their security level requirements. In those cases, none since they're considered public. Anything else would fall into requiring authentication. |
19:30 |
|
Naros |
you can ignore the app event listener. we did that for some special tracking of application events for login/logout. |
19:31 |
|
Naros |
Since we use a custom form, we defined a login form filter and entry point. |
19:33 |
|
Naros |
be aware, this config is a bit messy mainly because it's been a work-in-progress from an older version of Spring Security to 3.1.3 where things were shifted around and some old things were left behind (hence why you see a intercept-url patterns similar to the first set of security http patterns). |
19:33 |
|
Naros |
I'd advise you to take this as a grain of salt and follow the config docs |
19:34 |
|
Quest |
which part goes to the database, matches the username against password ? |
19:35 |
|
Naros |
That's the authenticationService bean |
19:35 |
|
Naros |
UserDetailsAuthenticationService extends AbstractUserDetailsAuthenticationProvider |
19:36 |
|
Naros |
iirc, it calls retrieveUser(String userName, UsernamePasswordAuthenticationToken authentication) |
19:36 |
|
Naros |
that is where we hook into the API and load our user by the username. |
19:37 |
|
Naros |
Once you return a UserDetails object, it then invokes the additionalAuthenciationChecks method on the provider's interface. |
19:37 |
|
Quest |
so a class would have to be made named UserDetailsAuthenticationService extends AbstractUserDetailsAuthenticationProvider |
19:37 |
|
Naros |
Yes. |
19:37 |
|
Naros |
If you wish to use some custom form of authentication. |
19:38 |
|
Naros |
there are other ways you can do it however. |
19:38 |
|
Naros |
but i found this to be the most flexible given our business needs. |
19:38 |
|
Quest |
i just have two column in a table named login and pass |
19:39 |
|
Naros |
tell me your pass is encrypted ? :P |
19:39 |
|
Quest |
not for the moment |
19:39 |
|
Quest |
nor hashed |
19:39 |
|
Quest |
but it might in future |
19:39 |
|
Naros |
yah definitely want to hash it. We use an SHA algorithm iirc. |
19:40 |
|
Quest |
i hope it would be refactored very easily, but for the moment just need it to work |
19:41 |
|
Naros |
yah that can be easily done later once the basics work :P |
19:41 |
|
Quest |
hm |
19:41 |
|
Quest |
so I create a class name UserDetailsAuthenticationService extends AbstractUserDetailsAuthenticationProvider |
19:41 |
|
Quest |
do you have that class already to be able be pasted? |
19:41 |
|
Naros |
http://static.springsource.org/spring-security/site/docs/3.1.x/apidocs/org/springframework/security/authentication/dao/AbstractUserDetailsAuthenticationProvider.html |
19:42 |
|
Naros |
No I cannot paste that class, sorry. |
19:42 |
|
Naros |
Just implement that interface I pasted you |
19:43 |
|
Naros |
er extend that abstract class i meant. |
19:43 |
|
Quest |
ok. |
19:43 |
|
Naros |
You could probably extend AuthenticationProvider or DaoAuthenticationProvider. |
19:43 |
|
Quest |
Naros, is that secret ! :) |
19:44 |
|
Naros |
That class has client-specific information which is under a NDA contract. |
19:46 |
|
Quest |
oh |
19:46 |
|
Quest |
so i can either extend AbstractUserDetailsAuthenticationProvider or AuthenticationProvider or DaoAuthenticationProvider. |
19:47 |
|
Naros |
Yep, read the docs and decide what makes most sense for your case. |
19:47 |
|
Quest |
okie dokie |
20:02 |
|
|
caverdude joined ##javaee |
20:03 |
|
|
Quest joined ##javaee |
20:05 |
|
Guest43761 |
<Quest> thanks for being so elaborative. point a person in the correct direction |
20:05 |
|
Guest43761 |
<Quest> pointing* |
20:05 |
|
Guest43761 |
<Quest> Naros, so its final that if i intend to use db auths. i only can use these three classes ? AbstractUserDetailsAuthenticationProvider or AuthenticationProvider or DaoAuthenticationProvider. |
20:05 |
|
Guest43761 |
<Quest> there are no other ways? (other than hard coding passwords which i wont do) |
20:05 |
|
Guest43761 |
<Quest> Naros, and I need to use security:authentication-provider. thats it. |
20:07 |
|
Naros |
1 moment, trying to resolve a DB crash i caused :P |
20:08 |
|
Naros |
sigh lets hope recovery works :E |
20:08 |
|
Guest43761 |
sure. |
20:09 |
|
Naros |
Without consulting the docs for later versions, I can't specifically how to configure your scenario, but yes you need an authentication provider for sure. But which you plan to extend is entirely up to you. |
20:10 |
|
Guest43761 |
hm |
20:10 |
|
Guest43761 |
I see there are alot. even on is UserDetailsService interface |
20:11 |
|
Guest43761 |
one* |
20:11 |
|
Guest43761 |
hm. i would catch up docs from here. thanks |
20:11 |
|
Naros |
yes there is the user details service too |
20:12 |
|
Naros |
But we only use that during a user-switch |
20:12 |
|
Guest43761 |
k |
20:12 |
|
Naros |
user-switch being where an admin can transparently convert their session to a user session without a password to debug/troubleshoot a problem that is user-specific. |
20:13 |
|
Naros |
a different user's session more explicitly. |
20:14 |
|
Guest43761 |
in my case i would surely want the admin to see all logged in users and expel any |
20:16 |
|
Naros |
no, what i mean is I can login as my user, go to the user administration console, select a user record and then select an option to make the application think I that user I selected in the admin console. |
20:16 |
|
Guest43761 |
oh |
20:16 |
|
Naros |
Then I can do a transaction and see where it fails for a different user without them needing to give me their password. |
20:17 |
|
Guest43761 |
in my case, the user would be just a user. even the admins. its the other privilieges in my tables that tells what the user is. i mean for the spring authen part. i would set up all as same. and deal the authoriz part by my custom way. |
20:18 |
|
Naros |
The beauty is spring security comes with this feature and the context management stores both the original user (the admin's data) and the switch user (the new user's data). When I exit Incognito mode, it restores the security context back to the admin's data and dumps the user's data I had previously been acting as. |
20:18 |
|
Guest43761 |
hm |
20:19 |
|
Naros |
right, just commenting on the fact that spring security allows a user to login as another user without their credentials if you need or want that feature. |
20:21 |
|
Naros |
We've worked around a lot of that need by having our requests store a transaction context where everything that happens is audited and when a failure point happens, users can contact helpdesk, the admin can select the session and view the last audit transaction trace in real time to see where the failure point is. |
20:21 |
|
|
SoniEx2|2 joined ##javaee |
20:23 |
|
Guest43761 |
hm |
20:23 |
|
Guest43761 |
nice! |
20:31 |
|
onr |
java vs php, which is better for web dev? |
20:32 |
|
Naros |
Depends on the project |
20:32 |
|
onr |
middle sized |
20:32 |
|
Naros |
that's not sufficient details. what type of project? What are it's needs? |
20:33 |
|
onr |
say twitter clone without scaling, data processing, etc. tasks |
20:33 |
|
Naros |
well, facebook's UI is PHP with a bunch of C/C++ backend |
20:33 |
|
onr |
yeah PHP is a powerful template language |
20:34 |
|
onr |
important info: for single-man band |
20:35 |
|
Naros |
Both can do a lot of the same things with enough time put into how things get architected. Is this for some uni / personal project or corporate work? |
20:35 |
|
|
sfisque joined ##javaee |
20:35 |
|
onr |
no in fact i'm looking for a go-to web development platform to learn |
20:36 |
|
onr |
i'll do stupid simple SQL backed CRUD web apps |
20:36 |
|
onr |
and it seems without knowing Java or PHP, i'll starve to death |
20:36 |
|
onr |
i've yet to see any python/ruby job around here, for example |
20:37 |
|
sfisque |
if all you want is a editor with decent java support, jEdit. if you want a real platform, then it's kind of "to taste" between idea, netbeans, and eclipse |
20:37 |
|
onr |
i've asked for java vs php, sfisque |
20:37 |
|
Naros |
if you want to learn something that has a lot of market value, then java imo. |
20:37 |
|
onr |
i'm kinda vim guy |
20:38 |
|
sfisque |
php will get you lots of grunt work jobs. EEJava will get you more headache and more money :P |
20:38 |
|
sfisque |
if you want opportunity, learn either android or iOS |
20:38 |
|
Naros |
but when i want to do quick and dirty stuff, i'll often favor php because it's easy |
20:39 |
|
sfisque |
well yah. its perl. no brainer there |
20:39 |
|
Naros |
exactly |
20:39 |
|
sfisque |
i still use perl often here and our project is pure JEE |
20:39 |
|
sfisque |
it's nice for doing forensics on log files |
20:40 |
|
sfisque |
or fast preflighting "uplaod files" for testing that facility |
20:40 |
|
onr |
i thought Java folks completely abandoned PHP |
20:42 |
|
onr |
so i assume Java doesn't provide quickie web microframework like PHP |
20:42 |
|
Naros |
Just because we use java doesn't mean we don't use other avenues when it makes more sense |
20:43 |
|
Naros |
I'm a framework kinda guy, so there is a bit of upfront configs I have to do to get even a quickie web app up and going in java that under php, it's usually just about creating the code and dropping it into my apache web server :P |
20:44 |
|
sfisque |
thats why i have boiler plate war/ear projects in my local cvs repo. checkout read only, make a few mods, import as new project |
20:45 |
|
onr |
true, almost anything other than PHP requires some amount of boilerplate code |
20:45 |
|
sfisque |
though, netbeans has kind of obsoleted them for the most part |
20:45 |
|
onr |
unfortunately, PHP is such a horrible language |
20:45 |
|
sfisque |
you can say, New Project, build, and deploy in under a minute with netbeans |
20:46 |
|
sfisque |
it's not that bad onr, but it suffers the same issue as JSP. you can do very bad things in the representation layer ... |
20:46 |
|
Naros |
horrible in what way? That's quite subjective imo. |
20:51 |
|
onr |
i *like* PHP's environment. there are situations where MVC is plain verbose and PHP-esque files-as-routes and business logic embedded in HTML is okay |
20:51 |
|
onr |
PHP-the-language isn't my type unfortunately |
20:51 |
|
onr |
anyway, i need to force myself to learn some popular server-side languages to find jobs |
20:51 |
|
* Guest43761 |
suggest a framework even php is used |
20:56 |
|
onr |
i already like most things i know about Java |
20:56 |
|
onr |
JVM, lots of learning material and job opportunities, being static typed and IDE support |
20:56 |
|
Naros |
my fav part of Java is the garbage collector :P |
20:57 |
|
* whartung |
loves JSP -- best page templating system on the market. |
20:57 |
|
onr |
but people say Java is too much for a single developer |
20:57 |
|
Naros |
O.o |
20:57 |
|
onr |
and there are thousands of concepts |
20:58 |
|
Naros |
There are tons of concepts in any language :) |
20:58 |
|
onr |
well, for example Servlet |
20:59 |
|
Naros |
Beauty is they often have similarities even across language barriers. That's why they're design patterns and such. |
20:59 |
|
onr |
isn't this just a damn HTTP handler class? |
20:59 |
|
sfisque |
yes and no |
20:59 |
|
Naros |
It depends (tm) :P |
20:59 |
|
onr |
heh |
20:59 |
|
sfisque |
HttpServlet is, Servlet is generic |
20:59 |
|
whartung |
yet not generic enough :) |
20:59 |
|
* Naros |
cries. |
20:59 |
|
sfisque |
servlet can be a SOAP endpoint, for example |
21:00 |
|
sfisque |
or a JSON REST endpont |
21:00 |
|
onr |
is it something like gen_server in Erlang, or specific to client/server paradigm in networking? |
21:00 |
|
sfisque |
not sure and no, respectively |
21:01 |
|
whartung |
not knowing anything about gen_server, can't comment |
21:01 |
|
sfisque |
it's a generic "request oriented connection" abstraction, with HttpServlet providing the concrete version for handling http requests |
21:02 |
|
|
Maziz joined ##javaee |
21:02 |
|
onr |
for example, can you use Servlet for, say, in-memory data store 'server'? |
21:03 |
|
onr |
protocol-agnostic server, i mean. not limited to TCP |
21:03 |
|
whartung |
the power of the servlet is two fold. 1) it's simple (really simple) binding et al. but the winner is 2) the forwarding mechanism that lets you invoke other resources (notably JSPs, but can be anything) internally, making it easy to separate responsibilities |
21:03 |
|
Guest43761 |
onr, in short. java is more of an enterprise medium to enterprise best suited thing. php is for small to medium (not scalable to high enterprise) thing |
21:03 |
|
onr |
ah, it exactly like gen_Server, i see |
21:04 |
|
onr |
"servlets can respond to any types of requests" |
21:04 |
|
whartung |
yea, php is only good for things like Facebook... |
21:04 |
|
whartung |
servlets aren't that generic |
21:04 |
|
whartung |
for example |
21:04 |
|
whartung |
you wouldn't write an SMTP server using Servlets |
21:04 |
|
onr |
hmm |
21:05 |
|
whartung |
I think the original vision was to be able to do something like that ,but HTTP is too leaky at the server level, it never panned out |
21:05 |
|
whartung |
that's what I meant by Servlets not being generic enough |
21:06 |
|
onr |
i see. still i'm glad it's not specifically designed & named for HTTP servers |
21:06 |
|
sfisque |
well yah, SMTP is an event driven service, not a request driven one |
21:06 |
|
whartung |
but it effectively is |
21:07 |
|
Naros |
it is request driven and has a finite state machine just like HTTP |
21:07 |
|
sfisque |
do you even know how smtp works? |
21:07 |
|
whartung |
but none of the servrs I know, especially out of the box, would actually accept such a socket and call your "Servlet". They all have the HTTP processing built in at the connector level. |
21:08 |
|
Naros |
sfisque: me? |
21:08 |
|
whartung |
you certainly can't implement a Servlet in a WAR and have it work. |
21:08 |
|
* whartung |
has written an SMTP server |
21:08 |
|
Naros |
As have I, in various languages. |
21:08 |
|
sfisque |
if you remember how Servlet evolved, it was a messy refactor from the original spec to what we have now. and it shows unfortunately |
21:09 |
|
whartung |
I could write code with jars that leveraged, say, the Grizzly Connectors in Glassfish, but it would be a GF artifact and not related to JEE at all |
21:09 |
|
whartung |
yea, it's messy. It's a shame, it would have been nice to be able to do an SMTP Servlet. |
21:09 |
|
sfisque |
that would be messy |
21:12 |
|
onr |
if SMTP doesn't fit into request/response paradigm, then there must be "event server" class in Java |
21:13 |
|
whartung |
HTTP is stateless and doesn't require a persistent connection. SMTP does. |
21:13 |
|
whartung |
that's the detail that moves it out of the "request/response" category. It's a conversation in contrast to HTTP. |
21:14 |
|
whartung |
That all said, I WRAPPED my SMTP server in to a servlet, but I use it as a skeleton for its lifecycle to stand up and tear down the SMTP server with our app. |
21:14 |
|
whartung |
but other than that, it just opens sockets on its own |
21:17 |
|
sfisque |
now what would be interesting would be to have a "container compatible" analog to ServerSocket, for cases where Servlet does not map well (like say, an SNMP endpoint, or similar) rather than having to go the CORBA/RMI route and build a tenuous pipe between the container and the external process |
21:18 |
|
whartung |
right. JEE punts on this with the JCA where it's point of integration is just a Message Bean. |
21:18 |
|
whartung |
but the module does all of the work. |
21:19 |
|
whartung |
I originally wrote the SMTP server as a JCA module, but it was a pain and couldn't call our server logic very easily. |
21:19 |
|
sfisque |
JCA's point of integration is the JNDI and JTA. you "can" also use MDB but that's not specifically part of the spec |
21:19 |
|
whartung |
I did't want the MDB process to be that raw. |
21:19 |
|
whartung |
well, that's how the payload gets in to the server, at least for this use case. |
21:20 |
|
whartung |
most examples of JCA are for external connectors (i.e. JDBC-esque) rather than listeners. |
21:20 |
|
sfisque |
the JCA adapter can expose whatever interface it wants, as long as it adheres to the JTA and JNDI expectations |
21:20 |
|
whartung |
but listeners interact with the JEE tier through a message bean |
21:20 |
|
sfisque |
aye |
21:21 |
|
onr |
heh. see how many Java terms you're using? :) |
21:21 |
|
whartung |
it's a JEE channel, you need to be pretty deep in java to play here. |
21:21 |
|
sfisque |
well yah, you're talking about a platform that spans 18 years in the SE and 14 in the EE world |
21:21 |
|
whartung |
and we're mostly using JEE terms, not Java terms per se, to be pedantic |
21:22 |
|
sfisque |
that's a billion years in internet time |
21:22 |
|
onr |
btw, did you know someone who had no clue about Java, then learnt it? |
21:23 |
|
whartung |
me |
21:23 |
|
onr |
curious how long it took to be 'productive' in Java. (consider i'm a CRUD web app guy) |
21:23 |
|
whartung |
hell, I didn't even know "web" hardly at all when I started it. |
21:24 |
|
whartung |
well, not true, I wrote an apache mod. |
21:24 |
|
whartung |
so I knew HTTP ok |
21:24 |
|
whartung |
but I couldn't spell java. |
21:24 |
|
sfisque |
i picked up java in about 6 mo using the 0.90b compiler and the first edition of "java in a nutshell". with the explosion of tutorials and tools these days, you can reach "productive" in about 3-4 months |
21:24 |
|
whartung |
yea |
21:24 |
|
whartung |
especially if you just focus on one aspect |
21:24 |
|
onr |
wow 6 months |
21:25 |
|
whartung |
the biggest problem with java is that it's very (VERY) easy to get distracted and go off in to the weeds |
21:25 |
|
sfisque |
all i had was BBEdit, the compiler, and nutshell |
21:25 |
|
sfisque |
kids these days are spoiled.... *wanders off to find his missing cane* |
21:25 |
|
whartung |
I suggest you write your more horrible PHP style code in Java/JSPs to get familiar with it, then move forward from there once you're comfortable with the syntax, build and deploy process and runtime. |
21:25 |
|
whartung |
heh |
21:26 |
|
whartung |
My first production system was on JRun :) |
21:26 |
|
whartung |
well, lies, it was actually on netscape. |
21:26 |
|
whartung |
then it locked up hard one day |
21:26 |
|
whartung |
and support didn't get back to me |
21:26 |
|
whartung |
so Iported it to JRun |
21:27 |
|
onr |
even 3-4 months sound surprising because it took me a week to learn Go and start to write web services |
21:27 |
|
sfisque |
there is a difference between, i made it work, and i'm productive |
21:27 |
|
whartung |
and actually understand and supporting what you did |
21:27 |
|
onr |
i can say i'm productive and not using any magic framework |
21:28 |
|
whartung |
then you should be able to pick up servlets in no time |
21:28 |
|
whartung |
Servlet != JEE |
21:29 |
|
onr |
yeah. i'll also need to grasp DB connectivity |
21:29 |
|
onr |
JDBC, i guess |
21:29 |
|
whartung |
yup |
21:29 |
|
whartung |
use a connection pool |
21:29 |
|
whartung |
and look it up using JNDI |
21:29 |
|
whartung |
yes, there are other ways |
21:29 |
|
whartung |
don't use them. |
21:29 |
|
whartung |
use the connection pool |
21:30 |
|
onr |
sure thing |
21:30 |
|
sfisque |
now there's a tech that suffers lack of knowledge. too many "java ee" engineers today have no idea how JNDI works.... /cries |
21:30 |
|
whartung |
heh |
21:30 |
|
whartung |
we use it all the time but so rarely at the same time. |
21:30 |
|
sfisque |
all they know is @EJB and @Inject and have no clue what's actually happening under the hood |
21:31 |
|
whartung |
yea |
21:31 |
|
pdurbin |
some of us are still only students of java ee :) |
21:31 |
|
whartung |
we're all students of JEE |
21:32 |
|
whartung |
it's deep and broad |
21:32 |
|
sfisque |
aye |
21:32 |
|
pdurbin |
yep |
21:32 |
|
sfisque |
i still learn new crap all the time, even after 14 years |
21:32 |
|
whartung |
si |
21:32 |
|
whartung |
I have no experience with the JEE6 stuff (CDI notably) for example |
21:32 |
|
whartung |
and I think EJB-Lite is one of the best things since sliced bread. |
21:33 |
|
whartung |
even though I can't use it :) |
21:33 |
|
sfisque |
cdi is a convenience. learn how to look stuff up in jndi. you'll be happy you did |
21:33 |
|
sfisque |
ejb-lite is only a container spec. as far as being a developer, it's unimportant except when you're choosing a container |
21:34 |
|
whartung |
sure, but it's a nice spec. |
21:34 |
|
whartung |
EJBS in your Wars -- EZ mode. So nice. |
21:34 |
|
whartung |
free transactions -- hurray |
21:34 |
|
sfisque |
that's diffrent. you're confusing "war packaging" with ejb-lite |
21:35 |
|
sfisque |
or "simplified packaging" |
21:35 |
|
whartung |
EJB lite is war packaging |
21:35 |
|
sfisque |
i had this conversation with a colleague recently |
21:35 |
|
sfisque |
ejb-lite is a container spec. |
21:35 |
|
whartung |
no, that web profile |
21:35 |
|
whartung |
that's different |
21:35 |
|
sfisque |
reduced packaging is the rules for bundling in a war |
21:35 |
|
sfisque |
one sec |
21:35 |
|
sfisque |
i have the white papers here on my drive |
21:39 |
|
sfisque |
JSR 318 - chapter 20 - Packaging |
21:39 |
|
sfisque |
JSR 310 - chapter 21.1 - EJB Lite |
21:39 |
|
sfisque |
***318 |
21:40 |
|
sfisque |
i had this very conversation a few weeks ago with a colleague here. |
21:40 |
|
whartung |
yea I guess you can have a container that JUST implements EJB-Lite |
21:40 |
|
sfisque |
aye. primarily defined for "embedded" container type situations |
21:41 |
|
sfisque |
but ejb-lite is a container spec. bundling ejb's in a war file is called something else, iirc, "reduced packaging" or "simplified packaging" or somesuch |
21:50 |
|
onr |
can Java SE guys develop web apps as well? |
21:50 |
|
sfisque |
yes, but you're still using EE api's. you can use EE Api's "individually" without the whole platform (Tomcat is a good example) |
21:51 |
|
sfisque |
JDBC, JNDI, JavaMail are other examples of EE api's that can "stand alone" |
21:52 |
|
pdurbin |
plenty of non-EE ways too, I suspect |
21:52 |
|
onr |
well, monster standard libraries basically warm me up :) |
21:52 |
|
whartung |
java se can host web services natively and has an in built http server -- it's awful, but it's there |
21:52 |
|
sfisque |
aye. if you "really really really" wanted to, you could write CGI's in java |
21:53 |
|
sfisque |
which then means all you're doing is writing CLI apps and having httpd call them |
21:53 |
|
onr |
java's startup time is horrible |
21:53 |
|
sfisque |
agreed. hench why i said "really really really" :P |
21:53 |
|
onr |
still, i'll start with such programs first |
21:54 |
|
sfisque |
that's one of the reasons the servlet spec was devloped. to create the concept of "always on" cgi's\ |
21:54 |
|
sfisque |
a servlet is basically just a cgi that never exits |
21:54 |
|
sfisque |
so you don't pay the "startup cost" on each invocation |
21:54 |
|
onr |
um, you write to stdout? |
21:55 |
|
sfisque |
no, but servlets do write to a "stream" |
21:55 |
|
onr |
pretty similar |
21:55 |
|
sfisque |
which the container either sends over the wire or to the fronting httpd |
21:55 |
|
sfisque |
aye |
21:56 |
|
whartung |
it's a little different |
21:56 |
|
whartung |
you don't have to write out the headrs |
21:56 |
|
whartung |
servlet api does that for you |
21:56 |
|
whartung |
just the content |
21:56 |
|
onr |
i hated node.js/python/etc.'s 'whole app in a single thread' perspective |
21:56 |
|
whartung |
INTERNET SKALEZ YO! |
21:56 |
|
sfisque |
aye, but you "can" do header rewriting for specific cases, but yes, the API solves alot of stuff "for you" |
21:56 |
|
onr |
i'll need to write to header anyways, for user auth |
21:56 |
|
onr |
cookies, etc |
21:57 |
|
sfisque |
look at JAAS. all the servet/ee containers support it |
21:57 |
|
onr |
i'm the happiest person when you put request object and write stream in my hands |
21:57 |
|
sfisque |
in fact, tomcat comes with a few jaas drivers |
21:57 |
|
sfisque |
so does jboss (my fave atm) |
21:57 |
|
whartung |
or punt on JAAS and do by hand with a filter :) |
21:58 |
|
sfisque |
aye |
21:58 |
|
onr |
well, my user auth needs are just placing an encrypted cookie in user's browser |
21:58 |
|
onr |
no need to read another 700-page book for this :) |
21:58 |
|
sfisque |
read up on session-fixation. storing cookies for auth can open you up for that attack vector (as well as others) |
21:59 |
|
sfisque |
bbiab |
22:00 |
|
onr |
so you guys know about Java EE |
22:00 |
|
whartung |
the servlet api manages sessions for you |
22:00 |
|
onr |
do you use it with other JVM languages? |
22:00 |
|
whartung |
I don't, well, javascript |
22:00 |
|
onr |
Rhino? |
22:00 |
|
whartung |
but that's more internal |
22:00 |
|
whartung |
yea |
22:01 |
|
onr |
i'm looking at Clojure |
22:01 |
|
whartung |
and Drools Rule language |
22:01 |
|
whartung |
for their rule engine |
22:01 |
|
whartung |
knock yourself out ;) |
22:15 |
|
|
malaverdiere joined ##javaee |
22:16 |
|
malaverdiere |
Hello *. I am having some trouble with a simple jaxb unmarshalling :( |
22:17 |
|
malaverdiere |
I am trying to read the JAX-WS Handlers file. I used xjc to generate classes, and I am reading using the JAXB object. But I get handler-chains whose elements are always null... what am I doing wrong? |
22:22 |
|
pdurbin |
malaverdiere: showing us some code would be appreciated |
22:23 |
|
malaverdiere |
val handlerFile = new File(f.getParent,file) |
22:23 |
|
malaverdiere |
if (handlerFile.exists()){ |
22:23 |
|
malaverdiere |
val unmarshalled = JAXB.unmarshal(handlerFile, classOf[HandlerChainsType]) |
22:23 |
|
malaverdiere |
disapointingly simple, isn't it ;) |
22:25 |
|
sfisque |
are you using @Webservice anntotated endpoint? |
22:25 |
|
malaverdiere |
I get a non-null object, but the handlerchain and id properties are null |
22:25 |
|
sfisque |
if so, it should be doing the marshall/unmarshall for you |
22:25 |
|
malaverdiere |
Actually, I am writing a static analysis engine for JEE |
22:25 |
|
whartung |
sounds like raw JAXB to me |
22:26 |
|
sfisque |
oh, gotcha. outside of my knowledge then |
22:26 |
|
malaverdiere |
So I need to parse the handler chain config file |
22:26 |
|
malaverdiere |
So I tried with jaxb |
22:26 |
|
malaverdiere |
but I don't know what I'm doing wrong |
22:27 |
|
sfisque |
assuming the config file is XML, you should be able to deserialize the file using xmlbeans, no? |
22:27 |
|
malaverdiere |
sfisque: I could. I thought that xjc and xmlbeans were more or less the same at this point :) |
22:27 |
|
sfisque |
not sure. i've not done anythign with xjc directly |
22:28 |
|
sfisque |
worse case, you could leverage apache digester and slurp the xml and deserialize that way |
22:28 |
|
sfisque |
i did that for a templating engine i wrote years ago |
22:29 |
|
sfisque |
but i'm not sure if that would solve the specific problem you're addressing |
22:30 |
|
malaverdiere |
doesn't hurt to look at it |
22:30 |
|
malaverdiere |
I feel like I'm doing a real n00b error somehow |
22:30 |
|
malaverdiere |
anyways, thanks guys |
22:32 |
|
onr |
you're welcome :) |
23:12 |
|
|
malaverdiere joined ##javaee |
23:21 |
|
|
SoniEx2|2 joined ##javaee |