jBoss noob questions
January 12, 2007 10:22 AM Subscribe
My new boss is suggesting we transition the current homebrewed corporate intranet to jBoss. Help.
Okay, new platform, no problem. But I have no experience with jBoss and haven't programmed anything in Java in many years. I've been programming corporate applications and intranets for about 10 years now. Mostly PHP, asp, C++. I'm ready to jump in enthusiastically. Hopefully jBoss users here have some suggestions for jumping into that world with a minimum of pain.
There are some hints that we'll be using portlets rather than handcoding things as we have in the past. This has me a bit worried in that it implies he thinks we won't need coders when there's a portlet for everything. We currently have about 30 mini-apps we've built for various departments, and we add more on a regular basis. Is jBoss+portlets the sort of thing where coders aren't needed as much?
Any suggestions and advice on getting up to speed quickly on this would be very helpful. Thank you.
Okay, new platform, no problem. But I have no experience with jBoss and haven't programmed anything in Java in many years. I've been programming corporate applications and intranets for about 10 years now. Mostly PHP, asp, C++. I'm ready to jump in enthusiastically. Hopefully jBoss users here have some suggestions for jumping into that world with a minimum of pain.
There are some hints that we'll be using portlets rather than handcoding things as we have in the past. This has me a bit worried in that it implies he thinks we won't need coders when there's a portlet for everything. We currently have about 30 mini-apps we've built for various departments, and we add more on a regular basis. Is jBoss+portlets the sort of thing where coders aren't needed as much?
Any suggestions and advice on getting up to speed quickly on this would be very helpful. Thank you.
Best answer: i would suggest you do the following:
1. get back up to speed in java. i would suggest using Eclipse for your IDE. install the JBoss IDE for Eclipse when you want to start working with jboss. jboss is going to make you use all java or java-derived technologies, all the time.
2. learn to write JSP pages for Tomcat, as Tomcat is one of the technologies embedded in jboss.
3. learn XML, if you haven't already.
4. learn about how the Model-View-Controller (MVC) design pattern works, if you haven't already. (scriptlets bad, tag libraries good!)
5. learn about the relevant bits of the J2EE platform work - particularly EJBs.
5a. if you're working with databases, learn Hibernate.
6. learn about how jboss has implemented the J2EE 'standard'.
jboss is extraordinarily powerful and quite complex application server. it has many, many things plugged into it and if you tried to learn them all at once, you're likely to melt your brain from all the buzzwords alone! i've been using jboss for a project i've been leading for the past 2 years and the learning curve is very steep. the documentation for it is not great, either, so if your experience is anything like mine, you're going to be spending alot of time wading through the jboss.com forums. i think i would have benefited tremendously from taking a class on jboss, so you might want to consider that as well - but get up to speed on java first! also, you may want to consider subscribing to the services they provide.
i think a good place to start would be to take the simplest piece of your existing platform and try to 'port' it over to jboss. heck, just getting "hello, world" to work is going to seem like pulling teeth. but once you get on top of it, i think you're going to be amazed at the suite of tools you will have at your disposal. there may even be a 'shrinkwrapped' jboss solution to your problem; i.e., jboss portal for portlet support. just beware that to a child with a hammer, everything looks like a nail...
posted by the painkiller at 12:04 PM on January 12, 2007 [1 favorite]
1. get back up to speed in java. i would suggest using Eclipse for your IDE. install the JBoss IDE for Eclipse when you want to start working with jboss. jboss is going to make you use all java or java-derived technologies, all the time.
2. learn to write JSP pages for Tomcat, as Tomcat is one of the technologies embedded in jboss.
3. learn XML, if you haven't already.
4. learn about how the Model-View-Controller (MVC) design pattern works, if you haven't already. (scriptlets bad, tag libraries good!)
5. learn about the relevant bits of the J2EE platform work - particularly EJBs.
5a. if you're working with databases, learn Hibernate.
6. learn about how jboss has implemented the J2EE 'standard'.
jboss is extraordinarily powerful and quite complex application server. it has many, many things plugged into it and if you tried to learn them all at once, you're likely to melt your brain from all the buzzwords alone! i've been using jboss for a project i've been leading for the past 2 years and the learning curve is very steep. the documentation for it is not great, either, so if your experience is anything like mine, you're going to be spending alot of time wading through the jboss.com forums. i think i would have benefited tremendously from taking a class on jboss, so you might want to consider that as well - but get up to speed on java first! also, you may want to consider subscribing to the services they provide.
i think a good place to start would be to take the simplest piece of your existing platform and try to 'port' it over to jboss. heck, just getting "hello, world" to work is going to seem like pulling teeth. but once you get on top of it, i think you're going to be amazed at the suite of tools you will have at your disposal. there may even be a 'shrinkwrapped' jboss solution to your problem; i.e., jboss portal for portlet support. just beware that to a child with a hammer, everything looks like a nail...
posted by the painkiller at 12:04 PM on January 12, 2007 [1 favorite]
Response by poster: "Do you use a CMS?"
Are current portal, which I and another programmer built from scratch over the last few years, is very full featured but nowhere near as formal as JSR 168. In fact I don't see much in jBoss that we don't already have, or couldn't integrate very quickly, on the current intranet.
But the downside is that no one else would ever be able to take the thing over, and it's basically locked into rather old technology.
Learn to code proper Java. Looks like I picked a bad week to give up sniffing glue.
posted by Devidicus at 12:34 PM on January 12, 2007
Are current portal, which I and another programmer built from scratch over the last few years, is very full featured but nowhere near as formal as JSR 168. In fact I don't see much in jBoss that we don't already have, or couldn't integrate very quickly, on the current intranet.
But the downside is that no one else would ever be able to take the thing over, and it's basically locked into rather old technology.
Learn to code proper Java. Looks like I picked a bad week to give up sniffing glue.
posted by Devidicus at 12:34 PM on January 12, 2007
Painkiller's post is a beautiful summation of what is wrong with corporate Java today.
"Here, just learn these 6 abstraction layers all piled on top of them other, then try to get anything productive done with them!"
posted by rsanheim at 2:12 PM on January 12, 2007
"Here, just learn these 6 abstraction layers all piled on top of them other, then try to get anything productive done with them!"
posted by rsanheim at 2:12 PM on January 12, 2007
Sadly, I second rsanheim's comment and add that the other big problem with Java is the marketing push made it visible to the managerial layer, which often would push it as a solution to imaginary problems. You never hear them push for php or ruby.
Java was very useful for rolling our own servers and such. I never was happy trying to use beans or whatever crazy new frameworky/objecty insanity they came up with. They always felt way overblown for getting the work done.
Just my opinion. YMMV.
posted by chairface at 3:26 PM on January 12, 2007
Java was very useful for rolling our own servers and such. I never was happy trying to use beans or whatever crazy new frameworky/objecty insanity they came up with. They always felt way overblown for getting the work done.
Just my opinion. YMMV.
posted by chairface at 3:26 PM on January 12, 2007
y'know it's funny, after i reread my post i was going to post a followup to the effect that if you've spent most of your time writing an intranet portal in php you're probably going to find the jboss approach a bit...bloaty. rsanheim and chairface are right, i think, in the sense that using java for these kinds of things can rapidly allow your project to get out of control in terms of complexity. but just because java affords you the opportunity for complexity doesn't mean that it has to wind up complicated - Devidicus may not even need jboss, needing to do 1. and 2. + a spot of JDBC to meet his goals. but i don't think that learning about the way java does distributed objects or object-relational bridges or xml would be such a bad thing, either. if you're going to use an enterprise-grade piece of software like jboss, it would be useful to learn about all the hoops that jboss makes available for you to jump through, and with jboss there are an awful lot of hoops.
posted by the painkiller at 4:28 PM on January 12, 2007
posted by the painkiller at 4:28 PM on January 12, 2007
you should definitely check out this amazing presentation/screencast of a comparison of various web frameworks:
http://oodt.jpl.nasa.gov/better-web-app.mov
Warning: The J2EE/JBoss stuff is nasty!
Also, I would try to shift the discussion with your new boss towards goals and functionality instead of getting stuck talking about which technology/tools to use.
posted by kamelhoecker at 5:15 PM on January 13, 2007
http://oodt.jpl.nasa.gov/better-web-app.mov
Warning: The J2EE/JBoss stuff is nasty!
Also, I would try to shift the discussion with your new boss towards goals and functionality instead of getting stuck talking about which technology/tools to use.
posted by kamelhoecker at 5:15 PM on January 13, 2007
This thread is closed to new comments.
Long answer: If you're switching to a product that implements the Java portal/portlet standard (JSR 168? I can't remember), then you might be in for a treat. It varies from the open source implementations which are probably closer to spec, to the commercial ones which all have their own quirks. There are some out of the box portlets which may solve a lot of your simple problems, but be aware that time that's no longer spent programming, testing, and deploying may now be spent doing portal configuration tasks.
Do you use a CMS? Are you going to? Different products integrate with portal differently, and you might end up doing some tweaking there as well. Where we previously had employees doing some content editing and minor web page edits, we now have the same people doing portal administration work and content integration. It's a lot easier to pick up than programming, but it's still a task that requires some skill.
Application complexity is an issue, too. Are you talking about small applications that can be served with a few JSPs, or are you talking about data-crunching applications with a web frontend? It sounds like the latter, but I'd shy away from integrating large, data-driven applications. In any case, learn to code proper Java. I've seen database connections and web service calls made within JSP files that give me headaches.
A portal gives you the ability to display content based on security, common style and interface, flexibility in deployment, and content integration at the expense of extensibility, customization, and flexibility in interface.
posted by mikeh at 11:16 AM on January 12, 2007