Your customer understands that Tomcat is not an EJB container, right? And that an EJB project would need to be seriously refactored, or even rewritten, to work without EJBs or other JEE constructs that Tomcat does not support, right?
What is the motivation for this in the first place?
How intensive it is going to be depends upon how you plan to replace all the non-supported JEE technology in the project, and the extent to which the project depends upon those technologies.
To be honest; if EJBs are being used, and the intent is to migrate to a non-EJB container, a complete re-architecture and rewrite are what I'd advise.
Perhaps the first step should be to post in the JBoss forum to see if his specific concerns can be addressed without ditching JBoss, or by migrating to an alternate JEE container (Tomcat not being a JEE container).
dude, thank you so much for the quick responses and informative ones too. i have to look up the abbreviations you're using to understand what you're talking about, so it is teaching me something. thank you.
honestly, i would like to continue with jboss because that is what all the code was developed in. and we might end up going that route due to the problems we are running into and the time it's taking to research and work through.
at the start of this, we did discuss converting jboss to tomcat was new territory for us and we didn't know how well it would work and we might end up having to stick with jboss.
i have a meeting to discuss progress and path forward tomorrow afternoon, so i might end up recommending we stand up a new centos 6.5 box and running jboss on that and be done with it.
To add to what Bear said and based on that stacktrace, it looks like his application relies on certain MBean (javax.management.InstanceNotFoundException: jboss.system:type=ServerConfig) which only JBoss exposes and not Tomcat. So I don't think the migration is going to work unless there are application level changes to make it work on Tomcat.
I would also advise against migrating to tomcat but you are using mbeans in jboss 4 so your reliance on the jboss 4 Mbean server makes it very difficult because you can't even migrate to the latest Jboss(Wildfly) version if (VM memory is your concern for the move) since it may not have all the mbeans that were on jboss 4 or they be under different namespaces. I would start by listing what the application does first and noting the APIs that the application uses/relies on before picking a container to migrate to.
I should also point out that these kind of decisions happen too often. People decide on a tool before looking at what they need to achieve. Even big corporates buy software that they later on have to butcher and hammer to try and get it to do what they really wanted which could have been done by a more suitable tool. Don't make the same mistake. Let your requirements decide which tools you need to use.
Grow a forest with seedballs and this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth