[rjst]

Hi,

I would like to ask if the following features are implemented (I’m using jetty with myeclipse 3.8.3):

-When I change my classpath, I have to start and stop the context in the jetty UI. Is there a way to make myeclipse do this by itself ?
-when I add libraries to the classpath I have to redeploy manually

some situation when this could happen automatically (perhaps via the server’s jmx interface):

-change to classes that can’t be updated via java debugging interface
-changes to web.xml file
-adding jars

also redeploying has it’s own troubles, because jetty locks files.

thanks
Ricardo

[Riyad Kalla]

-When I change my classpath, I have to start and stop the context in the jetty UI. Is there a way to make myeclipse do this by itself ?

Not currently, we try to avoid any application-server specific code within ME because we support so many application servers and each one can change its symantics between releases which would require a considerable development effort that would take away from the other development tools.

also redeploying has it’s own troubles, because jetty locks files.

If you are using an exploded deployment AND Jetty supports hot deploy like Tomcat/JBoss, then as you change files they are immediately copied out to the server and reloaded; so you don’t need to ‘redeploy’ every single time.

[rjst]

yes, I’m doing that, but some changes take a restart of the app (not of the server), like adding jar files.

thanks for your answer, I just wanted to know if a better way existed

[haobaba1]

@support-rkalla wrote:

-When I change my classpath, I have to start and stop the context in the jetty UI. Is there a way to make myeclipse do this by itself ?

Not currently, we try to avoid any application-server specific code within ME because we support so many application servers and each one can change its symantics between releases which would require a considerable development effort that would take away from the other development tools.

also redeploying has it’s own troubles, because jetty locks files.

If you are using an exploded deployment AND Jetty supports hot deploy like Tomcat/JBoss, then as you change files they are immediately copied out to the server and reloaded; so you don’t need to ‘redeploy’ every single time.

From what I can tell only files under the Web-Root are deployed automatically when they are saved. When ever I change a servlet or anything other class file that is not under web-root I need to redeploy inorder for it to be reloaded by jboss. This creating problems because now jboss is throwing exceptions everytime I redeploy, forcing me to restart the server.

This is the console output, the module in question does exists and is referenced properly:
13:28:42,852 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:/C:/jboss-4.0.1RC2/server/default/deploy/TATrackerEAR.ear/
13:28:42,852 INFO [EARDeployer] Init J2EE application: file:/C:/jboss-4.0.1RC2/server/default/deploy/TATrackerEAR.ear/
13:28:43,055 ERROR [MainDeployer] Could not initialise deployment: file:/C:/jboss-4.0.1RC2/server/default/deploy/TATrackerEAR.ear/
org.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.1RC2/server/default/deploy/TATrackerEAR.ear/MigrationWAR.war could not be opened, does it exist?
at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:175)
at org.jboss.deployment.EARDeployer.init(EARDeployer.java:236)
at org.jboss.deployment.MainDeployer.init(MainDeployer.java:828)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:765)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:122)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:131)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:175)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:305)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:463)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:215)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:194)

[Author]

Posts