You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by ji...@apache.org on 2004/06/09 16:26:10 UTC
[jira] Created: (JS2-74) Refactor PAM and Descriptor Utilities
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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: Open
Priority: Major
Project: Jetspeed 2
Components:
Deployment
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: Wed, 9 Jun 2004 7:25 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 this 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 11 Jun 2004 12:02 PM
Body:
I don't get it.
I retrieved a fresh cvs HEAD, cleared out all of J2 from my local maven repository and the J2 plugin.
fullDeploy goal fails again though because it can't find the jetspeed2:deploy goal.
AFAIK, using a local plugin requires it to be defined as dependency, otherwise maven won't know anything about it.
How is it possible you can deploy without it?
Below my console output:
fullDeploy:
deploy:
[echo] Deploying jetspeed2:jetspeed, Jetspeed-2 Portal Engine
[copy] Copying 1 file to C:\jetspeed-base\tomcat4\webapps
[unwar] Expanding: \jetspeed-base\tomcat4\webapps\jetspeed.war into \jetspeed-base\tomcat4\webapps\jetspeed
[copy] Copying 1 file to C:\jetspeed-base\tomcat4\webapps
[copy] Copying 1 file to C:\jetspeed-base\tomcat4\conf\Catalina\localhost
Tag library requested that is not present: 'reactor' in plugin: 'null'
catalina:base-shared:
[echo] Copying from c:\java\maven-local/repository to /jetspeed-base/tomcat4/shared/lib...
Tag library requested that is not present: 'reactor' in plugin: 'null'
Tag library requested that is not present: 'reactor' in plugin: 'null'
BUILD FAILED
File...... C:\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line...... 485
Column.... 40
Unable to obtain goal [fullDeploy] -- C:\workspace\jakarta-jetspeed-2\portal\maven.xml:250:41: <attainGoal> No goal [jet
speed2:deploy]
Total time: 39 seconds
Finished at: Fri Jun 11 20:50:45 CEST 2004
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36052
---------------------------------------------------------------------
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 12:02 PM
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Closed: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
Message:
The following issue has been closed.
---------------------------------------------------------------------
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: Wed, 9 Jun 2004 9:36 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 11 Jun 2004 7:05 AM
Body:
Scott,
The PortletApplicationWAR.insertElementCorrectly doesn't work correctly.
The pam and security portlet applications contain only the name and description elements.
The container servlet and mapping elements should be inserted after those but instead are inserted in between.
I looked at the code but cannot see what is going wrong.
It seems that it doesn't work when the elements must be inserted at the end.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36037
---------------------------------------------------------------------
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 7:05 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 11 Jun 2004 2:56 PM
Body:
The plugin problem can be solved by at least once do:
/maven-plugin/maven plugin:install
After that, plugin:deploy will update the plugin definition but without the install first it won't be found (without a dependency definition that is).
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36055
---------------------------------------------------------------------
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 2:56 PM
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Mon, 14 Jun 2004 5:47 AM
Body:
I finally found out the problem with the web.xml infusion.
The insertion point was based on the element index, *not* the content index. These two can, and usually are (comments, white space etc.) are !=.
Furthermore, added (again!) an EntityResolver to be able to build/run offline.
Not just with maven -o mind you, really offline without a network connection!
I had the same problem with TestPortletDescriptor so I added an EntityResolver, looking up the web.xml dtd (web-app_2_3.dtd) locally using the PortletApplicationWar class.
I kindly request future new xml parsing code also to be tested without a network connection (or blocked/disabled whatever) before it is committed because at my client I'm completely blind from the internet.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36141
---------------------------------------------------------------------
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: Mon, 14 Jun 2004 5:47 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Scott T Weaver
Created: Fri, 11 Jun 2004 10:28 AM
Body:
> 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.
How about changing these to use filter sets and add 2 new props to plugin.properties.
org.apache.jetspeed.tomcat.manager.user
org.apache.jetspeed.tomcat.manager.password
Then alter jetspeed.properties with @TOMCAT.USER@ and @TOMCAT.PASSWORD@
We could use the defaults jetspeed-manager/deployment.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36045
---------------------------------------------------------------------
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 10:28 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Scott T Weaver
Created: Fri, 11 Jun 2004 11:18 AM
Body:
> I think not only plugin.properties but also jetspeed.properties needs
> these new properties defined and filtered.
plugin.properties wouldn't need the filter set just jetspeed.properties. We would just leave plugin.properties as default values.
> Concerning the infusion of web.xml: it certainly wasn't working for
> me. The servlet and mapping were infused alright but in the wrong
> place.
> I've noticed that with the last changes you committed last night you
> upgraded to jdom b10. Can it be a bug in jdom b10 which caused this?
> Did you test the changes I made to
> PortletApplicationWAR.insertElementCorrectly? If these are working for
> you now I guess it must have gone wrong for you before as well...
yes, b10 added the ability to do Element.addContent(int index, Element child). Before I was sticking it into the list of elements at the specified index, which should have worked. I did not remove your changed on the last committ which fixed Serge Huber's requirement to specify conf info for the VFS file system manager.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36050
---------------------------------------------------------------------
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 11:18 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Scott T Weaver
Created: Fri, 11 Jun 2004 10:23 AM
Body:
Ate,
I never had the issue with the web.xml not getting infused. security and PAM always show up with the correct servlet and servlet mappings.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36044
---------------------------------------------------------------------
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 10:23 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor
PAM and Descriptor Utilities
Posted by Scott T Weaver <sc...@binary-designs.net>.
Awesome!
Your right, I must have done an plugin:install before I ever started my
initial testing. Would should probably add plugin:install to allBuild.
On Fri, 2004-06-11 at 17:53, Ate Douma wrote:
> I found it!
>
> You must have done a plugin:install at least once.
> After I done that it all works.
>
> After the install which copies the plugin to {MAVEN_HOME}/plugins new versions deployed using plugin:deploy (which
> *only* extracts the new plugin into {MAVEN_LOCAL_HOME}/plugins) take precedence over the original plugin definition.
> But, it *is* required to do an plugin:install at least once. Otherwise, a project dependency is needed.
>
> It would be nice if the maven documentation would be a bit more informative.
> Not even the developers guide, which addresses developing new plugins describes these kind of requirements clearly :(
>
> Bloody hell, I lost almost half a days work only just this one issue.
> We better make sure to document this clearly for future users.
>
> Scott T Weaver wrote:
>
> > I really don't know what it is, it's just very strange. I just ran
> > fullDeploy from /portal and it runs just fine.
> >
> > The only time I have seen that exception is when the plugin is missing
> > from .maven/plugins.
> >
> > On Fri, 2004-06-11 at 16:45, Ate Douma wrote:
> >
> >>Scott T Weaver wrote:
> >>
> >>>I was looking at the stacktrace you posted, it is find the jetspeed2
> >>>plugin just fine but appears to be blowing chunks on:
> >>>
> >>>Tag library requested that is not present: 'reactor' in plugin: 'null'
> >>
> >>Yes. I have that since I upgraded from maven 1.0-rc1 to rc2.
> >>It never resulted in any problem so I thought it to be some kind of deprecated error message or such.
> >>You're saying you don't have those messages?
> >>Maybe there really is something wrong in my setup.
> >>But then, I completely reinstalled java and maven at least once after the first time I saw this message so how could it
> >>be related to my setup?
> >>I'll see if I can find more about this message. If anyone else had/has this please let me know.
> >>
> >>
> >>>I have no idea what would be causing that. Are you still getting this
> >>>same error?
> >>>
> >>>On Fri, 2004-06-11 at 16:23, Ate Douma wrote:
> >>>
> >>>
> >>>>I give up.
> >>>>I tried all the thing you said. No go. Even completely reinstalled maven and deployed the plugin again.
> >>>>Still, no go.
> >>>>I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find anything about in the
> >>>>documentation but as you seems to be using it like that I'm lost.
> >>>>It just doesn't work on my machine.
> >>>>I checked my environment variables and the only related things I have defined is MAVEN_HOME and as classpath '.'.
> >>>>Are there other variables I should set?
> >>>>If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember correctly you are using Linux).
> >>>>
> >>>>Would there be any harm in defining the plugin dependency in portal/project.xml because without it I can't get it to
> >>>>work...
> >>>>
> >>>>Scott T Weaver wrote:
> >>>>
> >>>>
> >>>>
> >>>>>I figured you did, just had to check ;)
> >>>>>
> >>>>>try deleting all of the *.cache files in your .maven/plugins directory.
> >>>>>Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
> >>>>>deployed to the .maven/plugins directory.
> >>>>>
> >>>>>On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
> >>>>>>
> >>>>>>jira@apache.org wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>The following comment has been added to this issue:
> >>>>>>>
> >>>>>>> Author: Scott T Weaver
> >>>>>>> Created: Fri, 11 Jun 2004 12:15 PM
> >>>>>>> Body:
> >>>>>>>Ate,
> >>>>>>>
> >>>>>>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
> >>>>>>>---------------------------------------------------------------------
> >>>>>>>View this comment:
> >>>>>>>http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
> >>>>>>>
> >>>>>>>---------------------------------------------------------------------
> >>>>>>>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 12:15 PM
> >>>>>>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by Ate Douma <at...@douma.nu>.
I found it!
You must have done a plugin:install at least once.
After I done that it all works.
After the install which copies the plugin to {MAVEN_HOME}/plugins new versions deployed using plugin:deploy (which
*only* extracts the new plugin into {MAVEN_LOCAL_HOME}/plugins) take precedence over the original plugin definition.
But, it *is* required to do an plugin:install at least once. Otherwise, a project dependency is needed.
It would be nice if the maven documentation would be a bit more informative.
Not even the developers guide, which addresses developing new plugins describes these kind of requirements clearly :(
Bloody hell, I lost almost half a days work only just this one issue.
We better make sure to document this clearly for future users.
Scott T Weaver wrote:
> I really don't know what it is, it's just very strange. I just ran
> fullDeploy from /portal and it runs just fine.
>
> The only time I have seen that exception is when the plugin is missing
> from .maven/plugins.
>
> On Fri, 2004-06-11 at 16:45, Ate Douma wrote:
>
>>Scott T Weaver wrote:
>>
>>>I was looking at the stacktrace you posted, it is find the jetspeed2
>>>plugin just fine but appears to be blowing chunks on:
>>>
>>>Tag library requested that is not present: 'reactor' in plugin: 'null'
>>
>>Yes. I have that since I upgraded from maven 1.0-rc1 to rc2.
>>It never resulted in any problem so I thought it to be some kind of deprecated error message or such.
>>You're saying you don't have those messages?
>>Maybe there really is something wrong in my setup.
>>But then, I completely reinstalled java and maven at least once after the first time I saw this message so how could it
>>be related to my setup?
>>I'll see if I can find more about this message. If anyone else had/has this please let me know.
>>
>>
>>>I have no idea what would be causing that. Are you still getting this
>>>same error?
>>>
>>>On Fri, 2004-06-11 at 16:23, Ate Douma wrote:
>>>
>>>
>>>>I give up.
>>>>I tried all the thing you said. No go. Even completely reinstalled maven and deployed the plugin again.
>>>>Still, no go.
>>>>I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find anything about in the
>>>>documentation but as you seems to be using it like that I'm lost.
>>>>It just doesn't work on my machine.
>>>>I checked my environment variables and the only related things I have defined is MAVEN_HOME and as classpath '.'.
>>>>Are there other variables I should set?
>>>>If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember correctly you are using Linux).
>>>>
>>>>Would there be any harm in defining the plugin dependency in portal/project.xml because without it I can't get it to
>>>>work...
>>>>
>>>>Scott T Weaver wrote:
>>>>
>>>>
>>>>
>>>>>I figured you did, just had to check ;)
>>>>>
>>>>>try deleting all of the *.cache files in your .maven/plugins directory.
>>>>>Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
>>>>>deployed to the .maven/plugins directory.
>>>>>
>>>>>On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
>>>>>>
>>>>>>jira@apache.org wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>The following comment has been added to this issue:
>>>>>>>
>>>>>>> Author: Scott T Weaver
>>>>>>> Created: Fri, 11 Jun 2004 12:15 PM
>>>>>>> Body:
>>>>>>>Ate,
>>>>>>>
>>>>>>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
>>>>>>>---------------------------------------------------------------------
>>>>>>>View this comment:
>>>>>>>http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>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 12:15 PM
>>>>>>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM
and Descriptor Utilities
Posted by Scott T Weaver <sc...@binary-designs.net>.
I really don't know what it is, it's just very strange. I just ran
fullDeploy from /portal and it runs just fine.
The only time I have seen that exception is when the plugin is missing
from .maven/plugins.
On Fri, 2004-06-11 at 16:45, Ate Douma wrote:
> Scott T Weaver wrote:
> > I was looking at the stacktrace you posted, it is find the jetspeed2
> > plugin just fine but appears to be blowing chunks on:
> >
> > Tag library requested that is not present: 'reactor' in plugin: 'null'
> Yes. I have that since I upgraded from maven 1.0-rc1 to rc2.
> It never resulted in any problem so I thought it to be some kind of deprecated error message or such.
> You're saying you don't have those messages?
> Maybe there really is something wrong in my setup.
> But then, I completely reinstalled java and maven at least once after the first time I saw this message so how could it
> be related to my setup?
> I'll see if I can find more about this message. If anyone else had/has this please let me know.
>
> >
> > I have no idea what would be causing that. Are you still getting this
> > same error?
> >
> > On Fri, 2004-06-11 at 16:23, Ate Douma wrote:
> >
> >>I give up.
> >>I tried all the thing you said. No go. Even completely reinstalled maven and deployed the plugin again.
> >>Still, no go.
> >>I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find anything about in the
> >>documentation but as you seems to be using it like that I'm lost.
> >>It just doesn't work on my machine.
> >>I checked my environment variables and the only related things I have defined is MAVEN_HOME and as classpath '.'.
> >>Are there other variables I should set?
> >>If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember correctly you are using Linux).
> >>
> >>Would there be any harm in defining the plugin dependency in portal/project.xml because without it I can't get it to
> >>work...
> >>
> >>Scott T Weaver wrote:
> >>
> >>
> >>>I figured you did, just had to check ;)
> >>>
> >>>try deleting all of the *.cache files in your .maven/plugins directory.
> >>>Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
> >>>deployed to the .maven/plugins directory.
> >>>
> >>>On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
> >>>
> >>>
> >>>>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
> >>>>
> >>>>jira@apache.org wrote:
> >>>>
> >>>>
> >>>>
> >>>>>The following comment has been added to this issue:
> >>>>>
> >>>>> Author: Scott T Weaver
> >>>>> Created: Fri, 11 Jun 2004 12:15 PM
> >>>>> Body:
> >>>>>Ate,
> >>>>>
> >>>>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
> >>>>>---------------------------------------------------------------------
> >>>>>View this comment:
> >>>>> http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>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 12:15 PM
> >>>>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by Ate Douma <at...@douma.nu>.
Scott T Weaver wrote:
> I was looking at the stacktrace you posted, it is find the jetspeed2
> plugin just fine but appears to be blowing chunks on:
>
> Tag library requested that is not present: 'reactor' in plugin: 'null'
Yes. I have that since I upgraded from maven 1.0-rc1 to rc2.
It never resulted in any problem so I thought it to be some kind of deprecated error message or such.
You're saying you don't have those messages?
Maybe there really is something wrong in my setup.
But then, I completely reinstalled java and maven at least once after the first time I saw this message so how could it
be related to my setup?
I'll see if I can find more about this message. If anyone else had/has this please let me know.
>
> I have no idea what would be causing that. Are you still getting this
> same error?
>
> On Fri, 2004-06-11 at 16:23, Ate Douma wrote:
>
>>I give up.
>>I tried all the thing you said. No go. Even completely reinstalled maven and deployed the plugin again.
>>Still, no go.
>>I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find anything about in the
>>documentation but as you seems to be using it like that I'm lost.
>>It just doesn't work on my machine.
>>I checked my environment variables and the only related things I have defined is MAVEN_HOME and as classpath '.'.
>>Are there other variables I should set?
>>If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember correctly you are using Linux).
>>
>>Would there be any harm in defining the plugin dependency in portal/project.xml because without it I can't get it to
>>work...
>>
>>Scott T Weaver wrote:
>>
>>
>>>I figured you did, just had to check ;)
>>>
>>>try deleting all of the *.cache files in your .maven/plugins directory.
>>>Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
>>>deployed to the .maven/plugins directory.
>>>
>>>On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
>>>
>>>
>>>>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
>>>>
>>>>jira@apache.org wrote:
>>>>
>>>>
>>>>
>>>>>The following comment has been added to this issue:
>>>>>
>>>>> Author: Scott T Weaver
>>>>> Created: Fri, 11 Jun 2004 12:15 PM
>>>>> Body:
>>>>>Ate,
>>>>>
>>>>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
>>>>>---------------------------------------------------------------------
>>>>>View this comment:
>>>>> http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>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 12:15 PM
>>>>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM and
Descriptor Utilities
Posted by Scott T Weaver <sc...@binary-designs.net>.
I was looking at the stacktrace you posted, it is find the jetspeed2
plugin just fine but appears to be blowing chunks on:
Tag library requested that is not present: 'reactor' in plugin: 'null'
I have no idea what would be causing that. Are you still getting this
same error?
On Fri, 2004-06-11 at 16:23, Ate Douma wrote:
> I give up.
> I tried all the thing you said. No go. Even completely reinstalled maven and deployed the plugin again.
> Still, no go.
> I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find anything about in the
> documentation but as you seems to be using it like that I'm lost.
> It just doesn't work on my machine.
> I checked my environment variables and the only related things I have defined is MAVEN_HOME and as classpath '.'.
> Are there other variables I should set?
> If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember correctly you are using Linux).
>
> Would there be any harm in defining the plugin dependency in portal/project.xml because without it I can't get it to
> work...
>
> Scott T Weaver wrote:
>
> > I figured you did, just had to check ;)
> >
> > try deleting all of the *.cache files in your .maven/plugins directory.
> > Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
> > deployed to the .maven/plugins directory.
> >
> > On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
> >
> >>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
> >>
> >>jira@apache.org wrote:
> >>
> >>
> >>>The following comment has been added to this issue:
> >>>
> >>> Author: Scott T Weaver
> >>> Created: Fri, 11 Jun 2004 12:15 PM
> >>> Body:
> >>>Ate,
> >>>
> >>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
> >>>---------------------------------------------------------------------
> >>>View this comment:
> >>> http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
> >>>
> >>>---------------------------------------------------------------------
> >>>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 12:15 PM
> >>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by Ate Douma <at...@douma.nu>.
I give up.
I tried all the thing you said. No go. Even completely reinstalled maven and deployed the plugin again.
Still, no go.
I don't know: should all the plugins from the .maven/plugins be auto loaded? I didn't find anything about in the
documentation but as you seems to be using it like that I'm lost.
It just doesn't work on my machine.
I checked my environment variables and the only related things I have defined is MAVEN_HOME and as classpath '.'.
Are there other variables I should set?
If not I can only conclude it doesn't work on my laptop and/or on Windows XP (if I remember correctly you are using Linux).
Would there be any harm in defining the plugin dependency in portal/project.xml because without it I can't get it to
work...
Scott T Weaver wrote:
> I figured you did, just had to check ;)
>
> try deleting all of the *.cache files in your .maven/plugins directory.
> Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
> deployed to the .maven/plugins directory.
>
> On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
>
>>Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
>>
>>jira@apache.org wrote:
>>
>>
>>>The following comment has been added to this issue:
>>>
>>> Author: Scott T Weaver
>>> Created: Fri, 11 Jun 2004 12:15 PM
>>> Body:
>>>Ate,
>>>
>>>Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
>>>---------------------------------------------------------------------
>>>View this comment:
>>> http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
>>>
>>>---------------------------------------------------------------------
>>>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 12:15 PM
>>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM and Descriptor
Utilities
Posted by Scott T Weaver <sc...@binary-designs.net>.
I figured you did, just had to check ;)
try deleting all of the *.cache files in your .maven/plugins directory.
Also make sure that the maven-jetspeed2-plugin-1.0.0-SNAPSHOT has been
deployed to the .maven/plugins directory.
On Fri, 2004-06-11 at 15:17, Ate Douma wrote:
> Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
>
> jira@apache.org wrote:
>
> > The following comment has been added to this issue:
> >
> > Author: Scott T Weaver
> > Created: Fri, 11 Jun 2004 12:15 PM
> > Body:
> > Ate,
> >
> > Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
> > ---------------------------------------------------------------------
> > View this comment:
> > http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
> >
> > ---------------------------------------------------------------------
> > 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 12:15 PM
> > 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by Ate Douma <at...@douma.nu>.
Yes, of course I did. I retrieved a fresh cvs HEAD so I had to do an allBuild first.
jira@apache.org wrote:
> The following comment has been added to this issue:
>
> Author: Scott T Weaver
> Created: Fri, 11 Jun 2004 12:15 PM
> Body:
> Ate,
>
> Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
> ---------------------------------------------------------------------
> View this comment:
> http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
>
> ---------------------------------------------------------------------
> 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 12:15 PM
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Scott T Weaver
Created: Fri, 11 Jun 2004 12:15 PM
Body:
Ate,
Did you do an allBuild or a /maven-plugin plugin:deploy prior to calling fullDeploy?. If not, that is what is causing your problem.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36053
---------------------------------------------------------------------
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 12:15 PM
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Updated: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Scott T Weaver (mailto:weaver@apache.org)
Date: Wed, 9 Jun 2004 7:26 AM
Changes:
description changed from 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 this 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. to 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.
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/JS2-74?page=history
---------------------------------------------------------------------
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: Open
Priority: Major
Project: Jetspeed 2
Components:
Deployment
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: Wed, 9 Jun 2004 7:26 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 11 Jun 2004 11:00 AM
Body:
I think not only plugin.properties but also jetspeed.properties needs these new properties defined and filtered.
Concerning the infusion of web.xml: it certainly wasn't working for me. The servlet and mapping were infused alright but in the wrong place.
I've noticed that with the last changes you committed last night you upgraded to jdom b10. Can it be a bug in jdom b10 which caused this?
Did you test the changes I made to PortletApplicationWAR.insertElementCorrectly? If these are working for you now I guess it must have gone wrong for you before as well...
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36048
---------------------------------------------------------------------
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 11:00 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org