Home » Language IDEs » ServerTools (WTP) » Dynamic Web Project setup with new Deployment Assembly page
| Dynamic Web Project setup with new Deployment Assembly page [message #543209] |
Mon, 28 June 2010 17:11  |
 Matthew Hall
Messages: 4
Registered: June 2010 |
Junior Member |
|
|
So, like many, I seem to be having a bit of a problem working with the new Deployment Assembly page that has been added to the Dynamic Web Project Properties. Hopefully, you might be able to get me straightened out!
I have approximately 30 source folders that are in sub-directories all over the project that are added to the build path (such as "modules/core/src"). Most of these folders contain a java package hierarchy with source files, but a few simply contain a large number of configuration files (such as "modules/config/src"). Build and runtime libraries are scattered in a few different "lib" directories across the project as well.
Previously, in Galileo, setting up a new Dynamic Web Project was easy. Once all of the source folders and libraries were added to the build path, I simply had to go to the "Java EE Module Dependencies" preferences page and click "Select All". Publishing the project to a local Tomcat server after this worked like a charm.
In Helios, however, I seem to be having some issues getting Tomcat to see some of the configuration files once the project is published. In particular, I have a file called "default.loaders" that exists in the "modules/config/src" folder that one of my bootstrap servlets is having a hard time finding. The "modules/config/src" folder is a Java source folder and has been added to the "Deployment Assembly" page with its "Deploy Path" set to "/WEB-INF/classes". The "default.loaders" file exists in both the "modules/config/src" and "bin" folders, and yet my bootstrap servlet is still getting a FileNotFoundException when it attempts to open it.
Any ideas on what sort of configuration changes I might need to perform to make the files in my "modules/config/src" source folder visible to the webapp?
|
|
| |
| Re: Dynamic Web Project setup with new Deployment Assembly page [message #543577 is a reply to message #543209] |
Tue, 29 June 2010 20:17  |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 6/28/2010 1:11 PM, Matthew Hall wrote:
> So, like many, I seem to be having a bit of a problem working with the
> new Deployment Assembly page that has been added to the Dynamic Web
> Project Properties. Hopefully, you might be able to get me straightened
> out!
>
> I have approximately 30 source folders that are in sub-directories all
> over the project that are added to the build path (such as
> "modules/core/src"). Most of these folders contain a java package
> hierarchy with source files, but a few simply contain a large number of
> configuration files (such as "modules/config/src"). Build and runtime
> libraries are scattered in a few different "lib" directories across the
> project as well.
>
> Previously, in Galileo, setting up a new Dynamic Web Project was easy.
> Once all of the source folders and libraries were added to the build
> path, I simply had to go to the "Java EE Module Dependencies"
> preferences page and click "Select All". Publishing the project to a
> local Tomcat server after this worked like a charm.
>
> In Helios, however, I seem to be having some issues getting Tomcat to
> see some of the configuration files once the project is published. In
> particular, I have a file called "default.loaders" that exists in the
> "modules/config/src" folder that one of my bootstrap servlets is having
> a hard time finding. The "modules/config/src" folder is a Java source
> folder and has been added to the "Deployment Assembly" page with its
> "Deploy Path" set to "/WEB-INF/classes". The "default.loaders" file
> exists in both the "modules/config/src" and "bin" folders, and yet my
> bootstrap servlet is still getting a FileNotFoundException when it
> attempts to open it.
>
> Any ideas on what sort of configuration changes I might need to perform
> to make the files in my "modules/config/src" source folder visible to
> the webapp?
What you describe should work. Have you confirmed that the
"default.loaders" file is not found under
"<workspace> /.metadata/.plugins/org.eclipse.wst.server.core/tmp?/wtpweba pps/ <app_name>/WEB-INF/classes"?
If not, you might try experimenting in a separate project to see if some
aspect in your current project is confusing the publishing. Since it's
the output folder that gets published, I would think it would be
sufficient to have the Deployment Assembly page map just one source
folder that is tied to a particular output folder. I don't think
mapping multiple source folders which use the same output folder to be
necessary, though I don't think it should hurt.
If some cause can't be determined, a bug report would probably be in
order to investigate further. Since a non-working project will be
needed, you could try copying your project and removing as much as you
can to make it smaller while preserving its problem behavior, and attach
it to the bug.
Cheers,
Larry
|
|
|
| Re: Dynamic Web Project setup with new Deployment Assembly page [message #543602 is a reply to message #543577] |
Wed, 30 June 2010 02:01 |
Matthew Hall
Messages: 4
Registered: June 2010 |
Junior Member |
|
|
| Larry Isaacs wrote on Tue, 29 June 2010 16:17 |
What you describe should work. Have you confirmed that the
"default.loaders" file is not found under
"<workspace> /.metadata/.plugins/org.eclipse.wst.server.core/tmp?/wtpweba pps/ <app_name>/WEB-INF/classes"?
If not, you might try experimenting in a separate project to see if some
aspect in your current project is confusing the publishing. Since it's
the output folder that gets published, I would think it would be
sufficient to have the Deployment Assembly page map just one source
folder that is tied to a particular output folder. I don't think
mapping multiple source folders which use the same output folder to be
necessary, though I don't think it should hurt.
If some cause can't be determined, a bug report would probably be in
order to investigate further. Since a non-working project will be
needed, you could try copying your project and removing as much as you
can to make it smaller while preserving its problem behavior, and attach
it to the bug.
Cheers,
Larry
|
Thanks for the reply, Larry!
If I publish to Tomcat normally, everything does work, and the default.loaders file can be found there. The problem I described appears to only occur when serving modules without publishing, directly from the workspace. I also typically publish module contexts to separate XML files, so I diffed the working Galileo context XML with the nonworking Helios XML. The only difference is the addition of this attribute in the Resources element:
extraResourcePaths="/WEB-INF/classes|/Users/ioeth/Workspaces/ <workspace dir>/<project dir>/bin"
Not really sure what that attribute is used for, nor how it would treat the /WEB-INF/classes entry, since it looks like an absolute path. It also seems weird that the value in that attribute looks to be pipe-delimited, while the rest of the attributes in the module context file are semicolon-delimited.
I did some testing by editing the file manually, and can confirm that if I remove that attribute and value that my server starts up normally. Think it's time to enter a bug report?
|
|
|
| Re: Dynamic Web Project setup with new Deployment Assembly page [message #543862 is a reply to message #543602] |
Wed, 30 June 2010 20:35 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 6/29/2010 10:01 PM, Matthew Hall wrote:
> Larry Isaacs wrote on Tue, 29 June 2010 16:17
>> What you describe should work. Have you confirmed that the
>> "default.loaders" file is not found under "<workspace>
>> /.metadata/.plugins/org.eclipse.wst.server.core/tmp?/wtpweba pps/
>> <app_name>/WEB-INF/classes"?
>>
>> If not, you might try experimenting in a separate project to see if
>> some aspect in your current project is confusing the publishing. Since
>> it's the output folder that gets published, I would think it would be
>> sufficient to have the Deployment Assembly page map just one source
>> folder that is tied to a particular output folder. I don't think
>> mapping multiple source folders which use the same output folder to be
>> necessary, though I don't think it should hurt.
>>
>> If some cause can't be determined, a bug report would probably be in
>> order to investigate further. Since a non-working project will be
>> needed, you could try copying your project and removing as much as you
>> can to make it smaller while preserving its problem behavior, and
>> attach it to the bug.
>>
>>
>> Cheers,
>> Larry
>
>
> Thanks for the reply, Larry!
>
> If I publish to Tomcat normally, everything does work, and the
> default.loaders file can be found there. The problem I described appears
> to only occur when serving modules without publishing, directly from the
> workspace. I also typically publish module contexts to separate XML
> files, so I diffed the working Galileo context XML with the nonworking
> Helios XML. The only difference is the addition of this attribute in the
> Resources element:
>
> extraResourcePaths="/WEB-INF/classes|/Users/ioeth/Workspaces/ <workspace
> dir>/<project dir>/bin"
>
> Not really sure what that attribute is used for, nor how it would treat
> the /WEB-INF/classes entry, since it looks like an absolute path. It
> also seems weird that the value in that attribute looks to be
> pipe-delimited, while the rest of the attributes in the module context
> file are semicolon-delimited.
>
> I did some testing by editing the file manually, and can confirm that if
> I remove that attribute and value that my server starts up normally.
> Think it's time to enter a bug report?
See if Bug 318449[1] applies to your use case. This would appear to be
a regression caused by the attempt to support multiple web content folders.
Cheers,
Larry
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=318449
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 23:18:55 GMT 2024
Powered by FUDForum. Page generated in 0.03858 seconds |
] 
Search
Help
Register
Login
Home
