- This topic has 3 replies, 2 voices, and was last updated 19 years ago by
.
-
Posts
-
It would be great to have more flexibility when deploying large applications in EAR. For instance :
– Being able to chose for each module the exact name of file or directory that will be deployed. Sometimes the name that is automatically selected is not suitable. Renaming projects while working in team is not a workable approach.
– The possibility when including utility jars (build from depending projects) to automatically include them in application.xml (<module><java>mylib.jar</java></module>. Should be optionnal. It is the best way I found to manage utility jars with JBoss.
– The possibility to include depending projects as exploded jars when doing exploded deployment
– “Add EJB capabilities” on a project would be great. Should be possible to select J2EE 5 (EJB3) as specification.
-…
– A simple command (on the context menu) to touch application.xml or web.xml so that the full ear or a single module is restarted by the app server.Well in the mean time, I deploy with Ant so that I have full control on what it does.
Bernard
– Being able to chose for each module the exact name of file or directory that will be deployed. Sometimes the name that is automatically selected is not suitable. Renaming projects while working in team is not a workable approach.
This is an enhancement we have filed, to specify the archive name.
– The possibility to include depending projects as exploded jars when doing exploded deployment
EARs have no “classes” equivalent, there is no well-defined way to explode classes into an EAR and still honor the classloader hierarchy. And optionally merging it with any of the EJBs or Web projects deployed with the EAR wouldn’t make sense. Maybe I misunderstood you?
– “Add EJB capabilities” on a project would be great. Should be possible to select J2EE 5 (EJB3) as specification.
Agreed, this should be added and is filed as an enhancement right now.
– A simple command (on the context menu) to touch application.xml or web.xml so that the full ear or a single module is restarted by the app server.
I would argue that simply keeping those files open in an editor and switching to them, hitting space then backspace and save is probably equivalently as fast as mouse/right click/mouse/left click, but that’s up to debate.
EARs have no “classes” equivalent, there is no well-defined way to explode classes into an EAR and still honor the classloader hierarchy. And optionally merging it with any of the EJBs or Web projects deployed with the EAR wouldn’t make sense. Maybe I misunderstood you?
Well yes and no. If you run on JBoss and you declare a java module in application.xml (<module><java>mylib.jar</java></module>), it is deployed on the same class loader as your EJBs, so that it is accessible to both EJBs and webapps and it can be packaged or exploded.
This is in fact better than including it in EJBs and WARs Class-Path (inside MANIFEST.MF) because :
– This option supports only packeged jars even if you are doing exploded EAR deployment
– If you are doing exploded EAR deployment and your OS is Windows, your utility jar gets locked by the VM and is impossible to change or delete without stopping JBoss.This leads me to another of my requested fcts that you did not consider in your mail :
– The possibility when including utility jars (build from depending projects) to automatically include them in application.xml (<module><java>mylib.jar</java></module>. Should be optionnal. It is the best way I found to manage utility jars with JBoss.
This would help managing the configuration of the previews point.
Just for your information, here are 2 links related to this problem :
JBoss acknowledges but won’t fix the utility jar lock problem : http://jira.jboss.com/jira/browse/JBAS-2434
A discussion with myself on the java module workaround : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73071
PS : MyEclipse is great !
Bernard
