You could remove my committer-ship if you want, and that makes the list
somehow cleaner for you. I have not committed anything recently.
However, I do believe I am still an active member of the community.
Cris J H
On 11/07/2014 07:08 AM, Andrew Petro wrote:
uPortal committers,
These
One thing I think is important to look at with the 'build' system in
uPortal, is there has long been parts of the system that have nothing to
do with 'building'. Take a simple example, like adding a new fragment
to uPortal from a fragment definition file. This does not need to be
tied to the
would be most welcome.
-Original Message-
From: bounce-37554527-57692...@lists.wisc.edu [mailto:bounce-37554527-
57692...@lists.wisc.edu] On Behalf Of Cris J Holdorph
Sent: Friday, November 7, 2014 9:11 AM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Moving away from Ant/Maven
One other 'con' I'd like to bring up, besides Josh's (which I agree 100%
with), is the following.
I find inconsistent style frustrating, true. But what I find even more
frustrating is when I'm trying to debug and I want to know why a line of
code was last changed.
If you reformat the
Personally I think spending more time on getting rid of all the 'Ant'
related parts would be a lot better then trying to break up uPortal into
even smaller pieces.
I understand the aspect you mention about disabling tests because they
take so long, and if the tests took less time, then maybe
a
50-minute mark set for public projects on their free plan) now complete in
less than 20 minutes, give or take.
-Original Message-
From: bounce-37470921-57692...@lists.wisc.edu
[mailto:bounce-37470921-57692...@lists.wisc.edu] On Behalf Of Cris J
Holdorph
Sent: Tuesday, October 28, 2014 10:49
Why is it needed at all?
What settings exist in the jasig parent pom that uPortal and cas truly
need to share?
I just took at look at it, and I don't see very much, if anything in
that file that both CAS and uPortal need to be on the same version with,
except for one item, which is wrong as
the disagreement.
Can you give an example of a change between kinds of versions that
Semantic Versioning would allow but the description in UP-4146 would
forbid, or vice versa?
Andrew
On 6/19/14, 12:10 PM, Cris J Holdorph wrote:
There seems to be a difference in the Semantic Versioning you quoted
and what you
-compatible footer toggle adding
GumGum integration, after 4.2.0 is released, that new feature could come
into master towards 4.3.0, but it could not come into 4.2-patches
towards 4.2.1.
Clarifying?
Andrew
On 6/19/14, 12:46 PM, Cris J Holdorph wrote:
2. Semantic versioning says you add
This is probably not your problem, but I thought I would share some
recent experience with maven, repositories and dependency debugging.
I was trying to set up a local artifact repository to do mirroring of
maven dependencies. This is useful for dependencies that are not in
central, that
but
it is very much worth it long term to avoid this sort of dependency hell
pain.
On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph holdo...@unicon.net
mailto:holdo...@unicon.net wrote:
This is probably not your problem, but I thought I would share some
recent experience with maven
are entirely realizable
via only-in-Central dependencies, the better.
:)
Kind regards,
Andrew
On 6/13/14, 12:54 PM, Cris J Holdorph wrote:
It's not just a simple matter of putting YOUR dependencies into
central and not putting repositories into YOUR pom files. With
transitive dependencies
valuable.
Being able to always reproduce previous builds and insulating your build
process from external failures is quite valuable.
On Fri, Jun 13, 2014 at 11:09 AM, Cris J Holdorph holdo...@unicon.net
mailto:holdo...@unicon.net wrote:
Well yes, that's all good and definitely encouraged for any
Does it allow someone to connect from their existing chat client, like
pidgin?
Cris J H
On 04/18/2014 12:17 PM, Andrew Petro wrote:
uPortal committers,
As an experiment only (so far), let's check this out:
https://gitter.im/Jasig/uPortal
It *doesn't* seem to have the robust chat
Removing dead-unused code is a common practice. If the code is used
that changes the equation. My impression from Drew's original post and
his followup response, was that he did not know of anyone actively using
it. Therefore it would be dead-unused code.
Cris J H
On 12/10/2013 02:15
This is probably a more appropriate discussion for 'uportal-user'.
'uportal-dev' is for discussion of the uPortal core framework Java code.
In any case, can you include the 'setenv.sh' you put in the directory as
an attachment. I wonder if there is a kind of typo or whitespace
problem in
I recommend adding James Wennmacher ( jwennmac...@unicon.net ).
Cris J H
On 10/25/2013 07:13 AM, Jim Helwig wrote:
I think I have the power but lack the knowledge. (Always a dangerous
thing). Recommendations on who might best be in a position to be added
to the admin list?
Also, it seems
I don't want to derail the current vote. But after a couple of these
proposals have come through I thought it was time to share a thought.
Most of these votes I have had no basis to support an opinion on. Other
then maybe the person who was doing the recommendation.
In the future, it would
Sakai uses a very similar approach and has very similar messages in
their logs. While uPortal could certainly do better, I don't think in
this case, it's anything to worry too much about. Especially when the
extremely simple fix is just to create an empty file for it to 'find' if
you're that
I'm dealing with this every day in another project and it drives me
bonkers. I vote not just for the $Revision$ keyword removal, but for
ALL svn keywords to be removed. They are an annoyance when trying to diff.
+1 even if this is limited to just the $Revision$ keyword.
Cris J H
On
have pain with diffs so doing
this for the next 4.0 release might not be any more disruptive than the
keywords already are. Thoughts on when we should do this?
-Eric
On 04/10/2012 11:06 AM, Cris J Holdorph wrote:
I'm dealing with this every day in another project and it drives me
bonkers. I vote
I got an email from github that said:
View team: https://github.com/organizations/Jasig/teams/68892
but when I got there, I get a github 404.
Any ideas?
Cris J H
On 10/13/2011 02:20 PM, Eric Dalquist wrote:
Details of the uPortal SVN to GitHub migration, reasoning, and FAQ is in
the
/13/11 5:06 PM, Cris J Holdorph wrote:
I got an email from github that said:
View team: https://github.com/organizations/Jasig/teams/68892
but when I got there, I get a github 404.
Any ideas?
Cris J H
On 10/13/2011 02:20 PM, Eric Dalquist wrote:
Details of the uPortal SVN to GitHub
. That should let everyone
get the work they are doing out into a visible location earlier in the
development cycle and keep trunk (master) more stable.
-Eric
On 10/13/11 6:12 PM, Cris J Holdorph wrote:
I don't see any way to submit a pull request for
https://github.com/Jasig/svn2git-migration
Cris
+/- 0
I think making this change so soon after the uPortal 4.0.0 release, is a
mistake. I think it would be better to let that release simmer for a
while to shake out if there were any major problems.
If this vote was to take place in a month, or at least 2 weeks after
some university was
as
possible after 4.0 would be better as it would give more time for
developers to get used to the change before a 4.0.1 is needed.
-Eric
On 8/31/11 3:05 PM, Cris J Holdorph wrote:
+/- 0
I think making this change so soon after the uPortal 4.0.0 release, is
a mistake. I think it would be better
minus custom ichannel support. So, if you have custom ichannels and do
an export, those channels will not import into uPortal 4.0+
Cris J H
On 05/05/2011 05:02 PM, Eric Dalquist wrote:
3.3 == 4.0
Just like you said, we decided that with so much work being done in 3.3,
primarily around
If you're going to rename them, is there a significant reason to even
leave the '.channel' in the middle? To me this always felt like an
unneeded complication when the 'type' was in the XML content to begin
with. And in the case of uPortals own set of entity files it has them
in
, Cris J Holdorph wrote:
If you're going to rename them, is there a significant reason to even
leave the '.channel' in the middle? To me this always felt like an
unneeded complication when the 'type' was in the XML content to begin
with. And in the case of uPortals own set of entity files it has them
Can you describe why you want to use JSF?
Cris J H
On 11/22/2010 08:59 AM, Frédéric Ravetier wrote:
Hello,
I am the project manager for the ESUP Mobile Project, working at
Anyware-Services.
We started the development last week. Our first portlet is a portlet to
display messages (email
.
Otherwise we would have choice something else because it is not our
favorite Framework.
Why this question?
Regards,
Fred
Le 22/11/2010 17:05, Cris J Holdorph a écrit :
Can you describe why you want to use JSF?
Cris J H
On 11/22/2010 08:59 AM, Frédéric Ravetier wrote:
Hello,
I am
that fixed? I think it affect trunk, 3.2, 3.1 and 3.0
-Eric
On 8/6/10 1:19 PM, Cris J Holdorph wrote:
Please take a look at uPortal 3.2.2 the file:
uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java
Specifically lines 1893-1903...
They look like this:
final
in the log:
https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21106
https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21102
https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21023
-Eric
On 8/6/10 12:52 PM, Cris J Holdorph wrote:
I was looking at a bug
What do you mean it will leak the refresh thread? Won't the thread
complete and then die? I didn't think the thread lived on forever, but
only for as long as it took to refresh the group tree one time.
But I agree, if quartz is available, that's what quartz is good at and
I'd strongly
multiple places to
change all of the time based tasks? Wouldn't it be useful to have all
of the time based configuration in the one quartz subsystem?
Cris J H
On 08/06/2010 11:34 AM, Drew Wills wrote:
On 8/6/2010 11:10 AM, Cris J Holdorph wrote:
What do you mean it will leak the refresh
I was looking at a bug Unicon ran across trying to upgrade someone from
uPortal 3.2.1 to 3.2.2.
In tracking this bug down, I noticed that the svn log information did
not match fisheye.
compare this URL in a browser
Please take a look at uPortal 3.2.2 the file:
uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java
Specifically lines 1893-1903...
They look like this:
final ResultSet rs2 = pstmt2.executeQuery();
try {
This probably belongs on uportal-user. The 'uportal-dev' list is for
discussion of changes to the core uPortal framework code base.
If you create a new post on uPortal-user, can you describe how your
users might use the portal? Will they single-click in, and then leave
the portal. Do you
I think it would be worth attaching the 3.1 patch to the Jira issue, so
anyone who wants access to the feature sooner could grab it for their
own system.
Cris J H
On 06/15/2010 11:34 AM, Eric Dalquist wrote:
That is the way to go. Generally the following steps should work well:
1.
Unicon News, is broken in uPortal 3.2.x. This is documented with UP-2704
Cris J H
Gary Weaver wrote:
Some issues seen from cursory browsing of default uPortal trunk build currently:
In News section:
* uPortal-Powered Sites (error: This channel failed to accept needed data)
* Unicon News
Did you do the subversion add from the command line or from eclipse?
If from eclipse, does anyone know if subclipse will use/pick up those
parts of the subversion config file?
Cris J H
Nicholas Blair wrote:
I have the uportal subversion config file from
bug that appears
when using the gnome-keyring:
password-stores =
On Sun, Feb 28, 2010 at 11:39 AM, Cris J Holdorph holdo...@unicon.net wrote:
Did you do the subversion add from the command line or from eclipse?
If from eclipse, does anyone know if subclipse will use/pick up those parts
I proposed him, so I think that's an implicit +1 from me.
Here it is explicitly if needed.
+1
Cris J H
- Original Message -
From: Eric Dalquist eric.dalqu...@doit.wisc.edu
To: uportal-dev@lists.ja-sig.org
Sent: Saturday, January 30, 2010 9:19:04 PM GMT -07:00 U.S. Mountain Time
Yes, I have a file like that config in place. It's not the exact same
one as uportal, but one I've used from Sakai for a while. It is nearly
the same. I'll resolve the few differences (adding a couple of uportal
file types like .cpd) in the mean time.
Cris J H
Eric Dalquist wrote:
So
Ok, I resolved the diffs between the uportal config and the config i was
using. The only difference that remains, is I use this in my file as
well under the [miscellany] section
global-ignores=bin target m2-target
Cris J H
Cris J Holdorph wrote:
Yes, I have a file like that config
How do people feel about JDK support and uPortal?
Sun has dropped support for JDK 5 back in October. We have the next
major release of uPortal, 3.2, coming out as a release candidate
shortly. Recently a bug was introduced by some code that only built
with JDK 6.
Is it worth considering
Code will have to abide by the new licensing policy (signed agreements
included) to leave incubation. There is still the option for code to
live in the sandbox that never becomes a fully supported (into and out
of incubation) Jasig project.
Cris J H
Gary Weaver wrote:
Curious- will
You should make sure to send these comments on to the suggested email
address.
jasig-licens...@lists.jasig.org
I'm not certain if the people that requested feedback watch this list
too closely or not.
Cris J H
Gary Weaver wrote:
Something else I thought of if it helps is that
are you sure it's closed? what is the issue number? It would be above
the operations section if it's closed.
Cris J H
Aaron Brown wrote:
Cris J Holdorph wrote:
If you're logged in, you should simply see a Reopen Issue under the
Available Workflow Actions in the left hand menu. You
For 2235, I see an option for Reopen Issue right above the word
Operations. You sure, you're not seeing that?
Cris J H
Aaron Brown wrote:
Cris J Holdorph wrote:
are you sure it's closed? what is the issue number? It would be above
the operations section if it's closed.
http
:
Cris J Holdorph wrote:
are you sure it's closed? what is the issue number? It would be above
the operations section if it's closed.
http://www.ja-sig.org/issues/browse/UP-2235
You may be right - it's marked as fixed / resolved, but if Jira
doesn't equate that with Closed, then that could
+1
Andrew Petro wrote:
uPortal developers,
I'd like to nominate Jen Bourey as a uPortal developer representative to
the uPortal Steering Committee.
I believe Jen needs no introduction to the community of uPortal
committers, but I'd nonetheless take a moment to remind of her recent
and
simply tell people they'll have to hand edit their
channel files, before they reimport, but that seems kind of like a poor
workaround.
Cris J H
Eric Dalquist wrote:
I believe the export scripts are unaffected by these changes. Are they
failing for you?
Cris J Holdorph wrote:
you might want
+1 for removing the old CChannelManager and switching over to the new
one in trunk.
I don't say this lightly either. I know there is some risk here, but I
think this is a HUGE improvement and is worth the risk.
Cris J H
Jen Bourey wrote:
Hi all,
The new Portlet Administration
I'm a fan of fixing the stuff reported by FindBugs. However, there are
some things to be careful of.
Too much code change can sometimes have the reverse effect that was
intended. In certain cases '2 bugs' could be working together to cause
the end code to actually function. So if you only
sounds like a good idea to me.
Cris J H
Jen Bourey wrote:
Hi all,
I'd like to update the uPortal trunk to Fluid 1.0 this evening, unless
anyone has any objections. I think doing this update now will give us
lots of time to perform CSS integration and testing, as well as keep us
in
I find the anchors extremely annoying and turn them off whenever I
remember to. So the more places they are off by default, the better for
me :)
Cris J H
Eric Dalquist wrote:
Currently if the 'org.jasig.portal.ChannelManager.use_anchors' property
is true all render portlet URLs will be
This is probably a question for uportal-user. Before you post there,
you should probably include which version of uportal (e.g., 3.0.2),
which browserversion and confirm that you have javascript enabled.
Cris J H
Nathan Mcilree wrote:
Hi whenever I click on the add content link the box
if possible we should set up a http redirect for the old url. the old code will
still be out there.
- Original Message -
From: Eric Dalquist eric.dalqu...@doit.wisc.edu
To: uportal-dev@lists.ja-sig.org
Sent: Wed, 18 Feb 2009 11:09:48 -0700 (MST)
Subject: Re:[uportal-dev]
the jira issues are hyperlinked in his comments.
Cris J H
Eric Dalquist wrote:
Thanks for the reminder Arlo, I'll see if I can dig into the DLM issue.
Would you happen to have a list of Jira issue ids for those patches?
Thanks a lot!
-Eric
Arlo White wrote:
The biggest concern I have
I'm in favor of this change. I do not use the revision numbers for
anything specific. I do use the history, that you say will be
preserved. Removing empty revisions, makes querying the revision
history easier, so big +1 from me as well.
Cris J H
Eric Dalquist wrote:
We're getting
clean then an ant initportal, fixed my problem.
While the above is certainly not a common case, what do people think
about having ant clean be a dependency for ant initportal ?
Cris J H
Cris J Holdorph wrote:
Before I start chasing this down, I thought I would ask here to see
behavior from 2.x
-Eric
Cris J Holdorph wrote:
Ok, I was a little misleading when I said relatively fresh checkout.
It was an older checkout, but with a brand new 'svn update' and a run
of 'svn status' to make sure I had not modified anything.
Anyway, the problemm turns out that 'ant initportal
with old files in the
target directory will result in those old files being included in your
final artifact.
-Eric
Cris J Holdorph wrote:
Consistent, but only to a certain extent. We did not have the same
maven-multi-project+ant situation in uPortal 2.x. The problem is not
the same
I can't help with your greater problem but to the smaller one...
The code you included could run the outside finally block only, if the
m_authenticationService.authenticate() method throws an exception. In
this case, the call stack ends abnormally, so it never tries the next
normal line of
value of foo is: + foo.toString());
}
}
finally {
System.out.println(the outer value of foo is: + foo);
}
Would only print:
the outer value of foo is: null
The inner statement would not print, instead it would throw a
nullpointerexception.
Cris J H
George Lindholm wrote:
Cris J
Last I knew, the uPortal community was interested in supporting WSRP,
but no one had the availability to work on this effort. Maybe I missed,
some discussion though.
Cris J H
Kris Easter wrote:
There is a thread from earlier this year:
I wonder if we should consider some list renaming.
People consistently post to uportal-dev with questions that are about
them developing their portal. Look at the list name, think about what
those people are doing, it's really not a stretch. uportal-user
sounds like it might be for people
Also, when I do following, I have
C:\uPortal-3.0.1-quick-startant deployPortletApp -DportletApp=all
Buildfile: build.xml
BUILD FAILED
Target `deployPortletApp' does not exist in this project.
Thanks,
Edward
Cris J Holdorph wrote:
Did you run the ant deployPortletApp ant target, or did you just
Can you see anything wrong?
Thanks,
Edward
Cris J Holdorph wrote:
Can you try instead of
C:\uPortal-3.0.1-quick-start\uPortal-3.0.1ant deployPortletApp
-DportletApp=all
to do
C:\uPortal-3.0.1-quick-start\uPortal-3.0.1ant deployPortletApp
-DportletApp=c:\the\path\to\your\portlet_web.war
This sounds like it could be a pretty big upgrade path for a lot of
organizations using uPortal. How does everyone feel about this?
I'm all for moving onward with the later releases of the servlet spec
and in particular later releases of Tomcat, but I'm curious how places
that will likely
+1
Drew Wills wrote:
Hey folks,
I'd like to make a modest enhancement to DLM. I've prepared a JIRA and
a patch (attached to JIRA): http://www.ja-sig.org/issues/browse/UP-2117
Here's the description...
*
DLM already has the ability to remove channels that the user isn't
authorized to
I agree with Eric, that it should NOT be enabled by default, until the
appropriate maintenance code to accompany it is also written. The
maintenance code could be a simple quartz job, that truncates the table
after so many (configurable) days. That combined with logging a select
number of
and give great weight to Eric Dalquist's
perspective, since he's most recently been closely involved in the
distribution build process automation.
Andrew
Cris J Holdorph wrote:
This is something I see all the time in addition to the number of
times it comes up on the list.
What do people
I agree. I think 4 is the best solution for most situations.
Cris J H
Eric Dalquist wrote:
I vote for 4 as the default behavior.
-Eric
Jen Bourey wrote:
Hi all,
I've mostly completed (but not checked in) work on
http://www.ja-sig.org/issues/browse/UP-2027. This ticket describes
This is something I see all the time in addition to the number of times
it comes up on the list.
What do people think about the advantages/disadvantages of changing our
distribution format.
I know just about any other format would require someone to install a
tool they probably don't have
+1
Eric Dalquist wrote:
I'd like to propose making Tuy a uPortal committer, she has provided
several high-quality patches and enhancements to uPortal 3.0 both pre
and post release and it would be good to have her committing these on
her own.
-Eric
As a reminder votes need three positive
for uPortal
in general please say-so we can always do these local-only first and go
from there. I'd just rather do it in uPortal core and forgo the
local-only step if everyone is comfortable with that.
-Eric
Cris J Holdorph wrote:
I think a new Portlet Window for the same portlet entity is the right
What's the motivation behind the 'human readable' part? Do you expect,
(as a student) I can read the URL, that at some point in the future,
I'll simply type in
http://myportal.myuniv.edu/supercooltab/someportlet
in my address bar, because I remember I have a supercool tab and I put
some
I think I'm confused by what you said here. You said you changed
defaultTemplateUser and gave one of the reasons why, because you didn't
think that all users should be added to the developer group. Then you
ask if we should put the new template user in the developer group. What
am I
the issue of how do we make new
users appear to be in the Everyone group without loading up the database.
-Eric
Cris J Holdorph wrote:
I think I'm confused by what you said here. You said you changed
defaultTemplateUser and gave one of the reasons why, because you
didn't think that all users
It doesn't look like this happened. Did it? I still only see the up2
entry.
Cris J H
Eric Dalquist wrote:
Thursday morning around 9am CDT the up2 folder in Subversion will be
renamed to uPortal; https://www.ja-sig.org/svn/up2 to
https://www.ja-sig.org/svn/uPortal After the rename you
ah, reading comprehension thanks for pointing out the obvious.
Sorry everyone.
Cris J H
Jen Bourey wrote:
I think it's scheduled for tomorrow morning.
- Jen
On Wed, Mar 26, 2008 at 12:16 PM, Cris J Holdorph [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
It doesn't look
I disagree to an extent. I think continuing to use the term Channel
reinforces the past. When people look to adopt a portal, what are they
going to think if they see one Portal that is portlet based and one
that is 'proprietary channel' based. I feel like reducing the
visibility/use of the
I know it hasn't happened yet, might not happen, and if it did
happen we should have time to react to it before it causes us a problem...
However, I wonder about the Microsoft bid for Yahoo and if Microsoft
does acquire Yahoo, what they will think about that list. Is there an
equivalent out
I'm sure someone else will chime in with a longer response. My best
suggestion is to take a look at some of the more recent bugs entered
into Jira against the uPortal project.
http://www.ja-sig.org/issues/secure/BrowseProjects.jspa
Find a bug you are both interested in seeing fixed, and one
I don't think this portlet should ship WITH uPortal. I'd hate to see
the main uPortal distribution encumbered with a license we somehow have
to make sure commercial entities see and agree to, and contact
accuweather, before they can ever start uPortal. Now as a separate
download that people
Ok, I'm asking here, because my main purpose for doing this is to
benefit the uPortal community. Although, it's not a specific uPortal
question.
I am currently the maintainer of a Google Portlet on the
code.google.com hosting site. This portlet was exchanged in uPortal 2.6
for a version
I think the naming change to the subversion repository is both necessary
and required if we're really going to call the next release version 3.0.
So, +1 from me, despite any challenges it might bring.
Cris J H
Eric Dalquist wrote:
So way back when uPortal 2 and uPortal 3 were separate
There are few 'trends' that most in the community seem to agree on.
Eclipse was the first I noticed in this community.
Hibernate and Spring were the second and third (not sure the order). I
don't think you'll find much dissension on using Hibernate.
But If you really wanted to open the
I'd have stronger opinions if I was using an environment other then
Tomcat. However, in the Tomcat environment I don't see that it matters
much either way. In higher end app-server environments, it's probably
appropriate to let that server control the pools.
Even so, you can configure
, Cris J Holdorph wrote:
I'd have stronger opinions if I was using an environment other then
Tomcat. However, in the Tomcat environment I don't see that it
matters much either way. In higher end app-server environments, it's
probably appropriate to let that server control the pools.
Even so, you
Actually, there is a Portlet method on
javax.portlet.PortletRequest.getServerPort()
I'm not sure how much I would want to rely on it as a Portlet given the
general Portlet approach to URLs, but it's not something that you have
to unwrap the PortletRequest to get at.
Cris J H
Eric
I know there was discussion of up3 at the barcamp at the ja-sig
conference in June. Unfortunately, I had a 3.5 hour workshop to deliver
during that time so I was unable to participate.
What I don't understand is why the initial effort is being put towards
the activities you mention and
+1
Cris J H
Eric Dalquist wrote:
With no negative feedback on the RC I'd like to propose cutting the
2.6.1-GA release based on this code. Please respond with your vote on
releasing.
Thank you,
-Eric
Eric Dalquist wrote:
uPortal developers,
uPortal 2.6.1 release candidate one is now
Please let me know when a 2.6 patch is available, I have a training
class going right now, where multiple machines are experiencing this
problem with uPortal 2.6.0. If we see a patch we could test it on a
couple machines.
Cris J H
Eric Dalquist wrote:
There is a possible patch for this
I apologize if this is in the IRC log.
two questions.
1) why does the pluto 1.1 driver (test portal) not exhibit the same
problem? Do they do something similar to what your patch does for
uPortal? Specifically breaking part of the servlet spec (even though it
probably is ok to do so)?
2)
-1816
-Eric
Cris J Holdorph wrote:
I apologize if this is in the IRC log.
two questions.
1) why does the pluto 1.1 driver (test portal) not exhibit the same
problem? Do they do something similar to what your patch does for
uPortal? Specifically breaking part of the servlet spec (even though
The simplest way to do this is to set the EDIT mode on the portlet url
, that you use for the target of the form. So, if edit mode has a form
to fill in certain settings, you need a portlet action url to be the
target for the html form. on that portlet action url, simply have the
portlet
I'm in favor of it as well. I was just lamenting this morning, that
another project I am on, does not have it and I hope they introduce it soon.
Cris J H
Andrew Petro wrote:
Eric,
I favor adopting the script.
We use it internally at Unicon and headaches are minimal.
It's relatively
1 - 100 of 115 matches
Mail list logo
