You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Charles Severance <cs...@umich.edu> on 2006/08/28 05:19:08 UTC
Three problems in beta and trunk - trunk fails out of the box currently
Three little things are messed up in pluto. I have survived and
worked around things - but it would be nice to fix - particularly the
broken beta because it appears as though when the beta install
*seems* to work, it is actually installing some parts from the trunk
build if you end up building both at the same time.
/Chuck
==== Bug in pageId lookup in trunk ======
This worked about a week ago - so I am thinking something recent
happenned when I did an svn update.
The trunk has a bug where PageId's end up with a prefix of a "/" and
so the configuration can never find find pages - and things blow up
horribly.
To reproduce - simply bring up pluto, log in as tomcat, and navigate
to a page other than the default using the dropdown.
The fix is below:
vi pluto-portal-driver/src/main/java/org/apache/pluto/driver/services/
portal/RenderConfig.java
public PageConfig getPageConfig(String pageId) {
if (pageId == null || "".equals(pageId)) {
if (LOG.isDebugEnabled()) {
LOG.debug(
"Requested page is null. Returning default: " +
defaultPageId);
}
pageId = defaultPageId;
}
PageConfig retval = (PageConfig) pages.get(pageId);
// TODO: Fix Hack
if ( retval == null && pageId.startsWith("/") &&
pageId.length() > 2 ) {
System.out.println("HACK ALert - Trimming off slash
" + pageId.substring(1));
retval = (PageConfig) pages.get(pageId.substring(1));
}
System.out.println("retval = " + retval);
return retval;
}
[DEBUG] PortalURLParser - Parsing URL: /pluto/portal/Pluto%20Admin
[DEBUG] PortalURLParser - Parsing request pathInfo: /Pluto Admin
[DEBUG] PortalDriverServlet - Processing render request.
[DEBUG] PortalDriverServlet - Rendering Portal: Requested Page: /
Pluto Admin
HACK ALert - Trimming off slash Pluto Admin
retval = org.apache.pluto.driver.services.portal.PageConfig@f50e8d
======= Neither trunk nor beta1 will build unless
maven.test.skip=true ========
[INFO] Surefire report directory: /Users/csev/dev/pluto-1.1/pluto-
trunk/pluto-descriptor-impl/target/surefire-reports
org.apache.maven.surefire.booter.SurefireExecutionException: Unable
to create test class
'org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImp
lTest'; nested exception is java.lang.ClassNotFoundException:
org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImpl
Test; nested exception is
org.apache.maven.surefire.testset.TestSetFailedException: Unable to
create test class
'org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImp
lTest'; nested exception is java.lang.ClassNotFoundException:
org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImpl
Test
org.apache.maven.surefire.testset.TestSetFailedException: Unable to
create test class
'org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImp
lTest'; nested exception is java.lang.ClassNotFoundException:
org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImpl
Test
java.lang.ClassNotFoundException:
org.apache.pluto.descriptors.services.castor.WebAppDescriptorServiceImpl
Test
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass
(IsolatedClassLoader.java:100)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSet
s(AbstractDirectoryTestSuite.java:84)
at
org.apache.maven.surefire.Surefire.createSuiteFromDefinition
(Surefire.java:147)
at org.apache.maven.surefire.Surefire.run(Surefire.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:225)
at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:747)
[INFO]
------------------------------------------------------------------------
----
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
----
===== The beta1 tag builds but will not pluto:install =======
The key here is that you need to clean out your maven repo before
doing install and pluto:install.
cd ~/.m2
rm -rf `find . -name '*SNAPSHOT*'`
If you don't clean this up and have been building from trunk, the
beta pluto:install *will* find the artifact and happily install the
wrong thing (i.e. not the recently compiled beta1) code.
[INFO]
------------------------------------------------------------------------
----
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
----
[INFO] Failed to resolve artifact.
GroupId: org.apache.pluto
ArtifactId: pluto-portal
Version: 1.1.0-SNAPSHOT
Reason: Unable to download the artifact from any repository
org.apache.pluto:pluto-portal:1.1.0-SNAPSHOT:war
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> Just in case anyone is wondering, I don't recommend that we modify the
> tag since it represents a release. Let's just upgrade the trunk.
+1
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by Elliot Metsger <em...@jhu.edu>.
Awesome,
I'll take a crack at this tonight (my wife is working late :) )
Elliot
David H. DeWolf wrote:
> yup. the maven resources plugin can help with filtering/replacement
> too. . .
>
>
> David
>
> Elliot Metsger wrote:
>>
>>
>> David H. DeWolf wrote:
>>
>> >
>> > Agreed. i think the maven resources plugin is what we want here.
>> Here's
>> > the JIRA for it:
>> >
>> > https://issues.apache.org/jira/browse/PLUTO-191
>>
>> In the past I've had a "version.properties" file sitting in the
>> resource directory, with property names like:
>> commons-logging.version=${commons-logging.version}
>>
>> The property names come from the pom.
>>
>> That file gets interpolated, and would be packaged up in the jar. So
>> you end up with a versions.properties file with
>> commons-logging.version = 1.0.4
>>
>> Then java code (i.e. the Pluto maven plugin) can query the properties
>> file for version information.
>>
>> Is this the approach you are thinking of David? Or is there a better
>> way? I can get started on this if you want.
>>
>> Elliot
>>
>>>
>>>
>>> Charles Severance wrote:
>>>
>>>>> The duplication of version numbers to all child pom.xml files is a
>>>>> pain. Is there a way of using a
>>>>> variable in the pom.xml project/parent/version element value for
>>>>> all the pluto-* modules?
>>>>
>>>> In Sakai, we got repeatedly killed by scattered constants - finally
>>>> we simply "included" something like ../project.xml for these
>>>> "variables" - that of course is Maven 1 speak - but until we
>>>> centralized this version nuber one place - we never could get
>>>> anything to properly release.
>>>>
>>>> It seemed that hard-coding *where* the constant came from (like
>>>> ../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
>>>>
>>>> /Chuck
>>>>
>>
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by Elliot Metsger <em...@jhu.edu>.
I agree, I don't think pluto needs to release artifacts independently
and scm does become more painful. The Maven project has to deal with
these issues as well.
Just wanted to raise the issue, because if it was important to release
independently, the maven pluto plugin would need to walk the pom of the
parent and sub-projects which would be more work to code :)
Elliot
Charles Severance wrote:
> Just some stories form Sakai.
>
> (1) We version all million lines of code and release *together*. When
> we branch or tag for releases - we immediately update the version in the
> tag/branch so we keep from being confused as many develop on several
> branches at the same time.
>
> (2) To the extent we want to version independently - we made each major
> module a separate SVN tied together by a single externals file - that
> allows independent branching and tagging of each major component. It is
> quite flexible and useful for a million lines of code - but not
> necessary here IMHO. Using this approach makes svn update trickier and
> you can get in trouble - so I would avoid it until you *really* need it.
>
> /Chuck
>
> On Aug 30, 2006, at 8:17 AM, David H. DeWolf wrote:
>
>> I think for now it's ok to release all together. I don't see a problem
>>
>> with this. As a matter of fact, we've never even discussed independent
>>
>> releases. Commit Away!
>>
>>
>> David
>>
>>
>> David
>>
>>
>> Elliot Metsger wrote:
>>
>>> David H. DeWolf wrote:
>>>
>>>> yup. the maven resources plugin can help with filtering/replacement
>>>> too. . .
>>>>
>>> Ok so I've done what I proposed below in my working copy (I haven't
>>> committed it yet).
>>>
>>> One problem with my solution is that you cannot version the Pluto
>>> artifacts independently of each other. I don't know if that is a
>>> problem or not.
>>>
>>> If that isn't a problem (or if it is a problem we can resolve later)
>>> I'll commit the patch, and of course feel free to change things
>>> around (you won't hurt my feelings) :-)
>>>
>>> Elliot
>>>
>
Re: Three problems in beta and trunk - trunk fails out of the box currently
Posted by Charles Severance <cs...@umich.edu>.
Just some stories form Sakai.
(1) We version all million lines of code and release *together*.
When we branch or tag for releases - we immediately update the
version in the tag/branch so we keep from being confused as many
develop on several branches at the same time.
(2) To the extent we want to version independently - we made each
major module a separate SVN tied together by a single externals file
- that allows independent branching and tagging of each major
component. It is quite flexible and useful for a million lines of
code - but not necessary here IMHO. Using this approach makes svn
update trickier and you can get in trouble - so I would avoid it
until you *really* need it.
/Chuck
On Aug 30, 2006, at 8:17 AM, David H. DeWolf wrote:
> I think for now it's ok to release all together. I don't see a
> problem
> with this. As a matter of fact, we've never even discussed
> independent
> releases. Commit Away!
>
> David
>
> David
>
> Elliot Metsger wrote:
>> David H. DeWolf wrote:
>>> yup. the maven resources plugin can help with filtering/
>>> replacement too. . .
>> Ok so I've done what I proposed below in my working copy (I
>> haven't committed it yet).
>> One problem with my solution is that you cannot version the Pluto
>> artifacts independently of each other. I don't know if that is a
>> problem or not.
>> If that isn't a problem (or if it is a problem we can resolve
>> later) I'll commit the patch, and of course feel free to change
>> things around (you won't hurt my feelings) :-)
>> Elliot
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by "David H. DeWolf" <dd...@apache.org>.
I think for now it's ok to release all together. I don't see a problem
with this. As a matter of fact, we've never even discussed independent
releases. Commit Away!
David
David
Elliot Metsger wrote:
>
>
> David H. DeWolf wrote:
>> yup. the maven resources plugin can help with filtering/replacement
>> too. . .
>
> Ok so I've done what I proposed below in my working copy (I haven't
> committed it yet).
>
> One problem with my solution is that you cannot version the Pluto
> artifacts independently of each other. I don't know if that is a
> problem or not.
>
> If that isn't a problem (or if it is a problem we can resolve later)
> I'll commit the patch, and of course feel free to change things around
> (you won't hurt my feelings) :-)
>
> Elliot
>
>>
>> David
>>
>> Elliot Metsger wrote:
>>>
>>>
>>> David H. DeWolf wrote:
>>>
>>> >
>>> > Agreed. i think the maven resources plugin is what we want here.
>>> Here's
>>> > the JIRA for it:
>>> >
>>> > https://issues.apache.org/jira/browse/PLUTO-191
>>>
>>> In the past I've had a "version.properties" file sitting in the
>>> resource directory, with property names like:
>>> commons-logging.version=${commons-logging.version}
>>>
>>> The property names come from the pom.
>>>
>>> That file gets interpolated, and would be packaged up in the jar. So
>>> you end up with a versions.properties file with
>>> commons-logging.version = 1.0.4
>>>
>>> Then java code (i.e. the Pluto maven plugin) can query the properties
>>> file for version information.
>>>
>>> Is this the approach you are thinking of David? Or is there a better
>>> way? I can get started on this if you want.
>>>
>>> Elliot
>>>
>>>>
>>>>
>>>> Charles Severance wrote:
>>>>
>>>>>> The duplication of version numbers to all child pom.xml files is a
>>>>>> pain. Is there a way of using a
>>>>>> variable in the pom.xml project/parent/version element value for
>>>>>> all the pluto-* modules?
>>>>>
>>>>> In Sakai, we got repeatedly killed by scattered constants - finally
>>>>> we simply "included" something like ../project.xml for these
>>>>> "variables" - that of course is Maven 1 speak - but until we
>>>>> centralized this version nuber one place - we never could get
>>>>> anything to properly release.
>>>>>
>>>>> It seemed that hard-coding *where* the constant came from (like
>>>>> ../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
>>>>>
>>>>> /Chuck
>>>>>
>>>
>
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> yup. the maven resources plugin can help with filtering/replacement
> too. . .
Ok so I've done what I proposed below in my working copy (I haven't
committed it yet).
One problem with my solution is that you cannot version the Pluto
artifacts independently of each other. I don't know if that is a
problem or not.
If that isn't a problem (or if it is a problem we can resolve later)
I'll commit the patch, and of course feel free to change things around
(you won't hurt my feelings) :-)
Elliot
>
> David
>
> Elliot Metsger wrote:
>>
>>
>> David H. DeWolf wrote:
>>
>> >
>> > Agreed. i think the maven resources plugin is what we want here.
>> Here's
>> > the JIRA for it:
>> >
>> > https://issues.apache.org/jira/browse/PLUTO-191
>>
>> In the past I've had a "version.properties" file sitting in the
>> resource directory, with property names like:
>> commons-logging.version=${commons-logging.version}
>>
>> The property names come from the pom.
>>
>> That file gets interpolated, and would be packaged up in the jar. So
>> you end up with a versions.properties file with
>> commons-logging.version = 1.0.4
>>
>> Then java code (i.e. the Pluto maven plugin) can query the properties
>> file for version information.
>>
>> Is this the approach you are thinking of David? Or is there a better
>> way? I can get started on this if you want.
>>
>> Elliot
>>
>>>
>>>
>>> Charles Severance wrote:
>>>
>>>>> The duplication of version numbers to all child pom.xml files is a
>>>>> pain. Is there a way of using a
>>>>> variable in the pom.xml project/parent/version element value for
>>>>> all the pluto-* modules?
>>>>
>>>> In Sakai, we got repeatedly killed by scattered constants - finally
>>>> we simply "included" something like ../project.xml for these
>>>> "variables" - that of course is Maven 1 speak - but until we
>>>> centralized this version nuber one place - we never could get
>>>> anything to properly release.
>>>>
>>>> It seemed that hard-coding *where* the constant came from (like
>>>> ../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
>>>>
>>>> /Chuck
>>>>
>>
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by "David H. DeWolf" <dd...@apache.org>.
yup. the maven resources plugin can help with filtering/replacement
too. . .
David
Elliot Metsger wrote:
>
>
> David H. DeWolf wrote:
>
> >
> > Agreed. i think the maven resources plugin is what we want here. Here's
> > the JIRA for it:
> >
> > https://issues.apache.org/jira/browse/PLUTO-191
>
> In the past I've had a "version.properties" file sitting in the resource
> directory, with property names like:
> commons-logging.version=${commons-logging.version}
>
> The property names come from the pom.
>
> That file gets interpolated, and would be packaged up in the jar. So
> you end up with a versions.properties file with
> commons-logging.version = 1.0.4
>
> Then java code (i.e. the Pluto maven plugin) can query the properties
> file for version information.
>
> Is this the approach you are thinking of David? Or is there a better
> way? I can get started on this if you want.
>
> Elliot
>
>>
>>
>> Charles Severance wrote:
>>
>>>> The duplication of version numbers to all child pom.xml files is a
>>>> pain. Is there a way of using a
>>>> variable in the pom.xml project/parent/version element value for all
>>>> the pluto-* modules?
>>>
>>> In Sakai, we got repeatedly killed by scattered constants - finally
>>> we simply "included" something like ../project.xml for these
>>> "variables" - that of course is Maven 1 speak - but until we
>>> centralized this version nuber one place - we never could get
>>> anything to properly release.
>>>
>>> It seemed that hard-coding *where* the constant came from (like
>>> ../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
>>>
>>> /Chuck
>>>
>
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
>
> Agreed. i think the maven resources plugin is what we want here. Here's
> the JIRA for it:
>
> https://issues.apache.org/jira/browse/PLUTO-191
In the past I've had a "version.properties" file sitting in the resource
directory, with property names like:
commons-logging.version=${commons-logging.version}
The property names come from the pom.
That file gets interpolated, and would be packaged up in the jar. So
you end up with a versions.properties file with
commons-logging.version = 1.0.4
Then java code (i.e. the Pluto maven plugin) can query the properties
file for version information.
Is this the approach you are thinking of David? Or is there a better
way? I can get started on this if you want.
Elliot
>
>
> Charles Severance wrote:
>
>>> The duplication of version numbers to all child pom.xml files is a
>>> pain. Is there a way of using a
>>> variable in the pom.xml project/parent/version element value for all
>>> the pluto-* modules?
>>
>> In Sakai, we got repeatedly killed by scattered constants - finally we
>> simply "included" something like ../project.xml for these "variables"
>> - that of course is Maven 1 speak - but until we centralized this
>> version nuber one place - we never could get anything to properly
>> release.
>>
>> It seemed that hard-coding *where* the constant came from (like
>> ../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
>>
>> /Chuck
>>
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by "David H. DeWolf" <dd...@apache.org>.
Charles Severance wrote:
>> The duplication of version numbers to all child pom.xml files is a
>> pain. Is there a way of using a
>> variable in the pom.xml project/parent/version element value for all
>> the pluto-* modules?
>
> In Sakai, we got repeatedly killed by scattered constants - finally we
> simply "included" something like ../project.xml for these "variables" -
> that of course is Maven 1 speak - but until we centralized this version
> nuber one place - we never could get anything to properly release.
>
> It seemed that hard-coding *where* the constant came from (like
> ../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
>
> /Chuck
>
Agreed. i think the maven resources plugin is what we want here. Here's
the JIRA for it:
https://issues.apache.org/jira/browse/PLUTO-191
David
Re: Three problems in beta and trunk - trunk fails out of the box currently
Posted by Charles Severance <cs...@umich.edu>.
On Aug 28, 2006, at 10:27 AM, CDoremus@hannaford.com wrote:
> Last Wednesday I did commit a patch to the PortalURLParser class
> that was submitted by David Hay in PLUTO-246. Before the commit, I
> made sure the trunk built without error and the testsuite passed
> all its tests. I will also try to take a look at this issue
> tonight. If this is a real issue, maybe we need an addition to the
> testsuite to test for it.
It builds fine, comes up fine (the default pages render beautifully)
but when you switch pages on the drop-down it happens. My patch is a
workaround but not likely the right thing in the long run.
> I did a build this morning on Windows 2000 without any problems
> using Maven 2.0.4.
Ah - I am MVN 2.0 - Shall make that change and report back.
> The duplication of version numbers to all child pom.xml files is a
> pain. Is there a way of using a
> variable in the pom.xml project/parent/version element value for
> all the pluto-* modules?
In Sakai, we got repeatedly killed by scattered constants - finally
we simply "included" something like ../project.xml for these
"variables" - that of course is Maven 1 speak - but until we
centralized this version nuber one place - we never could get
anything to properly release.
It seemed that hard-coding *where* the constant came from (like ../
xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
/Chuck
Re: Three problems in beta and trunk - trunk fails out of the box currently
Posted by CD...@hannaford.com.
"David H. DeWolf" <dd...@gmail.com> wrote on 08/28/2006 07:56:00 AM:
>
>
> Charles Severance wrote:
>
> >
> > The trunk has a bug where PageId's end up with a prefix of a "/" and
so
> > the configuration can never find find pages - and things blow up
horribly.
>
> Are you seeing this with the trunk? Craig committed a patch that seems
> related just a few days ago. I'll take a look at it tonight if you
are.
>
Last Wednesday I did commit a patch to the PortalURLParser class that was
submitted by David Hay in PLUTO-246. Before the commit, I made sure the
trunk built without error and the testsuite passed all its tests. I will
also try to take a look at this issue tonight. If this is a real issue,
maybe we need an addition to the testsuite to test for it.
> >
> > ======= Neither trunk nor beta1 will build unless maven.test.skip=true
> > ========
> >
>
> I can't duplicate this. It builds fine for me on the following:
>
> - Mac OSX - upon which it was never before installed
> - Windows XP - upon which it has been installed before
>
> Both using: Maven version: 2.0.4
>
I did a build this morning on Windows 2000 without any problems using
Maven 2.0.4.
> >
> >
> > ===== The beta1 tag builds but will not pluto:install =======
> >
> > The key here is that you need to clean out your maven repo before
doing
> > install and pluto:install.
> >
> > cd ~/.m2
> > rm -rf `find . -name '*SNAPSHOT*'`
> >
>
> This is because we're using 1.1.0-SNAPSHOT as the version in trunk which
> has been hard coded (yuck) in the install goal as the dependent
> version. I recommend that we look into finding a more elegant
> approach to managing plugin dependencies.
>
> Just in case anyone is wondering, I don't recommend that we modify the
> tag since it represents a release. Let's just upgrade the trunk.
>
The duplication of version numbers to all child pom.xml files is a pain.
Is there a way of using a
variable in the pom.xml project/parent/version element value for all the
pluto-* modules?
>
> David
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by "David H. DeWolf" <dd...@apache.org>.
Charles Severance wrote:
>
> The trunk has a bug where PageId's end up with a prefix of a "/" and so
> the configuration can never find find pages - and things blow up horribly.
Are you seeing this with the trunk? Craig committed a patch that seems
related just a few days ago. I'll take a look at it tonight if you are.
>
> ======= Neither trunk nor beta1 will build unless maven.test.skip=true
> ========
>
I can't duplicate this. It builds fine for me on the following:
- Mac OSX - upon which it was never before installed
- Windows XP - upon which it has been installed before
Both using: Maven version: 2.0.4
>
>
> ===== The beta1 tag builds but will not pluto:install =======
>
> The key here is that you need to clean out your maven repo before doing
> install and pluto:install.
>
> cd ~/.m2
> rm -rf `find . -name '*SNAPSHOT*'`
>
This is because we're using 1.1.0-SNAPSHOT as the version in trunk which
has been hard coded (yuck) in the install goal as the dependent
version. I recommend that we look into finding a more elegant
approach to managing plugin dependencies.
Just in case anyone is wondering, I don't recommend that we modify the
tag since it represents a release. Let's just upgrade the trunk.
David
Re: Three problems in beta and trunk - trunk fails out of the box currently
Posted by Charles Severance <cs...@umich.edu>.
Craig,
All set http://issues.apache.org/jira/browse/PLUTO-251
By the way - I can compile with the testsuite not that I have updated
to maven 2.0.4 as you had guessed.
Thanks.
/Chuck
On Aug 28, 2006, at 10:57 AM, CDoremus@hannaford.com wrote:
>
> Thanks for this patch. Would you mind submitting this to Jira
> (http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10560)
> so we can
> properly keep track of this issue? It also would be helpful if you
> submit
> a patch file so we can apply your fix properly. Creating a patch
> file is pretty
> easy if you are using Eclipse and the subeclipse plugin.
>
Re: Three problems in beta and trunk - trunk fails out of the box
currently
Posted by "David H. DeWolf" <dd...@apache.org>.
Charles Severance wrote:
> Craig - I will make a JIRA, clean up my patch, and submit it. The print
> statements are not appropriate for a real patch.
>
> I will have to figure out how to make a patch the hard way - my IDE is
> a combination of vi, find and grep - I never have to worry when I
> mistakenly lose a toolbar and cannot figure out how to get it back :)
>
Hey! That used to be my IDE too. . .until I found IntelliJ. There's a
great VI plugin for it that makes it worthwhile.
To create a patch simply do:
svn di > patch-file.dif
David
PS: Diagrams should come tommorrow
Re: Three problems in beta and trunk - trunk fails out of the box currently
Posted by Charles Severance <cs...@umich.edu>.
Craig - I will make a JIRA, clean up my patch, and submit it. The
print statements are not appropriate for a real patch.
I will have to figure out how to make a patch the hard way - my IDE
is a combination of vi, find and grep - I never have to worry when I
mistakenly lose a toolbar and cannot figure out how to get it back :)
/Chuck
On Aug 28, 2006, at 10:57 AM, CDoremus@hannaford.com wrote:
>
> See below:
>
> Charles Severance <cs...@umich.edu> wrote on 08/27/2006 11:19:08 PM:
> >
> > ==== Bug in pageId lookup in trunk ======
> >
> > This worked about a week ago - so I am thinking something recent
> > happenned when I did an svn update.
> >
> > The trunk has a bug where PageId's end up with a prefix of a "/" and
> > so the configuration can never find find pages - and things blow up
> > horribly.
> >
> > To reproduce - simply bring up pluto, log in as tomcat, and navigate
> > to a page other than the default using the dropdown.
> >
> > The fix is below:
> >
> > vi pluto-portal-driver/src/main/java/org/apache/pluto/driver/
> services/
> > portal/RenderConfig.java
> >
> > public PageConfig getPageConfig(String pageId) {
> > if (pageId == null || "".equals(pageId)) {
> > if (LOG.isDebugEnabled()) {
> > LOG.debug(
> > "Requested page is null. Returning default:
> " +
> > defaultPageId);
> > }
> > pageId = defaultPageId;
> > }
> > PageConfig retval = (PageConfig) pages.get(pageId);
> > // TODO: Fix Hack
> > if ( retval == null && pageId.startsWith("/") &&
> > pageId.length() > 2 ) {
> > System.out.println("HACK ALert - Trimming off slash
> > " + pageId.substring(1));
> > retval = (PageConfig) pages.get(pageId.substring
> (1));
> > }
> > System.out.println("retval = " + retval);
> > return retval;
> > }
> >
> > [DEBUG] PortalURLParser - Parsing URL: /pluto/portal/Pluto%20Admin
> > [DEBUG] PortalURLParser - Parsing request pathInfo: /Pluto Admin
> > [DEBUG] PortalDriverServlet - Processing render request.
> > [DEBUG] PortalDriverServlet - Rendering Portal: Requested Page: /
> > Pluto Admin
> > HACK ALert - Trimming off slash Pluto Admin
> > retval = org.apache.pluto.driver.services.portal.PageConfig@f50e8d
> >
>
> Thanks for this patch. Would you mind submitting this to Jira
> (http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10560)
> so we can
> properly keep track of this issue? It also would be helpful if you
> submit
> a patch file so we can apply your fix properly. Creating a patch
> file is pretty
> easy if you are using Eclipse and the subeclipse plugin.
Re: Three problems in beta and trunk - trunk fails out of the box currently
Posted by CD...@hannaford.com.
See below:
Charles Severance <cs...@umich.edu> wrote on 08/27/2006 11:19:08 PM:
>
> ==== Bug in pageId lookup in trunk ======
>
> This worked about a week ago - so I am thinking something recent
> happenned when I did an svn update.
>
> The trunk has a bug where PageId's end up with a prefix of a "/" and
> so the configuration can never find find pages - and things blow up
> horribly.
>
> To reproduce - simply bring up pluto, log in as tomcat, and navigate
> to a page other than the default using the dropdown.
>
> The fix is below:
>
> vi pluto-portal-driver/src/main/java/org/apache/pluto/driver/services/
> portal/RenderConfig.java
>
> public PageConfig getPageConfig(String pageId) {
> if (pageId == null || "".equals(pageId)) {
> if (LOG.isDebugEnabled()) {
> LOG.debug(
> "Requested page is null. Returning default: " +
> defaultPageId);
> }
> pageId = defaultPageId;
> }
> PageConfig retval = (PageConfig) pages.get(pageId);
> // TODO: Fix Hack
> if ( retval == null && pageId.startsWith("/") &&
> pageId.length() > 2 ) {
> System.out.println("HACK ALert - Trimming off slash
> " + pageId.substring(1));
> retval = (PageConfig) pages.get(pageId.substring(1));
> }
> System.out.println("retval = " + retval);
> return retval;
> }
>
> [DEBUG] PortalURLParser - Parsing URL: /pluto/portal/Pluto%20Admin
> [DEBUG] PortalURLParser - Parsing request pathInfo: /Pluto Admin
> [DEBUG] PortalDriverServlet - Processing render request.
> [DEBUG] PortalDriverServlet - Rendering Portal: Requested Page: /
> Pluto Admin
> HACK ALert - Trimming off slash Pluto Admin
> retval = org.apache.pluto.driver.services.portal.PageConfig@f50e8d
>
Thanks for this patch. Would you mind submitting this to Jira (
http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10560) so we
can
properly keep track of this issue? It also would be helpful if you submit
a patch file so we can apply your fix properly. Creating a patch file is
pretty
easy if you are using Eclipse and the subeclipse plugin.