Skip to main content

asadmin deploydir

10 replies [Last post]
pierre
Offline
Joined: 2003-06-10

I'm trying to use asadmin deploydir to deploy a webapp that is already exploded. However, I keep getting the following error:

CLI171 Command deploydir failed : Unable to find the archive to be deployed in specified location.; requested operation cannot be completed

I don't quite understand the error message. Since I'm deploying an exploded directory, there obviously won't be an archive in there.

Is this working for anyone? Am I missing something?

Thanks,

-- Pierre

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pierre
Offline
Joined: 2003-06-10

Tim,

Many thanks for the clarifications. I started a new web project this morning, tried the command, and it now works like a charm!

Sorry about the noise... The fact that the error message had 'archive' in it really threw me off. I'm pretty sure I had the directory properly specified though. I wonder if there are any other error condition (e.g. web.xml absent) that would trigger this error message?

Thanks again,

-- Pierre

demiant
Offline
Joined: 2006-05-01

Hey,

I tried to follow post:
http://forums.java.net/jive/thread.jspa?forumID=56&threadID=13592&messag...

in order to make BRIT work with GF, but unfortunately it doesnt work for me,

since Brit's viewer comes already opened, i tried to use the 'asadmin deploydir' option, but I always get the error below:

CLI137 Command deploydir failed.

This is the command I am running:
asadmin deploydir --user admin --passwordfile /root/pass.txt /root/birt-viewer/

server.log doesnt change at all, the only thing I see is that CLI137 error line :-/

Any clue?

thanks,

Demian

hzhang_jn
Offline
Joined: 2005-07-22

What build were you trying? It so happened there was a regression in b18 and asadmin deploydir stopped working.
The problem is fixed in b19.

trouby
Offline
Joined: 2006-02-27

I had the same problem when I tried to install Birt Viewer yestreday, it really got fixed with b19 (the deploydir problem),

Anyway Birt's viewer still does not work with GF (although it seems to work just fine with tomcat/websphere/jboss 'out of the box'),

I'm not sure why, but maybe someone that has good knowledge with the structure of .war /servlet class-path can help,

After deploying the viewer, the following error occures when trying to execute a report:

[#|2006-10-10T14:14:54.497+0200|WARNING|sun-appserver-pe9.1|javax.enterprise.system.stream.err|_ThreadID=14;_ThreadName=httpWorkerThread-8080-0;_RequestID=dfaf0016-34c4-4935-a4ff-0160b732632c;|
java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.eclipse.birt.core.framework.osgi.OSGILauncher.startup(OSGILauncher.java:128)
at org.eclipse.birt.core.framework.Platform.startup(Platform.java:78)
at org.eclipse.birt.report.service.ReportEngineService.setEngineContext(Unknown Source)
at org.eclipse.birt.report.service.BirtViewerReportService.setContext(Unknown Source)
at org.eclipse.birt.report.servlet.ViewerServlet.__getContext(Unknown Source)
at org.eclipse.birt.report.servlet.BirtSoapMessageDispatcherServlet.doGet(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:246)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:185)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:549)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:789)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:328)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:251)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:205)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)
|#]

Looks like the class 'org.eclipse.core.runtime.adaptor.EclipseStarter' cannot be found, while this class exists, but not under WEB-INF/lib directory, but inside WEB-INF/platform/plugins/org.eclipse.osgi_3.2.0.v20060601.jar file,

What I do not understand, is how this jar file is expected to be found? maybe the servlet itself knows to seek it, if so, why it doesnt work with GF while it works with other J2EE web containers?

Any clue guys?

Thanks.

demiant
Offline
Joined: 2006-05-01

yeah i have exactly the same problem :/

tjquinn
Offline
Joined: 2005-03-30

Hi, demiant.

What build are you using that gives the same problem?

- Tim

demiant
Offline
Joined: 2006-05-01

im sorry i didnt explain myself good,

i have meant that i get the same error as trouby posted with birt viewer, this is not a pure glassfish problem but probably a packaging issue

thanks

jluehe
Offline
Joined: 2004-12-01

According to the spec, only class resources in WEB-INF/classes or bundled in a JAR file in WEB-INF/lib are considered by a webapp's classloader.

If you want the webapp's classloader to consider class resources in other locations, you need to specify those locations as the value of the "extra-class-path" attribute of the element in your sun-web.xml (if your webapp currently does not bundle any sun-web.xml, you need to add one and place it in the same directory as your web.xml).

Here's an example of a sun-web.xml that has the webapp classloader search for class resources in "WEB-INF/lib/extra/extra.jar", in addition to the standard repositories for class resources:



See my blog at

http://blogs.sun.com/jluehe/entry/greater_flexibility_in_configuring_your

for more details.

tjquinn
Offline
Joined: 2005-03-30

Hi, Pierre.

Can you post the following:

- The exact asadmin deploydir command you are using.
- As briefly as you can, a listing of the directory (and subdirs) you are using showing where the top-level is in the file system.

Because glassfish lets users deploy directories and not just .jars, .wars, and .ears, deployment in glassfish tends to use the term "archive" to mean the source of the deployemtn, whether it's one of the familiar jar types or a directory.

The error message is claiming that it cannot find the "archive" in this, broader, sense.

tjquinn
Offline
Joined: 2005-03-30

I should clarify. By "top-level" I meant the top-level of the directory from which you are trying to deploy.

I'm trying to verify that the appropriate files are where the app server will be looking for them, based on the deploydir command you are using.

Sorry for any confusion.

- Tim