- This topic has 12 replies, 3 voices, and was last updated 17 years, 10 months ago by
.
-
Posts
-
Just downloaded trial WebSphere Application Server 6.0 and was looking into the viablity of using MyEclipse for development/assembly/deployment.
But reading WebSphere documentation, the application assembly process seems to be based on using Rational Application Developer. Basically the deployment descriptors are tied in with their development tool.
Used WebLogic before and didn’t have this problem because they had a separate deployment tool which would generate all the deployment descriptors and I could continue to use MyEclipse for the development and deployment process.
Am I missing something here or WebSphere is trying to lock me into their development tools?
Would appreciate your tips.[/b]
IBM trying to create vendor lock-in? You bet!
Have a look at our more general case WebSphere 6.0 developer guide and see if this can walk you through the steps you need to get working:
http://www.myeclipseide.com/images/tutorials/quickstarts/websphere6/Yes, I have seen that tutorial before. It is quite helpful but it doesn’t cover how to configure the WebSphere specific deployment descriptors, etc.
For instance, with WebLogic, I could create a preliminary stateless session EJB jar file. Then I could use weblogic’s deploy tool to load this jar, graphically create the weblogic specific deployment descriptor files and generate the stub and skeleton files. I could continue to use MyEclipse for the rest of the development process.
Not sure how I can achieve this in the WebSphere 6.0 world, without using Rational Application Developer. It seems I cannot continue development with MyEclipse for WebSphere? Have other people been able to work around this problem? If so, how?
Yes, I have seen that tutorial before. It is quite helpful but it doesn’t cover how to configure the WebSphere specific deployment descriptors, etc.
Ahh you are correct we don’t cover those specific details, that would come from the WebSphere documentation you were reading. I don’t know if the visual tools you are looking to use are part of RAD now or stand alone deployment tools in the app server, I’m sorry.
But looking at other posts, it seems people are developing with MyEclipse for WebSphere. I’m really curious to understand how they are able to address this issue. I’d really appreciate comments from MyEclipse users who are developing/deploying with WebSphere.
Wagles,
I did a quick google for WebSphere deployment and it seems using the admin console to “deploy” the EAR generates all the files you need (I believe those steps are also in the doc for reference sake).I’m not sure any stand alone app is necessary.
Hmm… so just create the ear file with all it’s components etc. with the standard J2EE deployment descriptors and then deploy it using admin console and that’ll create Websphere specific descriptors. In their documentation though, they ask you to use their ‘assembly tools’ i.e. Rational Application Developer or Application Server Toolkit. I’ll check that out, thanks for the tip.
I’m not terribly sure… people might be writing the websphere specific descriptors by hand, I’ve not developed with websphere before.
Do you have RAD installed, can you do a quick app in RAD and MyEclipse and then diff them to see what RAD created that MyEclipse didn’t and then go from there? I’m shooting in the dark here.
I downloaded a trial version of RAD, and downloaded and installed a sample app. If I look at the various descriptors which came with this sample app, and try to make sense of it, it is a nightmare.
This is a EAR project with 1 WAR module and 1 Datasource resource configured. Seems like the Datasource is directly configured into the EAR rather than on the app server. Here is the sum total of the XML hell:
For the Enterprise Application:
1. application.xml (but it has stuff like module id=”WebModule_1099435093161″ which I think correlates else where).
2. .modulemaps (seems like an RAD artifact to create a dependency of the Web module on another plan java project).
3. security.xml (some security configuration. Seems WebSphere specific)
4. deployment.xml (some classloader ordering configurations!)
5. resources.xml (bunch of resources configured here, e.g. Datasources, Mail, JMS)
6. variables.xml (some sort of variable substitution)For the web-app:
1. web.xml
2. ibm-web-ext.xmi
3. ibm-web-bnd.xmi (binds the Datasource resource configured at enterprise level to web resource entry in web.xml using some sort of cross-referencing id attribute)And this is a very simple EAR file without any EJBs, Web Services etc, and only a simple JDBC resource configured. I assume all these cross-referencing ids are needed by WebSphere and I’m not sure how these can be handcrafted, without using the RAD.
I must give it to WebSphere for creating such convoluted implementations for fairly simple concepts!
Good lord… are you certain your team needs to stay on websphere? Can’t use JBoss or Sun App Server?
After reading your list I feel more sorry I didn’t have better news for you as far as what MyEclipse will take off your hands and do for you, this sounds like an XML-enema.
Well, we don’t have much of a choice in deciding that. WebSphere is quite prevalent in the govt. arena. IBM has done a good job of marketing it in that space. Guess the name helps sell.
Preliminarily, to me, this situation is a show case of what’s wrong with J2EE today:
1. J2EE has become XML hell.
2. Documentation is poor.
3. All the big commercial vendors try to tie you in with their proprietary stack of tools – covering design, development, deployment, testing.
4. Our RAD (Rapid Application Development) tools will increase your productivity and cut down your development costs! (First thing you’ll need to do is to buy their $3000/person development tool and send them to training ($2,500/person) to use that tool and/or get a vendor consultant on site to teach the team how to use it!)
5. Too much emphasis from vendors on the RAD tools and too little on automating the dev-build-test cycle.
6. The entity EJB hype!
7. You move from Project A that uses App Server 1 to Project B that uses App Server 2, and there’s a substantial learning curve to use the new App Server effectively.
8. Too many specifications – and each App Server is at different spec levels – and has their own extensions to the specs.
9. This is where I feel, at the end of the day, Microsoft may have the upper hand.1. Yes
2. Hit or miss
3. Absolutely
4. Bingo
5. Rational is trying to improve this… with multi-thousand-dollar management software. I guess they are saving you the time their other tools are wasting you 🙂
6. I’ve never seen a technology take off faster than Spring, it was like watching animals flee from a sinking ship. EJB 3 is better but most of our corporate customers have washed their hands of EJB, they just won’t do it for the reasons you mention.
7. It’s too true and unfortunate
8. Extensions are a pain anywhere, this certainly contributes to #7
9. We have certainly talked to developers that had this sentiment as well. Although I would say that once a company has normalized on an easy, extensible reusable stack (say all open source or something they are good at) they can fly through product just as fast as the next guy. It’s just the issue of normalizing ontop of that platform and tools that has caused some big developers headaches, especially when dealing with client demand “we have to be one XYZ with EJB ABC”.That being said I’ve been googling and not turning up much, if I run across a good resource to help with this I’ll try and post it for you.
