[uportal-dev] DatabaseMetaDataImpl and JDBC drivers

[Brad Johnson]

Hello,

Would it be safe to say that all JDBC drivers that are going to be used
with uPortal support Prepared statements?

The test for the TimsStamp syntax seems to require prepared statements
anyway. Could we eliminate the member "supportsPreparedStatements" from
DatabaseMetaDataImpl along with the prepared statement test?

thanks,
Brad Johnson

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] JA-SIG Spring 2008 Conference - Call for Committee Volunteers

[Aaron Godert]

[Apologies for the cross postings]

Good Evening Everyone,

It's time to start planning for the upcoming "traditional" JA-SIG 
conference, not to be confused with the "Winter Unconference" that's 
being held next month.  Given the recent change in direction, moving 
from a twice-a-year traditional conference, to a once-a-year 
"Unconference" and a once-a-year "traditional" conference, the board 
looked to find a time when there would be few if any conflicts with 
other events in Higher-Ed.  After researching alternate times, we have 
identified Sunday to Wednesday, April 27th-30th as the best possible dates.


In the spirit of collaboration, the board is currently talking with 
other higher education community source foundations and projects about 
developing a joint program with them.  We are also interested in adding 
fresh new content, in addition to the already excellent topics around 
uPortal, CAS, and HyperContent - which attendees have come to enjoy and 
benefit from.


We are currently looking to assemble a committee for planning this 
conference.  If you are interested in being a member of this team, 
please contact me via email at [EMAIL PROTECTED]  This is a great 
opportunity to connect up with your JA-SIG colleagues and people from 
other community source efforts and to shape the next generation of 
traditional JA-SIG conferences.


Thanks,
Aaron Godert
JA-SIG 2008 Conference Committee, Board Liaison

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Fluid summit update

[Timothy Carroll]

1. we are developing dlm processors that facilitate in-line user 
customizations:

- moving channels and columns adjacently
- moving channels to new parents
- renaming tabs
- removing channels and columns

2. we are creating a user customizable theme that allows them to choose 
how they want to see tabs (vertical or horizontal), how they want to see 
channel and column options (menus or buttons), how they want to view 
channels (tile or icon).



Eric Dalquist wrote:

Tim,

Could we get a summary on the list or in the wiki of what work you are 
doing?


-Eric

Timothy Carroll wrote:
  
we should talk soon.  some of the dlm processor work we have done may 
help facilitate this.


Eric Dalquist wrote:

I attended the Fluid summit in Toronto last week which was a great 
success. While there was much talked about and decided upon I'll 
leave most of that to those interested in reading the Fluid wiki: 
http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki


The big uPortal related news item is that Jen Bourey and I are 
working with some of the Fluid developers (and eventually designers) 
to integrate the reorderer component into uPortal for the 3.0 release 
this winter. The reorderer is a drag and drop style component that 
also allows for keyboard accessibility, the Fluid dev page 
http://wiki.fluidproject.org/display/fluid/Development provides links 
to more technical information about the component. This will replace 
the client side JavaScript that is currently used for drag and drop 
in 2.6.


-Eric
  
  


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Wrong port number being returned?

[Anastasia Cheetham]

An update:

We're still not sure why the wrong port number is being used - the  
cause seems to be in whatever is implementating the javax.portlet  
package.


For now, we've fixed a bug in our apache configuration that was  
supposed to be eliminating the need for the port number at all. Now,  
no port number is necessary, so the fact that it would be wrong is  
not an issue.


This one is being filed on the back burner for now. Thanks to  
everyone for your input!


--
Anastasia Cheetham   [EMAIL PROTECTED]
Software Designer, Fluid Project
Adaptive Technology Resource Centre / University of Toronto

  "Even if you're on the right track,
   you'll get run over if you just sit there."
-- Will Rogers




--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] bit-sized uPortal 3 tasks

[Eric Dalquist]

There are a few bit-sized tasks that interested folks could take on for 
the uPortal 3 effort and a few not so bit-sized tasks that can be done 
in a fairly parallel manner.

In order from smallest to largest (in my quick review) here are some 
tasks that would be great to get some help with:

Switch to stand-alone PersonDirectory library: 
http://www.ja-sig.org/issues/browse/UP-1827
This is likely the easiest as it is a near drop-in replacement for the 
existing Spring configured person directory code and since the PersonDir 
static service will be removed little legacy support code will need to 
be written.

Switch to stand-along Groups and Permissions library: 
http://www.ja-sig.org/issues/browse/UP-1828
This should be a fairly straight forward replacement for the APIs but 
there will be some work involved in ensuring database configurations are 
correct and the GAP code has more contact points with the framework than 
person directory so it will likely take a bit longer.

Switch to Spring-LDAP in place of ldap.xml/ldap.properties: 
http://www.ja-sig.org/issues/browse/UP-1841
There will be some work here in determining the best way for uPortal to 
utilize the DataSource style objects Spring-LDAP provides. It shouldn't 
be difficult to figure out but there will be some code changes in places 
that use the existing LdapServices class.

Switch to Acegi for security: http://www.ja-sig.org/issues/browse/UP-1840
This is probably one of the largest changes that can be done in a fairly 
parallel effort. The goal would be to replace as much of the custom 
authentication/authorization code in uPortal with Acegi. This would 
completely replace security.properties and likely some of the uPortal 
ties to GAP.



I will be more than happy to provide as much support as needed to anyone 
who wants to take on any of this work. The PersonDirectory and GAP work 
is firmly planned for 3.0 but the Spring-LDAP and Acegi work is optional 
depending on available time so the more help we get with these the 
better chance of them all making it into 3.0

Thanks,
-Eric


smime.p7s
Description: S/MIME Cryptographic Signature

[uportal-dev] Subject: 2.6.1 RC2 now available

[Eric Dalquist]

uPortal 2.6.1 release candidate two is now available from the uPortal 
downloads page .

A release candidate signals "feature completeness", makes a binary 
available for easy downloading and testing, and provides a concrete 
artifact to talk about and open issues against. It also defines a 
serious candidate for release as uPortal 2.6.1 GA. Unless additional 
significant issues are raised, this will be uPortal 2.6.1.

Release notes are available in the wiki 
.

Since the RC1 release of uPortal 2.6.1, five issues have been addressed, 
including a patch for portlet session problems and portlet deployment on 
a OS X.

Many people contributed code, testing, feedback, and issues leading up 
to the uPortal 2.6.1 RC2 release, including Nick Bolton, Timothy 
Carroll, Eric Dalquist, Andy Gherna, Cris Holdorph, Elliot Metsger, Brad 
Johnson and Andrew Wills, to name a few. These people and others deserve 
credit for their parts in making uPortal possible.

Eric Dalquist
uPortal 2.6.1 release engineer



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Wrong port number being returned?

[Eric Dalquist]

Really, wow I should have checked my assertion before making it. 
Interesting that it is there though since, as you point out, there isn't 
much use for it in URL generation.

-Eric

Cris J Holdorph wrote:
> 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 Dalquist wrote:
>> For anything executing as a JSR-168 portlet there is no valid 
>> request.getServerPort() call. While technically you can access a 
>> HttpServletRequest object when rendering in a JSP that object should 
>> never be used, the portlet's request/response objects must be used 
>> instead. The main question is how are URLs generated, as Chris 
>> pointed out portlets must generate URLs through an API that takes 
>> care of the entire URL string. My guess is there is something else 
>> going on with URL generation for the portlet (string concatenation or 
>> some such) and the format just happens to be close enough to what 
>> uPortal expects to work.
>>
>> -Eric
>>
>> Jason Shao wrote:
>>> On Oct 2, 2007, at 5:54 PM, Anastasia Cheetham wrote:
>>>
 Hi, everyone,

 We're observing a strange bug in a tool that we're deploying as a 
 portlet in uPortal. I'm hoping that someone might be able to shed 
 some light on it.

 The tool converts relative URLs to absolute URLs, but it's 
 inserting a wrong port number. Our uPortal instance is running on 
 port 8090, but the port number that turns up is 80. When the URLs 
 are tested with the right port number substituted, they work.

 In case it matters: The tool is actually a Sakai tool that is 
 wrapped as a portlet. When it runs within Sakai (which is running 
 on port 8080) all is fine. No port number is included in the 
 absolute URL, and in the Sakai context, this works.
>>> 1. "wrapped as a portlet?" are you using some kind of bridge servlet 
>>> (like the Struts-Bridge?)
>>>
>>> 2. What do the connectors in your server.xml look like?
>>>
>>> 3. (probably only applies if you're using a bridge servlet) If you 
>>> call request.getServerPort() what do you get?
>>>
>>> Jason
>>>
>>> -- 
>>>
>>> Jason Shao
>>> Application Developer
>>> Rutgers University, Office of Instructional & Research Technology
>>> v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | 
>>> http://jay.shao.org
>>>
>>>
>>>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Wrong port number being returned?

[Cris J Holdorph]

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 Dalquist wrote:
For anything executing as a JSR-168 portlet there is no valid 
request.getServerPort() call. While technically you can access a 
HttpServletRequest object when rendering in a JSP that object should 
never be used, the portlet's request/response objects must be used 
instead. The main question is how are URLs generated, as Chris pointed 
out portlets must generate URLs through an API that takes care of the 
entire URL string. My guess is there is something else going on with URL 
generation for the portlet (string concatenation or some such) and the 
format just happens to be close enough to what uPortal expects to work.


-Eric

Jason Shao wrote:

On Oct 2, 2007, at 5:54 PM, Anastasia Cheetham wrote:


Hi, everyone,

We're observing a strange bug in a tool that we're deploying as a 
portlet in uPortal. I'm hoping that someone might be able to shed 
some light on it.


The tool converts relative URLs to absolute URLs, but it's inserting 
a wrong port number. Our uPortal instance is running on port 8090, 
but the port number that turns up is 80. When the URLs are tested 
with the right port number substituted, they work.


In case it matters: The tool is actually a Sakai tool that is wrapped 
as a portlet. When it runs within Sakai (which is running on port 
8080) all is fine. No port number is included in the absolute URL, 
and in the Sakai context, this works.
1. "wrapped as a portlet?" are you using some kind of bridge servlet 
(like the Struts-Bridge?)


2. What do the connectors in your server.xml look like?

3. (probably only applies if you're using a bridge servlet) If you 
call request.getServerPort() what do you get?


Jason

--

Jason Shao
Application Developer
Rutgers University, Office of Instructional & Research Technology
v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | 
http://jay.shao.org






--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Wrong port number being returned?

[Jason Shao]

On Oct 3, 2007, at 7:09 AM, Eric Dalquist wrote:


For anything executing as a JSR-168 portlet there is no valid
request.getServerPort() call. While technically you can access a
HttpServletRequest object when rendering in a JSP that object should
never be used, the portlet's request/response objects must be used
instead. The main question is how are URLs generated, as Chris pointed
out portlets must generate URLs through an API that takes care of the
entire URL string. My guess is there is something else going on  
with URL

generation for the portlet (string concatenation or some such) and the
format just happens to be close enough to what uPortal expects to  
work.


Right.

My curiosity (never having used a bridge library) was how the bridges  
that try to smoosh servlets into portlets have some kind of wrapping  
or translation they do at that level to fake portletURL generation  
through the HttpServletRequest methods. Not sure what approach RSF  
takes.


Jason

--

Jason Shao
Application Developer
Rutgers University, Office of Instructional & Research Technology
v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | http:// 
jay.shao.org




--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Wrong port number being returned?

[Eric Dalquist]

No problem, I'm sure we'd all love to hear what you figure out eventually.

-Eric

[EMAIL PROTECTED] wrote:
> Eric Dalquist <[EMAIL PROTECTED]> wrote:
>
>> For anything executing as a JSR-168 portlet there is no valid
>> request.getServerPort() call. While technically you can access a
>> HttpServletRequest object when rendering in a JSP that object should
>> never be used, the portlet's request/response objects must be used
>> instead. The main question is how are URLs generated, as Chris pointed
>> out portlets must generate URLs through an API that takes care of the
>> entire URL string. My guess is there is something else going on with URL
>> generation for the portlet (string concatenation or some such) and the
>> format just happens to be close enough to what uPortal expects to work.
>
> The tool *is* executing as a JSR-168 portlet. It doesn't use 
> HttpServletRequest directly, it uses RSF's portlet library. It's 
> looking like the problem is related to the RSF code, and is not 
> uPortal specific.
>
> Thanks to all for the questions and suggestions, it has helped point 
> me toward where to look for this.
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [uportal-dev] Wrong port number being returned?

[a . cheetham]

Eric Dalquist <[EMAIL PROTECTED]> wrote:


For anything executing as a JSR-168 portlet there is no valid
request.getServerPort() call. While technically you can access a
HttpServletRequest object when rendering in a JSP that object should
never be used, the portlet's request/response objects must be used
instead. The main question is how are URLs generated, as Chris pointed
out portlets must generate URLs through an API that takes care of the
entire URL string. My guess is there is something else going on with URL
generation for the portlet (string concatenation or some such) and the
format just happens to be close enough to what uPortal expects to work.


The tool *is* executing as a JSR-168 portlet. It doesn't use  
HttpServletRequest directly, it uses RSF's portlet library. It's  
looking like the problem is related to the RSF code, and is not  
uPortal specific.


Thanks to all for the questions and suggestions, it has helped point  
me toward where to look for this.


--
Anastasia Cheetham   [EMAIL PROTECTED]
Software Designer, Fluid Project
Adaptive Technology Resource Centre / University of Toronto



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Wrong port number being returned?

[Eric Dalquist]

For anything executing as a JSR-168 portlet there is no valid 
request.getServerPort() call. While technically you can access a 
HttpServletRequest object when rendering in a JSP that object should 
never be used, the portlet's request/response objects must be used 
instead. The main question is how are URLs generated, as Chris pointed 
out portlets must generate URLs through an API that takes care of the 
entire URL string. My guess is there is something else going on with URL 
generation for the portlet (string concatenation or some such) and the 
format just happens to be close enough to what uPortal expects to work.

-Eric

Jason Shao wrote:
> On Oct 2, 2007, at 5:54 PM, Anastasia Cheetham wrote:
>
>> Hi, everyone,
>>
>> We're observing a strange bug in a tool that we're deploying as a 
>> portlet in uPortal. I'm hoping that someone might be able to shed 
>> some light on it.
>>
>> The tool converts relative URLs to absolute URLs, but it's inserting 
>> a wrong port number. Our uPortal instance is running on port 8090, 
>> but the port number that turns up is 80. When the URLs are tested 
>> with the right port number substituted, they work.
>>
>> In case it matters: The tool is actually a Sakai tool that is wrapped 
>> as a portlet. When it runs within Sakai (which is running on port 
>> 8080) all is fine. No port number is included in the absolute URL, 
>> and in the Sakai context, this works.
>
> 1. "wrapped as a portlet?" are you using some kind of bridge servlet 
> (like the Struts-Bridge?)
>
> 2. What do the connectors in your server.xml look like?
>
> 3. (probably only applies if you're using a bridge servlet) If you 
> call request.getServerPort() what do you get?
>
> Jason
>
> -- 
>
> Jason Shao
> Application Developer
> Rutgers University, Office of Instructional & Research Technology
> v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | 
> http://jay.shao.org
>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature