The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 11 Jun 2004 8:09 AM
Body:
As a test I incremented the insertAfter if insertAfter points at the last element.
Then the elements are inserted in the right place.
Strange.
I committed the fix.
One more important thing.
For hot deployment a user with a (Tomcat) manager role must be defined in
tomcat-users.xml and its name and password must be defined in jetspeed.properties
(properties services.autodeployment.user and
services.autodeployment.password).
For now these are defined as scott/scott.
These must be specified in the getting-started.html, including instructions how to add
this user to tomcat-users.xml.
Furthermore, I don't think these should be hardcoded like this but configurable using
(ant) filters, just like the database username/password.
New users to Jetspeed 2 will have a hard time getting it up and running otherwise (it
sure cost me some time before I understood what was going wrong during startup).
I think the new setup is great.
But I sure would like a warning and proper instructions when these kind of changes are
made which requires me to change my own configuration before I can get it running
again...
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36039
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-74
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-74
Summary: Refactor PAM and Descriptor Utilities
Type: Improvement
Status: Closed
Priority: Major
Resolution: FIXED
Project: Jetspeed 2
Components:
Deployment
Fix Fors:
2.0-dev/cvs
2.0-a1
Versions:
2.0-dev/cvs
2.0-a1
Assignee: Scott T Weaver
Reporter: Scott T Weaver
Created: Wed, 9 Jun 2004 7:25 AM
Updated: Fri, 11 Jun 2004 8:09 AM
Environment: Mandrake Linux 10, Tomcat 4.1.30, HSQL
Description:
I am refactoring all of the Jetspeed desccriptor utility classes from static, utility
classes into objects.
PortletDescriptorUtilities has been renamed to PortletApplicationDescriptor.
WebDescriptorUtilities has been refactored into WebApplicationDescriptor.
JetspeedDescriptorUtilities has been refactored into ExtendedPortletMetadata.
Besides the rename, the static methods have been converted into instance methods.
I have created a composite object, PortletApplicationWar, that uses these three
metadata classes to build up registry objects from a war file, which is either an
actual war file itself OR a war-like structure on the file system. I am using
commons-vfs to manipulate the WAR as this allows me to work on the war as a
FileObject, regardless if it is a file system directory or a WAR file.
All these descriptor classes have been moved to the
org.apache.jetspeed.util.descriptor package.
FileSystemPAM uses the PortletApplicationWar class exclusively instead of directly
using the metadata classes themselves. This makes the FSPAM code much more readable
and easier to debug.
Looking over the logic for processWebXML, it does not appear to be adding the
JetspeedContainer servlet nor its mapping. Also logic used to decide where to put the
new elements could possibly cause the elements to be placed in the wrong spot relative
to the DTD definition.
I rewrote this logic using JDom and XPath expressions. I am using an XPath query to
check for a specific servelet and servlet-mapping with the servlet-name
"JetspeedContainer". If these elements do not exist, I use JDom to walk the top-level
of elements until it finds the correct location, per the DTD, to insert both the
servlet and servlet-mapping elements.
I have added an additional test, testInfuseWebXML, to TestPortletDescriptor to verify
that the infusing works correctly.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
