tag:old.nabble.com,2006:forum-22546Nabble - uPortal2009-10-20T06:18:13Z<a href="http://www.uportal.org/" target="_top" rel="nofollow">uPortal</a> is a free, sharable portal under development by institutions of higher-education.
<br>This group sees an institutional portal as an abridged and customized version of the institutional Web presence... a "pocket-sized" version of the campus Web.
<br>Portal technology adds "customization" and "community" to the campus Web presence. Customization allows each user to define a unique and personal view of the campus Web. Community tools, such as chat, forums, survey, and so on, build relationships among campus constituencies.tag:old.nabble.com,2006:post-25974955Call for Proposals - Jasig 20102009-10-20T06:18:13Z2009-10-20T06:18:13ZJim Helwig-2<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<p>Hi all,<br>
I am forwarding this email from the conference committee stating the
that Call for Proposals is now open for the Spring conference but I
wanted to add a note encouraging you to consider doing a one hour
session. This is a great opportunity to talk about a portlet you have
developed, a portal implementation that went well, development
techniques or tools you find useful, understanding and managing user
expectations, or another topic your peers would find interesting. <br>
JimH<br>
</p>
<b><br>
</b>
<p><b>Ten Years of Open Source Innovation</b><br>
March 8 - 10, 2009</p>
<p>The Town and Country Resort, San Diego, California</p>
<p>Supplementary Seminars on March 7th and the afternoon of March 10th<br>
Developer Workshops, March 11 - 12</p>
<p><b>Call for Proposals now open</b><br>
Deadline for submission of proposals for half or full day seminars:
November 4, 2009<br>
Deadline for submission of proposals for all other sessions: November
18, 2009</p>
<p>Conference site: <a href="http://www.ja-sig.org/conferences/10spring/index.html" rel="nofollow" target="_top">http://www.ja-sig.org/conferences/10spring/index.html</a></p>
<p>Dear Colleague:</p>
<p>Help us celebrate Jasig's 10th anniversary in San Diego with
outstanding speakers and special events.</p>
<p>The focus is on innovation this year. We'll be highlighting new and
established work from higher education institutions: Projects you
should know about; local projects in search of community; creative work
by established communities of practice; projects that exist only as a
gleam in the eye of a creative developer.</p>
<p>Come and see presentations and seminars on new technologies soon to
impact higher education. We're seeking talks on topics such as Scala,
Spring 3, deployment to the Cloud, Groovy, Grails, REST, Jersey, mobile
applications, etc.</p>
<p>We invite you to propose talks, seminars, birds-of-a-feather
sessions, demos, and poster session displays on new and current campus
applications: Enterprise portlets, CAS, uPortal, Bedework Calendar,
Identity & Access Management, Fluid, ESUP Helpdesk, OpenRegistry,
Sakai, Kuali, Internet2 Middleware Solutions, Fedora and DSpace, and
others.</p>
<p>Talks will be presented in one of four tracks:</p>
<ul>
<li><b>Designing & Developing</b><br>
For developers, architects, UX designers, testers. Presentations for
people who build applications.</li>
<li><b>Deploying & Integrating</b><br>
For people who need to make applications work on campus: developers,
content providers, team leaders, evangelists. In particular, we would
like to highlight work that integrates open source projects within the
enterprise infrastructure and with each other.</li>
<li><b>Managing & Governing</b><br>
What are best practices for managing community source projects or their
deployments on campus? For encouraging adoption? For gaining acceptance
and campus buy-in? For engaging your community in the processes?
Presentations for managers, team leaders, executives, planners and
strategists.</li>
<li><b>Looking Ahead</b><br>
What are the technologies that will impact higher education in the
coming years? What project work, prototypes, plans, and local campus
applications would you like to share with a community of your peers?</li>
</ul>
<p>Half-day Supplementary Seminars will be held in the morning and
afternoon on Sunday, March 7th as well as on Wednesday (March 10th)
afternoon.</p>
<p>Proposals may be entered on the Jasig Conference Website. Proposals
require a Title, an Abstract (under 500 words), a Presenter Profile,
and some basic affiliation information. This year we are also asking
proposal submitters to select tags that best describe their proposals.</p>
<p>Submit your proposal directly at <a href="http://www.ja-sig.org/jasigconf/call-form.jsp?conf_id=jasig17" rel="nofollow" target="_top">http://www.ja-sig.org/jasigconf/call-form.jsp?conf_id=jasig17</a>
or from the conference home page, where you can find all the details: <a href="http://www.ja-sig.org/conferences/10spring/index.html" rel="nofollow" target="_top">http://www.ja-sig.org/conferences/10spring/index.html</a>
(Click the Call for Proposals link on the left).</p>
<p>We look forward to seeing you at <b>Ten Years of Open Source
Innovation</b>!</p>
<p>-The Jasig 2010 Spring Conference Planning Committee</p>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25974955&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25974955&i=1" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25974952Call for Proposals - Jasig 20102009-10-20T06:18:13Z2009-10-20T06:18:13ZJim Helwig-2<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<p>Hi all,<br>
I am forwarding this email from the conference committee stating the
that Call for Proposals is now open for the Spring conference but I
wanted to add a note encouraging you to consider doing a one hour
session. This is a great opportunity to talk about a portlet you have
developed, a portal implementation that went well, development
techniques or tools you find useful, understanding and managing user
expectations, or another topic your peers would find interesting. <br>
JimH<br>
</p>
<b><br>
</b>
<p><b>Ten Years of Open Source Innovation</b><br>
March 8 - 10, 2009</p>
<p>The Town and Country Resort, San Diego, California</p>
<p>Supplementary Seminars on March 7th and the afternoon of March 10th<br>
Developer Workshops, March 11 - 12</p>
<p><b>Call for Proposals now open</b><br>
Deadline for submission of proposals for half or full day seminars:
November 4, 2009<br>
Deadline for submission of proposals for all other sessions: November
18, 2009</p>
<p>Conference site: <a href="http://www.ja-sig.org/conferences/10spring/index.html" rel="nofollow" target="_top">http://www.ja-sig.org/conferences/10spring/index.html</a></p>
<p>Dear Colleague:</p>
<p>Help us celebrate Jasig's 10th anniversary in San Diego with
outstanding speakers and special events.</p>
<p>The focus is on innovation this year. We'll be highlighting new and
established work from higher education institutions: Projects you
should know about; local projects in search of community; creative work
by established communities of practice; projects that exist only as a
gleam in the eye of a creative developer.</p>
<p>Come and see presentations and seminars on new technologies soon to
impact higher education. We're seeking talks on topics such as Scala,
Spring 3, deployment to the Cloud, Groovy, Grails, REST, Jersey, mobile
applications, etc.</p>
<p>We invite you to propose talks, seminars, birds-of-a-feather
sessions, demos, and poster session displays on new and current campus
applications: Enterprise portlets, CAS, uPortal, Bedework Calendar,
Identity & Access Management, Fluid, ESUP Helpdesk, OpenRegistry,
Sakai, Kuali, Internet2 Middleware Solutions, Fedora and DSpace, and
others.</p>
<p>Talks will be presented in one of four tracks:</p>
<ul>
<li><b>Designing & Developing</b><br>
For developers, architects, UX designers, testers. Presentations for
people who build applications.</li>
<li><b>Deploying & Integrating</b><br>
For people who need to make applications work on campus: developers,
content providers, team leaders, evangelists. In particular, we would
like to highlight work that integrates open source projects within the
enterprise infrastructure and with each other.</li>
<li><b>Managing & Governing</b><br>
What are best practices for managing community source projects or their
deployments on campus? For encouraging adoption? For gaining acceptance
and campus buy-in? For engaging your community in the processes?
Presentations for managers, team leaders, executives, planners and
strategists.</li>
<li><b>Looking Ahead</b><br>
What are the technologies that will impact higher education in the
coming years? What project work, prototypes, plans, and local campus
applications would you like to share with a community of your peers?</li>
</ul>
<p>Half-day Supplementary Seminars will be held in the morning and
afternoon on Sunday, March 7th as well as on Wednesday (March 10th)
afternoon.</p>
<p>Proposals may be entered on the Jasig Conference Website. Proposals
require a Title, an Abstract (under 500 words), a Presenter Profile,
and some basic affiliation information. This year we are also asking
proposal submitters to select tags that best describe their proposals.</p>
<p>Submit your proposal directly at <a href="http://www.ja-sig.org/jasigconf/call-form.jsp?conf_id=jasig17" rel="nofollow" target="_top">http://www.ja-sig.org/jasigconf/call-form.jsp?conf_id=jasig17</a>
or from the conference home page, where you can find all the details: <a href="http://www.ja-sig.org/conferences/10spring/index.html" rel="nofollow" target="_top">http://www.ja-sig.org/conferences/10spring/index.html</a>
(Click the Call for Proposals link on the left).</p>
<p>We look forward to seeing you at <b>Ten Years of Open Source
Innovation</b>!</p>
<p>-The Jasig 2010 Spring Conference Planning Committee</p>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25974952&i=0" target="_top" rel="nofollow">uportal-dev@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25974952&i=1" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---Developer-f22545.html" embed="fixTarget[22545]" target="_top" >uPortal - Developer</a></p>tag:old.nabble.com,2006:post-25966981RE: Evaluating uPortal2009-10-19T15:45:43Z2009-10-19T15:45:43ZFang LinDwight,
<br><br>This is going to be very helpful to set the integration strategy at UW. Thank you so much for sharing your insights!
<br>I have learned that Johns Hopkins has developed a mobile version of the portal (<a href="http://www.jasig.org/johns-hopkins-university-selects-unicon-" target="_top" rel="nofollow">http://www.jasig.org/johns-hopkins-university-selects-unicon-</a>). Could you also share the status of that project?
<br><br>-Fang
<br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=0" target="_top" rel="nofollow">bounce-8030425-5729242@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=1" target="_top" rel="nofollow">bounce-8030425-5729242@...</a>] On Behalf Of Dwight Raum
<br>Sent: Friday, October 16, 2009 1:39 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=2" target="_top" rel="nofollow">uportal-user@...</a>
<br>Subject: RE: [uportal-user] Evaluating uPortal
<br><br>Fang,
<br><br>I have to agree with some of the sentiments you've expressed. We see the era of portals as a heavy application stack coming to an end too. As much as possible, we've modeled our implementation of uPortal (myJohnsHopkins) to minimize heavyweight dependencies, and to use uPortal as more of a lightweight container for personalization and aggregation. To that end, here are some key things we've done:
<br><br>* Integration: We rely heavily upon existing services within the enterprise -- this includes our enterprise directory, groups management (Active Directory), content management (SiteExecutive), institutional calendar (ActiveData Calendar), and SSO (CA SiteMinder). uPortal is pretty good at doing this, especially on the directory side of things. We have configured the SmartLdapGroupStore against our Active Directory, and we also use PAGS extensively for dynamic group mappings, and as a result have become largely independent of uPortal's local groups management structures altogether.
<br><br>Also, we pretty much avoid using proper JSR-168 portlets, particularly since they must live within the same JVM as uPortal. Early on we experienced stability problems with the uPortal environment due to independent issues within a specific homegrown portlet. This lack of compartmentalization between the portal and portlets is significant, and affects not only reliability but also scalability.
<br><br>Instead, we make extensive use of the WebProxy portlet -- this is absolutely key to our content and apps strategy. We've developed a custom pre-interceptor for WebProxyPortlet to pass along person-attributes through the proxied requests. The reliance on WebProxyPortlet also allows us to scale our apps and content their source. There is still burden on uPortal to personalize and aggregate, but a resource intensive application has little effect on the overall performance of uPortal. The tradeoffs are that apps are not intimately intertwined with the portal stack, and can be 'limited' in their UI. By devolving our content/apps to most basic forms, we've effectively diminished our dependencies so we're not 'locked' into a portal framework.
<br><br>* Delegated administration: Hopkins is a very decentralized place -- apps and content are administered all over the place. It would be impossible, organizationally, to centralize administration of content for our audiences. With the Portal, our ultimate end goal is to pass off the drudgeries of simple content and layout management to non-technical "content owners" of each sub-section within our portal. Because we're trying to leverage our existing services for directory, groupings, apps and content, it made little sense to pull their administration into uPortal. Our constituent services already have a reasonable set of tools for delegated administration, and by relying on them to provide their services to uPortal we've sidestepped some administration issues. One area where we couldn't sidestep uPortal is DLM Fragment Administration; however, working with Unicon we've implemented tools within uPortal that allow for better delegated management. These tools are used extensively by our communities to manage and maintain their respective areas of myJohnsHopkins.
<br><br>* URL based personalization: Since we're so decentralized, we've extended our single instance of uPortal to support multiple identities. So for example:
<br> <a href="http://my.jhmi.edu" target="_top" rel="nofollow">http://my.jhmi.edu</a><br> <a href="http://my.jhu.edu" target="_top" rel="nofollow">http://my.jhu.edu</a><br> <a href="http://insider.sais-jhu.edu" target="_top" rel="nofollow">http://insider.sais-jhu.edu</a><br> <a href="http://myep.jhu.edu" target="_top" rel="nofollow">http://myep.jhu.edu</a><br>These are all actually part of the same instance of uPortal, but the environment is flexible enough that we can deliver a unique experience based upon entry URL. We also employ uPortal template users to dynamically apply the initial user skin setting derived from enterprise directory data.
<br><br>So, like many technology answers "it depends". We've been very successful in using uPortal as a lightweight framework to personalize and aggregate content & applications. We also have a lot of the services necessary to implement a portal in our environment, and little desire to re-invent the wheel. The model for personalization and use of groups for uPortal is quite good, and when coupled with delegation is incredibly powerful.
<br><br>Thanks,
<br><br>Dwight Raum
<br>Director Enterprise Services, Johns Hopkins
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=3" target="_top" rel="nofollow">draum@...</a>
<br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=4" target="_top" rel="nofollow">bounce-8018404-5729417@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=5" target="_top" rel="nofollow">bounce-8018404-5729417@...</a>] On Behalf Of Fang Lin
<br>Sent: Wednesday, October 14, 2009 1:12 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=6" target="_top" rel="nofollow">uportal-user@...</a>
<br>Subject: RE: [uportal-user] Evaluating uPortal
<br><br>Gary,
<br><br>Personally I do have some concerns about how long the conventional enterprise web portal will last. UW just adopted Google Apps Education Edition (GAEE). We did a brief investigation to see if iGoogle can be used as the portal platform; it is summarized below:
<br><br>"GAEE has no conventional enterprise portal. Alternatively, Google Sites are where we present personalized contents to users and have total control of the user interface. The personal contents are delivered on Google Sites via Google Gadgets, which may be further configured by the users. The users may add the gadgets onto their iGoogle pages where they have the total control. But users can not change the layout of the Google Sites.
<br>Google Sites can be configured to allow only authorized users to access to the content and gadgets."
<br><br>When we finish our evaluation we will be happy to share our report here.
<br><br>Warm regards,
<br>-Fang
<br><br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=7" target="_top" rel="nofollow">bounce-8017258-5729242@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=8" target="_top" rel="nofollow">bounce-8017258-5729242@...</a>] On Behalf Of Gary Weaver
<br>Sent: Wednesday, October 14, 2009 7:42 AM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=9" target="_top" rel="nofollow">uportal-user@...</a>
<br>Subject: Re: [uportal-user] Evaluating uPortal
<br><br>Fang,
<br><br>Glad that helped. I definitely was not suggesting for UW to abandon the
<br>concept of a portal. I was just trying to present both sides. Thanks for
<br>passing on the great post by Oren!
<br><br>The less people that people talk about something, the more that people
<br>will think it is not worth talking about. It would be great to hear some
<br>feedback on what the rest of the Jasig community thinks about uPortal
<br>vs. Liferay vs. other portals. Perhaps this could help identify
<br>features/enhancements that might benefit from more focus of development
<br>over others. I could be wrong though.
<br><br>Take care,
<br><br>Gary
<br><br><br>Fang Lin wrote:
<div class='shrinkable-quote'><br>> Hi Gray,
<br>>
<br>> I will share your inputs with my team, thank you!!
<br>>
<br>> On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it.
<br>>
<br>> We also realize that the portal won't meet all the needs. See Oren Sreebny's blog:
<br>> <a href="http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/" target="_top" rel="nofollow">http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/</a> and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect.
<br>>
<br>> -Fang
<br>>
<br>>
<br>> -----Original Message-----
<br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=10" target="_top" rel="nofollow">bounce-8011050-5729242@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=11" target="_top" rel="nofollow">bounce-8011050-5729242@...</a>] On Behalf Of Gary Weaver
<br>> Sent: Tuesday, October 13, 2009 7:37 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=12" target="_top" rel="nofollow">uportal-user@...</a>
<br>> Cc: Janice C. Granberg; Leman Chung
<br>> Subject: Re: [uportal-user] Evaluating uPortal
<br>>
<br>> Fang,
<br>>
<br>> Here is a comparison (I'm not an expert on either, but this is what I've
<br>> noticed- others please jump in if I've left out anything or if what I'm
<br>> saying is incorrect):
<br>>
<br>> uPortal
<br>>
<br>> Miscellaneous:
<br>> * By default uPortal uses CAS for authN. Some info for how to get
<br>> Shibboleth setup is here:
<br>> <a href="http://www.ja-sig.org/wiki/display/UPM31/03+Shibboleth" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPM31/03+Shibboleth</a> and James Hong is
<br>> the last one to indicate that he Shibbolized a recent version. We plan
<br>> to eventually move to uP 3.1.1 (or later) and shibbolize it, but I just
<br>> did a quick spike (test) of shibbing it (I wasn't able to keep it from
<br>> hitting Login even on the guest view, but I'm guessing I was doing
<br>> something wrong). If you have any trouble Shibbolizing, let the list
<br>> know and maybe James can assist.
<br>> * uPortal has handful of portlets "under its wing" here:
<br>> <a href="https://www.ja-sig.org/svn/portlets/" target="_top" rel="nofollow">https://www.ja-sig.org/svn/portlets/</a><br>> (note that not all of the portlets in the list at
<br>> <a href="http://www.jasig.org/portlets" target="_top" rel="nofollow">http://www.jasig.org/portlets</a> are functional/have been tested in uPortal
<br>> 3.1.1, but I assume the ones in <a href="https://www.ja-sig.org/svn/portlets/" target="_top" rel="nofollow">https://www.ja-sig.org/svn/portlets/</a><br>> have although I'm not sure totally. There are also a few built-in to the
<br>> uPortal codebase itself (for administration, etc.).
<br>>
<br>> Pros:
<br>> * Community is more University/school focused: I think there are many
<br>> more universities/schools using uPortal vs. those using Liferay, but it
<br>> not strictly used by universities.
<br>> * Has a Jasig portlet adoption process so that if you do contribute
<br>> something that you can help get to the point where it meets standards
<br>> (including being Apache-licensed), you should have some help in
<br>> maintaining it.
<br>> * Works closely with Fluid group, so there is innovation in development
<br>> of UI that first was shown in uP 3.1.
<br>> * CAS is built-in. Since many use CAS, this is good for them!
<br>> * Webproxy portlet can be used to share existing/new web applications
<br>> and web content in the portal (but you'd need to use CSS classes
<br>> implemented in your uPortal skin(s)).
<br>> * They offer free use of their Jira, Confluence, and Subversion for
<br>> portlet and uPortal-related project development and community frequently
<br>> will work together on portlets.
<br>>
<br>> Cons:
<br>> * Not fully up-to-date on latest portlet standard: Although support was
<br>> added in preparation for JSR-286, the latest release version of uPortal
<br>> still uses JSR-168.
<br>> * Upgrades are non-trivial: Upgrades have been stated to be non-trivial
<br>> and probably will run into things that are not-documented, but recently
<br>> code was provided that should assist greatly in uP 2.5.3 and uP 2.6.1
<br>> upgrades to uPortal 3.x, and the community and developers are willing to
<br>> assist.
<br>> * Configuration/Usage/Development may be more difficult: From what I
<br>> read and hear from others, uPortal is just more difficult to use than
<br>> Liferay, however there is much greater support from the uPortal
<br>> community to help you through it.
<br>> * CAS is built-in. If you don't use CAS, it might not be as well-tested
<br>> with your type of authN.
<br>> * Wiki documentation is sometimes out-of-date and lacking. They welcome
<br>> anyone to assist with documentation that wants to help though.
<br>>
<br>> Liferay:
<br>>
<br>> Pros:
<br>> * Sun contributes to Liferay (Sun basically gave up with OpenPortal
<br>> project and took on Liferay).
<br>> * The latest release version of Liferay uses the latest portlet spec JSR286.
<br>> * Default portal is pretty slick/feels polished: while the UI of uPortal
<br>> quickstart has certainly greatly improved, Liferay's default
<br>> version/skin/UI of the portal feels more polished. However, this
<br>> probably doesn't mean much because you will end up needing to reskin it
<br>> for your implementation.
<br>> * There is a project for those interested in developing portlets using
<br>> JRuby on Rails (but it is Liferay and JSR-286 specific even though they
<br>> welcome development to make it work with other portals):
<br>> <a href="http://rails-portlet.rubyforge.org/" target="_top" rel="nofollow">http://rails-portlet.rubyforge.org/</a><br>> * There is a project for those interested in developing portlets using
<br>> Grails (may be is Liferay specific and I think still only supports
<br>> JSR-168): <a href="http://grails.org/plugin/portlets" target="_top" rel="nofollow">http://grails.org/plugin/portlets</a><br>> * There are probably more portlets available in Liferay and I think they
<br>> have more developers working on the project and more users, but am not sure.
<br>>
<br>> Cons:
<br>> * Community is less university/school focused
<br>> * CAS not built-in (if you are using CAS).
<br>> * Community/forums not nearly as helpful for universities or in-general
<br>> as responsive at getting people up-to-speed (at least that is from what
<br>> I hear. I can say for certain that the uPortal developers and community
<br>> are very helpful.
<br>>
<br>> Unsure:
<br>> * Don't know anything about ease of Liferay upgrades.
<br>>
<br>> Pros of both uPortal and Liferay:
<br>> * Both portals are Java-based: Integration with existing/new Java
<br>> libraries is easier. Since Java has a very large userbase and there is a
<br>> lot written in Java, you can develop portlets to do just about anything
<br>> you can think of and reuse existing libraries from Apache/Jakarta,
<br>> Sourceforge, Codehaus, Springsource, Hibernate, etc. along with plugins
<br>> for Maven 2, tasks for Ant, etc.
<br>> * Both are standards-based and have active development and user communities.
<br>>
<br>> Cons of both uPortal and Liferay:
<br>> * Portals in-general aren't as hot as they were years ago. There has
<br>> been a lot of movement towards applications that make it easier to
<br>> publish communication (Confluence/MediaWiki, Drupal/Joomla) or just in
<br>> web applications that are faster to develop ((J/C)Ruby on Rails, etc.).
<br>> However, there is still a place for them and the ability for users to
<br>> customize them and what content they see is a great asset, and as long
<br>> as you focus on continuing to provide things that the users actually
<br>> want and need (even things outside of the institution's normal realm),
<br>> the implementation will likely do well.
<br>>
<br>> Hope that helps,
<br>>
<br>> Gary
<br>>
<br>>
<br>> Fang Lin wrote:
<br>>
<br>>> Dear uPortal Community,
<br>>>
<br>>>
<br>>>
<br>>> At University of Washington we are about to start an evaluation
<br>>> project of portal frameworks as the replacement of our home-grown
<br>>> portal <a href="http://myuw.washington.edu/" target="_top" rel="nofollow">http://myuw.washington.edu/</a>). The two candidates that will be
<br>>> evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very
<br>>> grateful if folks have gone through the portal evaluation process can
<br>>> provide some advices.
<br>>>
<br>>>
<br>>>
<br>>> Our implementation platform will be Linux, Apache, Tomcat or Jetty,
<br>>> and the Shibboleth SP software for SSO support. Should we set up the
<br>>> evaluation portal using the portal only installation or the Quick
<br>>> Start version? What might be the limitations of using the Quick Start
<br>>> version for evaluation?
<br>>>
<br>>>
<br>>>
<br>>> Has there been any comparative analysis of uPortal 3.x with Liferay 5.x?
<br>>>
<br>>>
<br>>>
<br>>> Thanks!
<br>>>
<br>>> Fang Lin
<br>>>
<br>>> Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=13" target="_top" rel="nofollow">fanglin@...</a>
<br>>>
<br>>> UW Technology, University of Washington
<br>>>
<br>>>
<br>>>
<br>>> --
<br>>>
<br>>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=14" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=15" target="_top" rel="nofollow">gary.weaver@...</a>
<br>>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>>
<br>>
<br>>
<br>> ---
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=16" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=17" target="_top" rel="nofollow">fanglin@...</a>
<br>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>> ---
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=18" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=19" target="_top" rel="nofollow">gary.weaver@...</a>
<br>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>>
</div><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=20" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=21" target="_top" rel="nofollow">fanglin@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=22" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=23" target="_top" rel="nofollow">draum@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=24" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=25" target="_top" rel="nofollow">fanglin@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=26" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25966981&i=27" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25965109Re: [jasig-ue] portlet UI design guidelines?2009-10-19T13:27:43Z2009-10-19T13:27:43ZGary WeaverGary T.,
<br><br>Noticed that in the latest release of infusion, the class for an active
<br>tab appears to have changed a bit from the one used in uPortal 3.1.1.
<br><br>In
<br><a href="http://source.fluidproject.org/svn/fluid/infusion/tags/fluid-1.1.1/src/webapp/framework/fss/css/fss-layout.css" target="_top" rel="nofollow">http://source.fluidproject.org/svn/fluid/infusion/tags/fluid-1.1.1/src/webapp/framework/fss/css/fss-layout.css</a><br><br>there is:
<br>.fl-tabs .fl-tabs-active a {padding:0.25em 1.25em; border-bottom:none;
<br>color:#000;}
<br><br>and in uPortal 3.1.1 there is:
<br>apache-tomcat-6.0.18/webapps/uPortal/media/skins/universality/common/css/fluid/fluid.layout.css
<br><br>.fl-tabs .fl-activeTab {}
<br><br>and (among other minified versions, etc. and in the uportal3 theme)
<br>apache-tomcat-6.0.18/webapps/uPortal/media/skins/universality/uportal3/fluid.theme.uportal3.css
<br><br>.fl-theme-uportal3 .fl-tabs li.fl-activeTab,
<br>.fl-theme-uportal3 .fl-tabs li.fl-activeTab:hover,
<br>.fl-theme-uportal3 .fl-tabs li.fl-activeTab a,
<br>.fl-theme-uportal3 .fl-tabs li.fl-activeTab a:hover {background-color:
<br>#fff; border-bottom-color:#fff; color:#508cc9;}
<br><br>Some questions if you (or someone else) have time:
<br><br>* Which version of Infusion does uPortal 3.1.1 use? (doesn't look like
<br>it uses 1.1.1)
<br>* In the FSS, is there any deprecation of CSS classnames between
<br>versions? (I'm guessing in this case maybe this was a class that didn't
<br>meet the naming convention so it was just changed?)
<br>* Will uPortal deprecate the fluid CSS classnames or just go with the
<br>flow and change classnames when FSS/Infusion changes them and people
<br>will just need to change their skins, etc.?
<br><br>Thanks!
<br>Gary
<br><br><br>Gary Weaver wrote:
<div class='shrinkable-quote'><br>> Gary T.,
<br>>
<br>> Thanks so much! That will really help and I will look into using your
<br>> example and including part of the FSS styling in our uPortal if
<br>> possible so that the portlet (in theory) might be used in both uP
<br>> 3.1.1+ and uP 2.5.3.
<br>>
<br>> As a note on your example usage of portlet-menu, what is especially
<br>> confusing to me about the specs related to the menu is that in JSR-286
<br>> they provided a graphical example in PLT.C of how portlet-menu-*
<br>> classes should be used which is basically about styling popout menus.
<br>>
<br>> I really (!) like the portlet markup template that you wrote as well
<br>> as your example below:
<br>> <a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template</a><br>>
<br>> Thanks!
<br>> Gary
<br>>
<br>>
<br>> BTW- If it helps anyone at all, seeing some of the stuff that Gary T.
<br>> wrote triggered me to fix/update my JSR-168/JSR-286 portlet styling
<br>> quick reference to just include text directly from the JSR's because
<br>> otherwise the paraphrasing I did (as well as some mistakes in
<br>> accidentally referring to/basing it on older versions of the specs and
<br>> attributing the menu classes to JSR-286 rather than JSR-168 :( !!)
<br>> probably did more harm than good :( :
<br>> <a href="http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference" target="_top" rel="nofollow">http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference</a><br>>
<br>>
<br>> Gary Thompson wrote:
<br>>> Gary,
<br>>>
<br>>> (Great name, BTW.)
<br>>>
<br>>> I am glad you asked. Having standards for portlet markup and CSS is
<br>>> significant in developing portlets efficiently and that result in
<br>>> good user experiences.
<br>>> In developing the new Portlet Administration
<br>>> <<a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet</a>>
<br>>> (PA) portlet user experience for uPortal via Unicon's Cooperative
<br>>> Support program <<a href="http://www.unicon.net/support/cooperative" target="_top" rel="nofollow">http://www.unicon.net/support/cooperative</a>>, I had
<br>>> the opportunity to give some focused thought and attention to such
<br>>> standards. The results of that work are built into the PA portlet
<br>>> and documented (to some degree) here:
<br>>>
<br>>> * <a href="http://www.ja-sig.org/wiki/display/UPC/User+Interface" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/User+Interface</a><br>>> *
<br>>> <a href="http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions</a><br>>> * <a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template</a><br>>>
<br>>> It's not perfect, but it's a start. Please feel empowered and
<br>>> encouraged to contribute to refining it.
<br>>>
<br>>> Let me summarize a few high-level strategic thoughts and then try to
<br>>> answer a few of your more specific, tactical questions around the
<br>>> Mail portlet.
<br>>>
<br>>> S1. JSR-168 CSS specification
<br>>> Having many years of both broad and deep involvement in portal and
<br>>> portlet user interface design and development, my assessment is that
<br>>> the JSR-168 portlet CSS specification
<br>>> <<a href="http://www.ja-sig.org/wiki/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions</a>>
<br>>> is poorly designed, poorly defined, and woefully inadequate for
<br>>> modern portlet development. It also has not been updated in many
<br>>> years. This results in it being mostly useless as a standard, and
<br>>> therefore not worthy of significant effort to maintain as such in the
<br>>> Jasig community. For clarification, I am speaking of the CSS part of
<br>>> the JSR-168 specification, not the specification as a whole. Having
<br>>> concluded that it is a poor markup/CSS standard, that is not to say
<br>>> that it should be totally ignored or discarded - it is indeed still
<br>>> in use in uPortal and a few parts of it are usable. However, as a
<br>>> community we cannot base current and future efforts on it - it is not
<br>>> sufficient.
<br>>>
<br>>> S2. Portlet user interface spans major releases of uPortal
<br>>> I admire your efforts to achieve this, however I believe that you
<br>>> will find this effort not worthwhile when speaking of 2.5.x and
<br>>> 3.1.x. Especially in regards to the user interface layer, the
<br>>> differences between the two releases are rather un-spannable. Not
<br>>> impossible, but probably not worth the effort. I'll demonstrate this
<br>>> below in regards to your question about converting an unordered list
<br>>> into tabs. My recommendation is to press forward where possible - in
<br>>> most senses, uPortal and Jasig portlets are only now beginning to
<br>>> achieve the user experience standards that are prevalent conventions
<br>>> (and continuing to press forward) in the Web. We need not abandon
<br>>> the past, but we do need to press forward - that is where most of our
<br>>> energy and effort needs to be for our portal and portlets to remain
<br>>> viable.
<br>>>
<br>>> S3. As much as we are able, let's not create our own standard
<br>>> We can't sustain it, and if isolated to Jasig/uPortal, that doesn't
<br>>> make it much of a standard. However, I am of the opinion that Jasig
<br>>> should and must set some standards in this area where other standards
<br>>> are not sufficient. I am also of the opinion that where possible, we
<br>>> should push those needs into other open standards, like Fluid (see
<br>>> next).
<br>>>
<br>>> S4. Fluid Skinning System
<br>>> Incorporated into uPortal 3.1.x, the Fluid Skinning System
<br>>> <<a href="http://wiki.fluidproject.org/x/96M7" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/96M7</a>> is a CSS standard that uPortal
<br>>> (and Sakai, and several newer portlets) have adopted. Fluid also has
<br>>> a growing component library of many useful user interface "widgets"
<br>>> like Pagers, Reorderers, and Inline Editors
<br>>> <<a href="http://wiki.fluidproject.org/x/PAAF" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/PAAF</a>>. The Fluid Project community
<br>>> <<a href="http://fluidproject.org/" target="_top" rel="nofollow">http://fluidproject.org/</a>> is a well-balanced mix of both designers
<br>>> and developers, and their processes result in friendly frameworks
<br>>> that accomplish modern best practices in programming, usability, and
<br>>> accessibility. As a Fluid Project community participant and member,
<br>>> and hands-on user of the FSS, I can say that from personal
<br>>> experience. Since the community is active and growing, the Jasig
<br>>> community is welcome and encouraged to participate in the growth of
<br>>> the standard, yet does not have to solely bear the burden of
<br>>> maintaining the standard. My recommendation, therefore, is to
<br>>> continue to standardize on Fluid and related good frameworks like
<br>>> jQuery.
<br>>>
<br>>> S5. Portability
<br>>> The hallmark of the JSR-168 portlet spec is portability - the concept
<br>>> that a portlet can be taken from one portal context and dropped into
<br>>> wholly different portal context and operate the same. Theoretically,
<br>>> it's an interesting concept, but frankly, I have never seen this work
<br>>> practically. Maybe it is an easier achievement with the technology
<br>>> (though my experience is that doesn't work well either), but on the
<br>>> user experience front, it fails miserably. Because in user
<br>>> experience, CONTEXT is critical. Let me give an example of a
<br>>> singer. A singer being someone who can sing music. But a singer can
<br>>> be as different as Britney Spears is from Bob Dylan is from Bob
<br>>> Marley is from Mick Jagger is from Snoop Dogg is from Luciano
<br>>> Pavarotti is from Elvis Presley is from Willie Nelson. If the Opera
<br>>> needs a singer, you can't just unplug Snoop Dogg from rap and send
<br>>> him to the Opera. He doesn't FIT. Especially when they were
<br>>> expecting the Fat Lady for costuming. So like singers in different
<br>>> contexts, we are trying to pass around portlets to different portal
<br>>> contexts, with similar results. They don't naturally fit the new
<br>>> context without a lot of re-work and makeup applied - and even then
<br>>> they are easily identified as counterfeit. So far I have seen
<br>>> portlet portability fall into one of two strategies. In one, the
<br>>> portlet is packaged with its context (interactions, interfaces,
<br>>> styling, etc.), so that it ALWAYS is an Opera singer, for example.
<br>>> That works well in the Opera, but clearly fails at the rock concert.
<br>>> The other strategy is to make the portlet as generic as possible.
<br>>> This is the equivalent of sending a B-rate singer (has to be because
<br>>> he can't focus on any one context) in his underwear to whatever gig
<br>>> comes up, hoping that there will be the appropriate, fitting clothes
<br>>> waiting for him. This also fails (except for maybe the rock concert,
<br>>> where pretty much every singer is B-rate and in his underwear) for
<br>>> pretty obvious reasons. From the user interface/user experience
<br>>> perspective, portlets are particularly troubling that way. The Jasig
<br>>> community is great about being open when building portlets, but that
<br>>> often comes at a price of generic (B-rate, shows-up-in-his-underwear)
<br>>> quality, even when placed in its own uPortal. As far as I have
<br>>> experienced, this issue has yet to be solved. There isn't a good way
<br>>> to package and include all of the resources - markup, CSS, images,
<br>>> js, etc. - into every portlet so that it can be portable; that
<br>>> defeats many other best practices, standards, and maintainability.
<br>>> Howver, there is neither a good way to ensure that those resources
<br>>> are available from the portal context, and in a way that the portlet
<br>>> needs them to be functional and a good user experience. We have need
<br>>> of solving this issue.
<br>>>
<br>>> Now on to more tactical specifics.
<br>>>
<br>>> T1. Portlet Administraton
<br>>> The PA portlet in the 3.1 trunk is probably the best current, go
<br>>> forward example. It is not perfect, but shows how an older uPortal
<br>>> channel has been converted into a shiny, modern portlet. You should
<br>>> also refer to this CSS file in trunk for portlet development (which
<br>>> includes the JSR-168 spec and is amply commented):
<br>>>
<br>>> \uportal-war\src\main\webapp\media\skins\universality\uportal3\uportal3_portlet.css
<br>>>
<br>>>
<br>>> T2. FSS for grids and layout
<br>>> FSS (included in uPortal) comes with an excellent layout/grid
<br>>> framework. The FSS layout framework is being used to render the main
<br>>> uPortal UI layout (multi-column and sidebars - all without tables!).
<br>>> Refer to this FSS primer: <a href="http://wiki.fluidproject.org/x/-gBS" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/-gBS</a><br>>>
<br>>> T3. Making an unordered list into tabs
<br>>> On the 3.1.x release with FSS, this is simple and quick (rather
<br>>> beautiful overall). Simply take your semantic unordered list markup
<br>>> and sprinkle in a few FSS classes (I would also encourage some
<br>>> meaningful ARIA roles for accessibility):
<br>>> <div class="fl-container-flex">
<br>>> <ul role="tablist" class="fl-tabs fl-tabs-left">
<br>>> <li role="tab" class="fl-activeTab"><a href="#_bottom">Active
<br>>> Tab</a></li>
<br>>> <li role="tab"><a href="#_bottom">Tab #2</a></li>
<br>>> <li role="tab"><a href="#_bottom">Tab #3</a></li>
<br>>> </ul>
<br>>> <div role="tabpanel" class="fl-tab-content">
<br>>> Content
<br>>> </div>
<br>>> </div>
<br>>> Viola! And you don't have to edit CSS at all. FSS layout makes
<br>>> the unordered list into tabs, and FSS themes (uPortal skins) style
<br>>> the tabs to match the currently selected skin.
<br>>>
<br>>> Sadly, this will produce no tangible result in uPortal 2.5.3 - you'll
<br>>> still have a basic, unordered list in the user interface. What to
<br>>> do? Here's where we clearly demonstrate the shortcomings of the
<br>>> JSR-168 CSS specification (I'll try not to be overly sarcastic in my
<br>>> example).
<br>>>
<br>>> CSS classes are free (or at least cheap), so in most senses, there is
<br>>> no harm in layering on additional CSS classes into the markup. So
<br>>> let's think about layering in JSR-168 CSS classes to support non-FSS
<br>>> implementations. First, let's consult the JSR-168 spec to see what
<br>>> is available. After perusal, it looks like this section makes sense:
<br>>>
<br>>> PLT.C.6. Menus
<br>>> "Menu styles define the look-and-feel of the text and background of a
<br>>> menu structure. This structure may be embedded in the aggregated page
<br>>> or may appear as a context sensitive popup menu."
<br>>>
<br>>> Umm, okay, that definition makes it clear how I am supposed to use
<br>>> the spec... or not. Let's see if we can make sense of the classes
<br>>> they give us:
<br>>>
<br>>> portlet-menu General menu settings such as background color,
<br>>> margins, etc.
<br>>> portlet-menu-item Normal, unselected menu item.
<br>>> portlet-menu-item-selected Selected menu item.
<br>>> portlet-menu-item-hover Normal, unselected menu item when the
<br>>> mouse hovers over it.
<br>>> portlet-menu-item-hover-selected Selected menu item when the
<br>>> mouse hovers over it.
<br>>> portlet-menu-cascade-item Normal, unselected menu item that has
<br>>> submenus.
<br>>> portlet-menu-cascade-item-selected Selected sub-menu item that
<br>>> has sub-menus.
<br>>> portlet-menu-description Descriptive text for the menu (e.g. in a
<br>>> help context below the menu).
<br>>> portlet-menu-caption Menu caption.
<br>>>
<br>>>
<br>>> Why we need to specifically delineate "portlet-menu-item" on the <li>
<br>>> (when the <li> is contained in a <ul> already specified as a
<br>>> "portlet-menu") is lost on me, but okay. And we're supposed to put
<br>>> in a CSS class "portlet-menu-item-hover" for mouse-hover? Isn't
<br>>> there such a thing as :hover in the CSS spec itself? There's some
<br>>> stuff in there that could be used (though a Menu caption? Really?
<br>>> And the desciption is so helpful.), but the point is that even
<br>>> something as basic as a menu is not well designed or defined in the
<br>>> JSR-168 CSS spec. And note there is no JSR-168 class for the
<br>>> associated tabpanel.
<br>>> Taking these classes we could add in the following to our markup:
<br>>>
<br>>> <div class="fl-container-flex">
<br>>> <ul role="tablist" class="fl-tabs fl-tabs-left portlet-menu">
<br>>> <li role="tab" class="fl-activeTab
<br>>> portlet-menu-item-selected"><a href="#_bottom">Active Tab</a></li>
<br>>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
<br>>> #2</a></li>
<br>>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
<br>>> #3</a></li>
<br>>> </ul>
<br>>> <div role="tabpanel" class="fl-tab-content">
<br>>> Content
<br>>> </div>
<br>>> </div>
<br>>> And we would discover that this has done very little to our UI result
<br>>> in 2.5.3. Still no tabs, just an unordered list with maybe a bit of
<br>>> styling applied. Why? Because there is no context. What KIND of
<br>>> menu is this? Nothing in the JSR-168 spec specifies this as a TAB
<br>>> menu. Well, we could define that in the CSS by making all
<br>>> .portlet-menu .portlet-menu-item elements inline or floated and so
<br>>> forth. Super! (except that you had to figure out and test that
<br>>> across browsers on your own effort, which is painful, trust me). Now
<br>>> we have tabs from our unordered list. But wait - now EVERYWHERE that
<br>>> these classes are used will be converted to TABS, whether they are
<br>>> contextually tabs or not. The JSR-168 spec does not give us classes
<br>>> to define the context.
<br>>>
<br>>> So, okay, we could add the context to the container <div>, like so:
<br>>>
<br>>> <div class="fl-container-flex portlet-menu-tabs">
<br>>> <ul role="tablist" class="fl-tabs fl-tabs-left portlet-menu">
<br>>> <li role="tab" class="fl-activeTab
<br>>> portlet-menu-item-selected"><a href="#_bottom">Active Tab</a></li>
<br>>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
<br>>> #2</a></li>
<br>>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
<br>>> #3</a></li>
<br>>> </ul>
<br>>> <div role="tabpanel" class="fl-tab-content">
<br>>> Content
<br>>> </div>
<br>>> </div>
<br>>> And then solve the problem in the CSS with selectors like:
<br>>>
<br>>> .portlet-menu-tabs .portlet-menu .portlet-menu-item {}
<br>>>
<br>>> So that only those specifications are applied to make an unordered
<br>>> list into tabs when the parent .portlet-menu-tabs class is present.
<br>>> However, now we have broken the standard. No one will get the
<br>>> benefit of using these classes to achieve tabs from an unordered list
<br>>> without knowing to put the .portlet-menu-tabs class on the containing
<br>>> element. And even if that class is on the containing element, if you
<br>>> take the portlet out of uPortal and try to use it elsewhere, it will
<br>>> revert to an undesireable, plain unordered list. You could say the
<br>>> same about FSS (that it isn't portable), but it IS easily includable
<br>>> and relieves us from having to solve the problem, test the solution,
<br>>> and maintain the standard.
<br>>>
<br>>> My recommendation: include FSS into your CSS includes in your 2.5.3
<br>>> skin (minimally fss-layout.css), and you will at least get the basic
<br>>> structural benefits without doing any extra work and without
<br>>> complicating the markup with the JSR-168 classes. Besides, after
<br>>> including the JSR-168 classes, if you were to stumble on this markup,
<br>>> which classes do you use/modify? The FSS ones, or the JSR-168 ones?
<br>>> And if they are both (FSS and JSR-168) trying to make tabs out of an
<br>>> unordered list, you are going to get some ugly CSS conflicts. I like
<br>>> to Keep It Simple. The FSS markup is much cleaner, and does the job
<br>>> much better, with little effort required on your part as the
<br>>> implementor.
<br>>>
<br>>> Hope that helps. I welcome more discussion on these matters.
<br>>>
<br>>>
<br>>> Gary Thompson
<br>>> User Experience Leader
<br>>> Unicon | www.unicon.net
<br>>>
<br>>>
<br>>> ----- Original Message -----
<br>>> From: "Gary Weaver" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=0" target="_top" rel="nofollow">gary.weaver@...</a>>
<br>>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=1" target="_top" rel="nofollow">jasig-ue@...</a>
<br>>> Sent: Thursday, October 15, 2009 10:51:42 AM GMT -07:00 U.S. Mountain
<br>>> Time (Arizona)
<br>>> Subject: Re:[jasig-ue] portlet UI design guidelines?
<br>>>
<br>>> I should probably clarify that in the MailPortlet when you click on a
<br>>> tab, that it when it queries the pop3/imap server for mail, so I'm not
<br>>> looking for a show/hide div type of thing, but rather either the
<br>>> standard CSS classes that display line-items horizontally (in a way
<br>>> friendly to various existing skins in both uPortal 2.5.3 and uPortal
<br>>> 3.1.1) or something (that I'm not guessing would be a simple?) that not
<br>>> only display tabs but would use Ajax to load the chosen tab in the
<br>>> background and to do this in a skin-friendly way (specifically in the
<br>>> formatting of the tabs) that hopefully could work without much problem
<br>>> in both uPortal 2.5.3 and 3.1.1. The following is basically what I'm
<br>>> showing for tabs atop the mail message list table (I made up the class
<br>>> names to show what I'm looking for):
<br>>>
<br>>> <ul
<br>>> class="some-well-used-skin-class-to-indicate-these-are-tabs-and-therefore-this-unordered-list-should-be-composed-of-blocked-bordered-and-backgrounded-inline-line-items">
<br>>>
<br>>> <li>...</li>
<br>>> <li
<br>>> class="some-well-used-skin-class-to-indicate-this-inline-line-item-tab-is-selected">...</li>
<br>>>
<br>>> <li>...</li>
<br>>> </ul>
<br>>>
<br>>> It looks like maybe the thing to use in uPortal 3.1.1 is fl-tabs as the
<br>>> class name and fl-activeTab for the selected tab. But can I just define
<br>>> those in the portlet's CSS so that it works in older versions without it
<br>>> overriding the newer stuff in uPortal 3.1.1?
<br>>>
<br>>> And for table formatting, I was just checking to see what the best way
<br>>> to define the table and its classes are or what you would say is a
<br>>> uPortal 2.5.3 and 3.1.1 friendly way to define a table in a portlet. I
<br>>> currently have the following for the display of mail messages, but I'm
<br>>> guessing I could do better?:
<br>>>
<br>>> <%-- is there any nice column-resizing
<br>>> javascript deal available via uP 3.1 and if so could we include that in
<br>>> the portlet so that it could be used in both earlier and later versions
<br>>> of uPortal? %-->
<br>>> <table
<br>>> class="is-there-some-sort-of-standard-uportal-skin-class-that-should-be-used-here-that-might-add-a-border-or-similar">
<br>>>
<br>>> <tbody>
<br>>> <c:forEach
<br>>> items="${selectedMailAccountDetails.stubs}" var="stub"
<br>>> varStatus="counter">
<br>>> <c:set var="className">${ (counter.index
<br>>> % 2 == 0) ? 'portlet-section-body' : 'portlet-section-alternate'}
<br>>> ${stub.seen ? 'mailportlet-read-message' :
<br>>> 'mailportlet-unread-message'}</c:set>
<br>>> <tr class="${className}">
<br>>> <td>
<br>>> <c:if test="${stub.flagged}">
<br>>> <%-- am guessing maybe there
<br>>> are famfamfam icons for these, but then should resource-server be a
<br>>> requirement since it serves those in 3.1 or should they be included in
<br>>> the portlet to be compatible with older uPortal versions? --%>
<br>>> <img
<br>>> src="<%=request.getContextPath()%>/images/star.png"/>
<br>>> </c:if>
<br>>> <c:if test="${stub.answered}">
<br>>> <img
<br>>> src="<%=request.getContextPath()%>/images/answered.png"/>
<br>>> </c:if>
<br>>> <c:if test="${not stub.flagged
<br>>> && not stub.answered}">
<br>>> <%-- it just looks bad when
<br>>> there are no flags on any messages. assuming this column have some sort
<br>>> of minimum width. --%>
<br>>>
<br>>> </c:if>
<br>>> </td>
<br>>> <td><span class=${stub.deleted ?
<br>>> 'mailportlet-deleted-message' : ''}>
<br>>> <a
<br>>> href="${selectedMailAccountDetails.link}"><c:choose><c:when
<br>>> test="${empty stub.from}"><fmt:message
<br>>> key="noSender"/></c:when><c:otherwise><c:out
<br>>>
<br>>> value="${stub.from}"/></c:otherwise></c:choose></a></span></td>
<br>>> <td><span class=${stub.deleted ?
<br>>> 'mailportlet-deleted-message' : ''}><a
<br>>> href="${selectedMailAccountDetails.link}"><c:choose><c:when
<br>>> test="${empty stub.subject}"><fmt:message
<br>>> key="noSubject"/></c:when><c:otherwise><c:out
<br>>>
<br>>> value="${stub.subject}"/></c:otherwise></c:choose></a></span></td>
<br>>> <td><span class=${stub.deleted ?
<br>>> 'mailportlet-deleted-message' : ''}><a
<br>>> href="${selectedMailAccountDetails.link}"><c:choose><c:when
<br>>> test="${empty stub.received}"><fmt:message
<br>>> key="noDate"/></c:when><c:otherwise><c:out
<br>>>
<br>>> value="${stub.received}"/></c:otherwise></c:choose></a></span></td>
<br>>> </tr>
<br>>> </c:forEach>
<br>>> </tbody>
<br>>> </table>
<br>>>
<br>>> Thanks,
<br>>> Gary
<br>>>
<br>>>
<br>>> Gary Weaver wrote:
<br>>> > (sorry to cross-post, but I don't know where to send this)
<br>>> >
<br>>> > Am having a little bit of a dilemma working on the MailPortlet UI and
<br>>> > thought maybe someone could provide some guidance.
<br>>> >
<br>>> > * I want to use what I can of what standards I should from PLT.C CSS
<br>>> > classes of JSR-168, and am trying to make it utilize the classes as
<br>>> > defined in the default skin of uPortal 3.1.1 for reference
<br>>> > (skins/universality/uportal3/jsr168_portlet_spec.css) just to have a
<br>>> > better feel for what it would look like in the future if we were to
<br>>> > upgrade uPortal 3.1+. I know that these classes were also defined in
<br>>> > uPortal 2.5.3 skins, but I haven't looked at how those would look yet.
<br>>> >
<br>>> > * Those classes in the default skin of uP 3.1.1 at least seem to just
<br>>> > define background color, border color, change a few font sizes/bold a
<br>>> > few things, and do some light padding/margin changes.
<br>>> >
<br>>> > * Things like portlet-section-header, portlet-section-subheader, and
<br>>> > portlet-form-label aren't defining "display: block;" and therefore
<br>>> > also not defining margins/padding, so I'm unclear as to whether those
<br>>> > should be headers (h3, h4, ...) or label elements (all seem like they
<br>>> > should be headers I guess).
<br>>> >
<br>>> > * I need other CSS classes to make nice (list item) tabs across the
<br>>> > top of the main MailPortlet view
<br>>> >
<br>>> > * I need other CSS classes to do some better formatting of the table
<br>>> > containing the list of the most recent email messages for a specific
<br>>> > account (which has columns for flags, sender, subject, and date like
<br>>> > you'd expect in the main message list view a mail client)
<br>>> >
<br>>> > * It would be great (but not totally necessary) to have resizeable
<br>>> > columns in the table (so some standard javascript to assist with that
<br>>> > might be nice) or at the very least to have it defined the table
<br>>> >
<br>>> > My questions are:
<br>>> >
<br>>> > * Were there CSS classes that did that in the standard skins that came
<br>>> > with uPortal 2.5.3 (I'm looking through them now- not sure)? Do those
<br>>> > still apply for uP 3.1.1?
<br>>> >
<br>>> > * Could you point me at specific examples of portlets or other places
<br>>> > in uPortal 3.1.1 that do a good job (list item) tabs and grid/table
<br>>> > formatting like I'm talking about in a uPortal-skin friendly way?
<br>>> >
<br>>> > * What level of header should portlet-section-header,
<br>>> > portlet-section-subheader, and portlet-form-label be to have
<br>>> > consistency throughout portlets and if they should be labels, what
<br>>> > additional classes should be used if any to define that they should be
<br>>> > display:block and to define their margins/padding?
<br>>> >
<br>>> > * Do you think that ResourceServer should be a requirement for
<br>>> > portlets to display correctly from here on out, and if so, do you know
<br>>> > of anyone using it with older versions of uPortal?
<br>>> >
<br>>> > I completely understand that at some point the past has to be left
<br>>> > behind and newer portlets should only work with uPortal 3.1+, but for
<br>>> > those of us that want to contribute in such a way that portlets can be
<br>>> > used in both uPortal 3.1.1+ and uPortal 2.5.3, I want to make sure
<br>>> > that I'm defining things correctly and defining portlet-specific CSS
<br>>> > and/or reusing skin CSS in a way that is kosher for both environments
<br>>> > (at least for now, if it makes sense).
<br>>> >
<br>>> > Thanks!
<br>>> >
<br>>> > Gary
<br>>> >
<br>>>
<br>>>
<br>>> --
<br>>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=2" target="_top" rel="nofollow">jasig-ue@...</a> as:
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=3" target="_top" rel="nofollow">gary@...</a>
<br>>> To unsubscribe, change settings or access archives, see
<br>>> <a href="http://www.ja-sig.org/wiki/display/JSG/jasig-ue" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/jasig-ue</a><br>>> --
<br>>>
<br>>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=4" target="_top" rel="nofollow">uportal-dev@...</a> as:
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=5" target="_top" rel="nofollow">gary.weaver@...</a>
<br>>> To unsubscribe, change settings or access archives, see
<br>>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-dev" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-dev</a><br>>
<br>>
</div><br><br>--
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=6" target="_top" rel="nofollow">uportal-dev@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25965109&i=7" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-dev" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-dev</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---Developer-f22545.html" embed="fixTarget[22545]" target="_top" >uPortal - Developer</a></p>tag:old.nabble.com,2006:post-25962591Re: Mobility documentation?2009-10-19T10:46:16Z2009-10-19T10:46:16ZJen Bourey-2I've just committed a fix that restricts the new mobile theme to a set of specific mobile browsers, so desktop Safari should now receive the normal uPortal Universality theme. If you do an update and "ant deploy-war" your portal should pick up the new change.<br>
<br>If you'd still like to disable the new theme even for mobile devices, open up uportal-impl/src/main/resources/properties/browser.mappings and comment out all the lines directing browsers to the "mobileDefault" theme.<br>
<br>- Jen<br><br><br><div class="gmail_quote">On Mon, Oct 19, 2009 at 1:28 PM, Domazlicky, Eric <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962591&i=0" target="_top" rel="nofollow">edomazlicky@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal">Is there any info on the new uPortal Mobile support in
Trunk. I recently upgraded my trunk and now Safari is getting the Mobile
version. How can this be turned off?</p>
</div>
<pre>-- <font color="#888888"><br>
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962591&i=1" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962591&i=2" target="_top" rel="nofollow">jennifer.bourey@...</a><br>
To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_blank" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a></font></pre>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>Jen Bourey<br>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962591&i=3" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962591&i=4" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25962329Mobility documentation?2009-10-19T10:28:49Z2009-10-19T10:28:49ZDomazlicky, Eric<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:Z="urn:schemas-microsoft-com:" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>Is there any info on the new uPortal Mobile support in
Trunk. I recently upgraded my trunk and now Safari is getting the Mobile
version. How can this be turned off?<o:p></o:p></p>
</div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962329&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25962329&i=1" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25960660Re: [jasig-ue] portlet UI design guidelines?2009-10-19T08:45:15Z2009-10-19T08:45:15ZGary WeaverGary T.,
<br><br>Thanks so much! That will really help and I will look into using your
<br>example and including part of the FSS styling in our uPortal if possible
<br>so that the portlet (in theory) might be used in both uP 3.1.1+ and uP
<br>2.5.3.
<br><br>As a note on your example usage of portlet-menu, what is especially
<br>confusing to me about the specs related to the menu is that in JSR-286
<br>they provided a graphical example in PLT.C of how portlet-menu-* classes
<br>should be used which is basically about styling popout menus.
<br><br>I really (!) like the portlet markup template that you wrote as well as
<br>your example below:
<br><a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template</a><br><br>Thanks!
<br>Gary
<br><br><br>BTW- If it helps anyone at all, seeing some of the stuff that Gary T.
<br>wrote triggered me to fix/update my JSR-168/JSR-286 portlet styling
<br>quick reference to just include text directly from the JSR's because
<br>otherwise the paraphrasing I did (as well as some mistakes in
<br>accidentally referring to/basing it on older versions of the specs and
<br>attributing the menu classes to JSR-286 rather than JSR-168 :( !!)
<br>probably did more harm than good :( :
<br><a href="http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference" target="_top" rel="nofollow">http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference</a><br><br><br>Gary Thompson wrote:
<div class='shrinkable-quote'><br>> Gary,
<br>>
<br>> (Great name, BTW.)
<br>>
<br>> I am glad you asked. Having standards for portlet markup and CSS is
<br>> significant in developing portlets efficiently and that result in good
<br>> user experiences.
<br>>
<br>> In developing the new Portlet Administration
<br>> <<a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet</a>>
<br>> (PA) portlet user experience for uPortal via Unicon's Cooperative
<br>> Support program <<a href="http://www.unicon.net/support/cooperative" target="_top" rel="nofollow">http://www.unicon.net/support/cooperative</a>>, I had the
<br>> opportunity to give some focused thought and attention to such
<br>> standards. The results of that work are built into the PA portlet and
<br>> documented (to some degree) here:
<br>>
<br>> * <a href="http://www.ja-sig.org/wiki/display/UPC/User+Interface" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/User+Interface</a><br>> * <a href="http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions</a><br>> * <a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template</a><br>>
<br>> It's not perfect, but it's a start. Please feel empowered and
<br>> encouraged to contribute to refining it.
<br>>
<br>> Let me summarize a few high-level strategic thoughts and then try to
<br>> answer a few of your more specific, tactical questions around the Mail
<br>> portlet.
<br>>
<br>> S1. JSR-168 CSS specification
<br>> Having many years of both broad and deep involvement in portal and
<br>> portlet user interface design and development, my assessment is that
<br>> the JSR-168 portlet CSS specification
<br>> <<a href="http://www.ja-sig.org/wiki/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions</a>>
<br>> is poorly designed, poorly defined, and woefully inadequate for modern
<br>> portlet development. It also has not been updated in many years.
<br>> This results in it being mostly useless as a standard, and therefore
<br>> not worthy of significant effort to maintain as such in the Jasig
<br>> community. For clarification, I am speaking of the CSS part of the
<br>> JSR-168 specification, not the specification as a whole. Having
<br>> concluded that it is a poor markup/CSS standard, that is not to say
<br>> that it should be totally ignored or discarded - it is indeed still in
<br>> use in uPortal and a few parts of it are usable. However, as a
<br>> community we cannot base current and future efforts on it - it is not
<br>> sufficient.
<br>>
<br>> S2. Portlet user interface spans major releases of uPortal
<br>> I admire your efforts to achieve this, however I believe that you will
<br>> find this effort not worthwhile when speaking of 2.5.x and 3.1.x.
<br>> Especially in regards to the user interface layer, the differences
<br>> between the two releases are rather un-spannable. Not impossible, but
<br>> probably not worth the effort. I'll demonstrate this below in regards
<br>> to your question about converting an unordered list into tabs. My
<br>> recommendation is to press forward where possible - in most senses,
<br>> uPortal and Jasig portlets are only now beginning to achieve the user
<br>> experience standards that are prevalent conventions (and continuing to
<br>> press forward) in the Web. We need not abandon the past, but we do
<br>> need to press forward - that is where most of our energy and effort
<br>> needs to be for our portal and portlets to remain viable.
<br>>
<br>> S3. As much as we are able, let's not create our own standard
<br>> We can't sustain it, and if isolated to Jasig/uPortal, that doesn't
<br>> make it much of a standard. However, I am of the opinion that Jasig
<br>> should and must set some standards in this area where other standards
<br>> are not sufficient. I am also of the opinion that where possible, we
<br>> should push those needs into other open standards, like Fluid (see next).
<br>>
<br>> S4. Fluid Skinning System
<br>> Incorporated into uPortal 3.1.x, the Fluid Skinning System
<br>> <<a href="http://wiki.fluidproject.org/x/96M7" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/96M7</a>> is a CSS standard that uPortal
<br>> (and Sakai, and several newer portlets) have adopted. Fluid also has
<br>> a growing component library of many useful user interface "widgets"
<br>> like Pagers, Reorderers, and Inline Editors
<br>> <<a href="http://wiki.fluidproject.org/x/PAAF" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/PAAF</a>>. The Fluid Project community
<br>> <<a href="http://fluidproject.org/" target="_top" rel="nofollow">http://fluidproject.org/</a>> is a well-balanced mix of both designers
<br>> and developers, and their processes result in friendly frameworks that
<br>> accomplish modern best practices in programming, usability, and
<br>> accessibility. As a Fluid Project community participant and member,
<br>> and hands-on user of the FSS, I can say that from personal
<br>> experience. Since the community is active and growing, the Jasig
<br>> community is welcome and encouraged to participate in the growth of
<br>> the standard, yet does not have to solely bear the burden of
<br>> maintaining the standard. My recommendation, therefore, is to
<br>> continue to standardize on Fluid and related good frameworks like jQuery.
<br>>
<br>> S5. Portability
<br>> The hallmark of the JSR-168 portlet spec is portability - the concept
<br>> that a portlet can be taken from one portal context and dropped into
<br>> wholly different portal context and operate the same. Theoretically,
<br>> it's an interesting concept, but frankly, I have never seen this work
<br>> practically. Maybe it is an easier achievement with the technology
<br>> (though my experience is that doesn't work well either), but on the
<br>> user experience front, it fails miserably. Because in user
<br>> experience, CONTEXT is critical. Let me give an example of a singer.
<br>> A singer being someone who can sing music. But a singer can be as
<br>> different as Britney Spears is from Bob Dylan is from Bob Marley is
<br>> from Mick Jagger is from Snoop Dogg is from Luciano Pavarotti is from
<br>> Elvis Presley is from Willie Nelson. If the Opera needs a singer, you
<br>> can't just unplug Snoop Dogg from rap and send him to the Opera. He
<br>> doesn't FIT. Especially when they were expecting the Fat Lady for
<br>> costuming. So like singers in different contexts, we are trying to
<br>> pass around portlets to different portal contexts, with similar
<br>> results. They don't naturally fit the new context without a lot of
<br>> re-work and makeup applied - and even then they are easily identified
<br>> as counterfeit. So far I have seen portlet portability fall into one
<br>> of two strategies. In one, the portlet is packaged with its context
<br>> (interactions, interfaces, styling, etc.), so that it ALWAYS is an
<br>> Opera singer, for example. That works well in the Opera, but clearly
<br>> fails at the rock concert. The other strategy is to make the portlet
<br>> as generic as possible. This is the equivalent of sending a B-rate
<br>> singer (has to be because he can't focus on any one context) in his
<br>> underwear to whatever gig comes up, hoping that there will be the
<br>> appropriate, fitting clothes waiting for him. This also fails (except
<br>> for maybe the rock concert, where pretty much every singer is B-rate
<br>> and in his underwear) for pretty obvious reasons. From the user
<br>> interface/user experience perspective, portlets are particularly
<br>> troubling that way. The Jasig community is great about being open
<br>> when building portlets, but that often comes at a price of generic
<br>> (B-rate, shows-up-in-his-underwear) quality, even when placed in its
<br>> own uPortal. As far as I have experienced, this issue has yet to be
<br>> solved. There isn't a good way to package and include all of the
<br>> resources - markup, CSS, images, js, etc. - into every portlet so that
<br>> it can be portable; that defeats many other best practices, standards,
<br>> and maintainability. Howver, there is neither a good way to ensure
<br>> that those resources are available from the portal context, and in a
<br>> way that the portlet needs them to be functional and a good user
<br>> experience. We have need of solving this issue.
<br>>
<br>> Now on to more tactical specifics.
<br>>
<br>> T1. Portlet Administraton
<br>> The PA portlet in the 3.1 trunk is probably the best current, go
<br>> forward example. It is not perfect, but shows how an older uPortal
<br>> channel has been converted into a shiny, modern portlet. You should
<br>> also refer to this CSS file in trunk for portlet development (which
<br>> includes the JSR-168 spec and is amply commented):
<br>>
<br>> \uportal-war\src\main\webapp\media\skins\universality\uportal3\uportal3_portlet.css
<br>>
<br>> T2. FSS for grids and layout
<br>> FSS (included in uPortal) comes with an excellent layout/grid
<br>> framework. The FSS layout framework is being used to render the main
<br>> uPortal UI layout (multi-column and sidebars - all without tables!).
<br>> Refer to this FSS primer: <a href="http://wiki.fluidproject.org/x/-gBS" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/-gBS</a><br>>
<br>> T3. Making an unordered list into tabs
<br>> On the 3.1.x release with FSS, this is simple and quick (rather
<br>> beautiful overall). Simply take your semantic unordered list markup
<br>> and sprinkle in a few FSS classes (I would also encourage some
<br>> meaningful ARIA roles for accessibility):
<br>> <div class="fl-container-flex">
<br>> <ul role="tablist" class="fl-tabs fl-tabs-left">
<br>> <li role="tab" class="fl-activeTab"><a href="#_bottom">Active Tab</a></li>
<br>> <li role="tab"><a href="#_bottom">Tab #2</a></li>
<br>> <li role="tab"><a href="#_bottom">Tab #3</a></li>
<br>> </ul>
<br>> <div role="tabpanel" class="fl-tab-content">
<br>> Content
<br>> </div>
<br>> </div>
<br>>
<br>> Viola! And you don't have to edit CSS at all. FSS layout makes the
<br>> unordered list into tabs, and FSS themes (uPortal skins) style the
<br>> tabs to match the currently selected skin.
<br>>
<br>> Sadly, this will produce no tangible result in uPortal 2.5.3 - you'll
<br>> still have a basic, unordered list in the user interface. What to
<br>> do? Here's where we clearly demonstrate the shortcomings of the
<br>> JSR-168 CSS specification (I'll try not to be overly sarcastic in my
<br>> example).
<br>>
<br>> CSS classes are free (or at least cheap), so in most senses, there is
<br>> no harm in layering on additional CSS classes into the markup. So
<br>> let's think about layering in JSR-168 CSS classes to support non-FSS
<br>> implementations. First, let's consult the JSR-168 spec to see what is
<br>> available. After perusal, it looks like this section makes sense:
<br>>
<br>> PLT.C.6. Menus
<br>> "Menu styles define the look-and-feel of the text and background of a
<br>> menu structure. This structure may be embedded in the aggregated page
<br>> or may appear as a context sensitive popup menu."
<br>>
<br>> Umm, okay, that definition makes it clear how I am supposed to use the
<br>> spec... or not. Let's see if we can make sense of the classes they
<br>> give us:
<br>>
<br>> portlet-menu General menu settings such as background color, margins,
<br>> etc.
<br>> portlet-menu-item Normal, unselected menu item.
<br>> portlet-menu-item-selected Selected menu item.
<br>> portlet-menu-item-hover Normal, unselected menu item when the mouse
<br>> hovers over it.
<br>> portlet-menu-item-hover-selected Selected menu item when the mouse
<br>> hovers over it.
<br>> portlet-menu-cascade-item Normal, unselected menu item that has
<br>> submenus.
<br>> portlet-menu-cascade-item-selected Selected sub-menu item that has
<br>> sub-menus.
<br>> portlet-menu-description Descriptive text for the menu (e.g. in a
<br>> help context below the menu).
<br>> portlet-menu-caption Menu caption.
<br>>
<br>>
<br>> Why we need to specifically delineate "portlet-menu-item" on the <li>
<br>> (when the <li> is contained in a <ul> already specified as a
<br>> "portlet-menu") is lost on me, but okay. And we're supposed to put in
<br>> a CSS class "portlet-menu-item-hover" for mouse-hover? Isn't there
<br>> such a thing as :hover in the CSS spec itself? There's some stuff in
<br>> there that could be used (though a Menu caption? Really? And the
<br>> desciption is so helpful.), but the point is that even something as
<br>> basic as a menu is not well designed or defined in the JSR-168 CSS
<br>> spec. And note there is no JSR-168 class for the associated tabpanel.
<br>>
<br>> Taking these classes we could add in the following to our markup:
<br>>
<br>> <div class="fl-container-flex">
<br>> <ul role="tablist" class="fl-tabs fl-tabs-left portlet-menu">
<br>> <li role="tab" class="fl-activeTab portlet-menu-item-selected"><a href="#_bottom">Active Tab</a></li>
<br>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab #2</a></li>
<br>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab #3</a></li>
<br>> </ul>
<br>> <div role="tabpanel" class="fl-tab-content">
<br>> Content
<br>> </div>
<br>> </div>
<br>> And we would discover that this has done very little to our UI result
<br>> in 2.5.3. Still no tabs, just an unordered list with maybe a bit of
<br>> styling applied. Why? Because there is no context. What KIND of
<br>> menu is this? Nothing in the JSR-168 spec specifies this as a TAB
<br>> menu. Well, we could define that in the CSS by making all
<br>> .portlet-menu .portlet-menu-item elements inline or floated and so
<br>> forth. Super! (except that you had to figure out and test that across
<br>> browsers on your own effort, which is painful, trust me). Now we have
<br>> tabs from our unordered list. But wait - now EVERYWHERE that these
<br>> classes are used will be converted to TABS, whether they are
<br>> contextually tabs or not. The JSR-168 spec does not give us classes
<br>> to define the context.
<br>>
<br>> So, okay, we could add the context to the container <div>, like so:
<br>>
<br>> <div class="fl-container-flex portlet-menu-tabs">
<br>> <ul role="tablist" class="fl-tabs fl-tabs-left portlet-menu">
<br>> <li role="tab" class="fl-activeTab portlet-menu-item-selected"><a href="#_bottom">Active Tab</a></li>
<br>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab #2</a></li>
<br>> <li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab #3</a></li>
<br>> </ul>
<br>> <div role="tabpanel" class="fl-tab-content">
<br>> Content
<br>> </div>
<br>> </div>
<br>> And then solve the problem in the CSS with selectors like:
<br>>
<br>> .portlet-menu-tabs .portlet-menu .portlet-menu-item {}
<br>>
<br>> So that only those specifications are applied to make an unordered
<br>> list into tabs when the parent .portlet-menu-tabs class is present.
<br>> However, now we have broken the standard. No one will get the benefit
<br>> of using these classes to achieve tabs from an unordered list without
<br>> knowing to put the .portlet-menu-tabs class on the containing
<br>> element. And even if that class is on the containing element, if you
<br>> take the portlet out of uPortal and try to use it elsewhere, it will
<br>> revert to an undesireable, plain unordered list. You could say the
<br>> same about FSS (that it isn't portable), but it IS easily includable
<br>> and relieves us from having to solve the problem, test the solution,
<br>> and maintain the standard.
<br>>
<br>> My recommendation: include FSS into your CSS includes in your 2.5.3
<br>> skin (minimally fss-layout.css), and you will at least get the basic
<br>> structural benefits without doing any extra work and without
<br>> complicating the markup with the JSR-168 classes. Besides, after
<br>> including the JSR-168 classes, if you were to stumble on this markup,
<br>> which classes do you use/modify? The FSS ones, or the JSR-168 ones?
<br>> And if they are both (FSS and JSR-168) trying to make tabs out of an
<br>> unordered list, you are going to get some ugly CSS conflicts. I like
<br>> to Keep It Simple. The FSS markup is much cleaner, and does the job
<br>> much better, with little effort required on your part as the implementor.
<br>>
<br>> Hope that helps. I welcome more discussion on these matters.
<br>>
<br>>
<br>> Gary Thompson
<br>> User Experience Leader
<br>> Unicon | www.unicon.net
<br>>
<br>>
<br>> ----- Original Message -----
<br>> From: "Gary Weaver" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=0" target="_top" rel="nofollow">gary.weaver@...</a>>
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=1" target="_top" rel="nofollow">jasig-ue@...</a>
<br>> Sent: Thursday, October 15, 2009 10:51:42 AM GMT -07:00 U.S. Mountain
<br>> Time (Arizona)
<br>> Subject: Re:[jasig-ue] portlet UI design guidelines?
<br>>
<br>> I should probably clarify that in the MailPortlet when you click on a
<br>> tab, that it when it queries the pop3/imap server for mail, so I'm not
<br>> looking for a show/hide div type of thing, but rather either the
<br>> standard CSS classes that display line-items horizontally (in a way
<br>> friendly to various existing skins in both uPortal 2.5.3 and uPortal
<br>> 3.1.1) or something (that I'm not guessing would be a simple?) that not
<br>> only display tabs but would use Ajax to load the chosen tab in the
<br>> background and to do this in a skin-friendly way (specifically in the
<br>> formatting of the tabs) that hopefully could work without much problem
<br>> in both uPortal 2.5.3 and 3.1.1. The following is basically what I'm
<br>> showing for tabs atop the mail message list table (I made up the class
<br>> names to show what I'm looking for):
<br>>
<br>> <ul
<br>> class="some-well-used-skin-class-to-indicate-these-are-tabs-and-therefore-this-unordered-list-should-be-composed-of-blocked-bordered-and-backgrounded-inline-line-items">
<br>> <li>...</li>
<br>> <li
<br>> class="some-well-used-skin-class-to-indicate-this-inline-line-item-tab-is-selected">...</li>
<br>> <li>...</li>
<br>> </ul>
<br>>
<br>> It looks like maybe the thing to use in uPortal 3.1.1 is fl-tabs as the
<br>> class name and fl-activeTab for the selected tab. But can I just define
<br>> those in the portlet's CSS so that it works in older versions without it
<br>> overriding the newer stuff in uPortal 3.1.1?
<br>>
<br>> And for table formatting, I was just checking to see what the best way
<br>> to define the table and its classes are or what you would say is a
<br>> uPortal 2.5.3 and 3.1.1 friendly way to define a table in a portlet. I
<br>> currently have the following for the display of mail messages, but I'm
<br>> guessing I could do better?:
<br>>
<br>> <%-- is there any nice column-resizing
<br>> javascript deal available via uP 3.1 and if so could we include that in
<br>> the portlet so that it could be used in both earlier and later versions
<br>> of uPortal? %-->
<br>> <table
<br>> class="is-there-some-sort-of-standard-uportal-skin-class-that-should-be-used-here-that-might-add-a-border-or-similar">
<br>> <tbody>
<br>> <c:forEach
<br>> items="${selectedMailAccountDetails.stubs}" var="stub"
<br>> varStatus="counter">
<br>> <c:set var="className">${ (counter.index
<br>> % 2 == 0) ? 'portlet-section-body' : 'portlet-section-alternate'}
<br>> ${stub.seen ? 'mailportlet-read-message' :
<br>> 'mailportlet-unread-message'}</c:set>
<br>> <tr class="${className}">
<br>> <td>
<br>> <c:if test="${stub.flagged}">
<br>> <%-- am guessing maybe there
<br>> are famfamfam icons for these, but then should resource-server be a
<br>> requirement since it serves those in 3.1 or should they be included in
<br>> the portlet to be compatible with older uPortal versions? --%>
<br>> <img
<br>> src="<%=request.getContextPath()%>/images/star.png"/>
<br>> </c:if>
<br>> <c:if test="${stub.answered}">
<br>> <img
<br>> src="<%=request.getContextPath()%>/images/answered.png"/>
<br>> </c:if>
<br>> <c:if test="${not stub.flagged
<br>> && not stub.answered}">
<br>> <%-- it just looks bad when
<br>> there are no flags on any messages. assuming this column have some sort
<br>> of minimum width. --%>
<br>>
<br>> </c:if>
<br>> </td>
<br>> <td><span class=${stub.deleted ?
<br>> 'mailportlet-deleted-message' : ''}>
<br>> <a
<br>> href="${selectedMailAccountDetails.link}"><c:choose><c:when
<br>> test="${empty stub.from}"><fmt:message
<br>> key="noSender"/></c:when><c:otherwise><c:out
<br>>
<br>> value="${stub.from}"/></c:otherwise></c:choose></a></span></td>
<br>> <td><span class=${stub.deleted ?
<br>> 'mailportlet-deleted-message' : ''}><a
<br>> href="${selectedMailAccountDetails.link}"><c:choose><c:when
<br>> test="${empty stub.subject}"><fmt:message
<br>> key="noSubject"/></c:when><c:otherwise><c:out
<br>>
<br>> value="${stub.subject}"/></c:otherwise></c:choose></a></span></td>
<br>> <td><span class=${stub.deleted ?
<br>> 'mailportlet-deleted-message' : ''}><a
<br>> href="${selectedMailAccountDetails.link}"><c:choose><c:when
<br>> test="${empty stub.received}"><fmt:message
<br>> key="noDate"/></c:when><c:otherwise><c:out
<br>>
<br>> value="${stub.received}"/></c:otherwise></c:choose></a></span></td>
<br>> </tr>
<br>> </c:forEach>
<br>> </tbody>
<br>> </table>
<br>>
<br>> Thanks,
<br>> Gary
<br>>
<br>>
<br>> Gary Weaver wrote:
<br>> > (sorry to cross-post, but I don't know where to send this)
<br>> >
<br>> > Am having a little bit of a dilemma working on the MailPortlet UI and
<br>> > thought maybe someone could provide some guidance.
<br>> >
<br>> > * I want to use what I can of what standards I should from PLT.C CSS
<br>> > classes of JSR-168, and am trying to make it utilize the classes as
<br>> > defined in the default skin of uPortal 3.1.1 for reference
<br>> > (skins/universality/uportal3/jsr168_portlet_spec.css) just to have a
<br>> > better feel for what it would look like in the future if we were to
<br>> > upgrade uPortal 3.1+. I know that these classes were also defined in
<br>> > uPortal 2.5.3 skins, but I haven't looked at how those would look yet.
<br>> >
<br>> > * Those classes in the default skin of uP 3.1.1 at least seem to just
<br>> > define background color, border color, change a few font sizes/bold a
<br>> > few things, and do some light padding/margin changes.
<br>> >
<br>> > * Things like portlet-section-header, portlet-section-subheader, and
<br>> > portlet-form-label aren't defining "display: block;" and therefore
<br>> > also not defining margins/padding, so I'm unclear as to whether those
<br>> > should be headers (h3, h4, ...) or label elements (all seem like they
<br>> > should be headers I guess).
<br>> >
<br>> > * I need other CSS classes to make nice (list item) tabs across the
<br>> > top of the main MailPortlet view
<br>> >
<br>> > * I need other CSS classes to do some better formatting of the table
<br>> > containing the list of the most recent email messages for a specific
<br>> > account (which has columns for flags, sender, subject, and date like
<br>> > you'd expect in the main message list view a mail client)
<br>> >
<br>> > * It would be great (but not totally necessary) to have resizeable
<br>> > columns in the table (so some standard javascript to assist with that
<br>> > might be nice) or at the very least to have it defined the table
<br>> >
<br>> > My questions are:
<br>> >
<br>> > * Were there CSS classes that did that in the standard skins that came
<br>> > with uPortal 2.5.3 (I'm looking through them now- not sure)? Do those
<br>> > still apply for uP 3.1.1?
<br>> >
<br>> > * Could you point me at specific examples of portlets or other places
<br>> > in uPortal 3.1.1 that do a good job (list item) tabs and grid/table
<br>> > formatting like I'm talking about in a uPortal-skin friendly way?
<br>> >
<br>> > * What level of header should portlet-section-header,
<br>> > portlet-section-subheader, and portlet-form-label be to have
<br>> > consistency throughout portlets and if they should be labels, what
<br>> > additional classes should be used if any to define that they should be
<br>> > display:block and to define their margins/padding?
<br>> >
<br>> > * Do you think that ResourceServer should be a requirement for
<br>> > portlets to display correctly from here on out, and if so, do you know
<br>> > of anyone using it with older versions of uPortal?
<br>> >
<br>> > I completely understand that at some point the past has to be left
<br>> > behind and newer portlets should only work with uPortal 3.1+, but for
<br>> > those of us that want to contribute in such a way that portlets can be
<br>> > used in both uPortal 3.1.1+ and uPortal 2.5.3, I want to make sure
<br>> > that I'm defining things correctly and defining portlet-specific CSS
<br>> > and/or reusing skin CSS in a way that is kosher for both environments
<br>> > (at least for now, if it makes sense).
<br>> >
<br>> > Thanks!
<br>> >
<br>> > Gary
<br>> >
<br>>
<br>>
<br>> --
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=2" target="_top" rel="nofollow">jasig-ue@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=3" target="_top" rel="nofollow">gary@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/jasig-ue" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/jasig-ue</a><br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=4" target="_top" rel="nofollow">uportal-dev@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=5" target="_top" rel="nofollow">gary.weaver@...</a>
<br>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-dev" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-dev</a></div><br><br>--
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=6" target="_top" rel="nofollow">uportal-dev@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960660&i=7" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-dev" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-dev</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---Developer-f22545.html" embed="fixTarget[22545]" target="_top" >uPortal - Developer</a></p>tag:old.nabble.com,2006:post-25960137Re: access to a tab on startup (up3.1)2009-10-19T08:15:44Z2009-10-19T08:15:44ZLeblanc ChristopheThanks for your reply, it works fine and solve my problem.
<br><br>2009/10/13 Eric Dalquist <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960137&i=0" target="_top" rel="nofollow">eric.dalquist@...</a>>:
<div class='shrinkable-quote'><br>> This has been fixed for 3.2 by <a href="http://www.ja-sig.org/issues/browse/UP-2426" target="_top" rel="nofollow">http://www.ja-sig.org/issues/browse/UP-2426</a><br>>
<br>> The changes are very simple so if you want to try applying it to your 3.1
<br>> code you can see the patch here:
<br>> <a href="http://developer.jasig.org/source/rdiff/jasigsvn?csid=45860&u&N" target="_top" rel="nofollow">http://developer.jasig.org/source/rdiff/jasigsvn?csid=45860&u&N</a><br>>
<br>> -Eric
<br>>
<br>> Leblanc Christophe wrote:
<br>>>
<br>>> Hi,
<br>>>
<br>>> I wan't my guests users to access the tab they want via an url. I use
<br>>> externalid url looks like this :
<br>>>
<br>>> <a href="http://localhost:8080/uPortal/render.userLayoutRootNode.uP?uP_root=root&uP_sparam=activeTab&activeTab=welcome" target="_top" rel="nofollow">http://localhost:8080/uPortal/render.userLayoutRootNode.uP?uP_root=root&uP_sparam=activeTab&activeTab=welcome</a><br>>> or
<br>>>
<br>>> <a href="http://localhost:8080/uPortal/render.userLayoutRootNode.uP?uP_root=root&uP_sparam=activeTab&activeTab=news" target="_top" rel="nofollow">http://localhost:8080/uPortal/render.userLayoutRootNode.uP?uP_root=root&uP_sparam=activeTab&activeTab=news</a><br>>>
<br>>> But when the user first access the portal, he is redirected to the main
<br>>> page
<br>>> <a href="http://localhost:8080/uPortal/render.userLayoutRootNode.uP" target="_top" rel="nofollow">http://localhost:8080/uPortal/render.userLayoutRootNode.uP</a><br>>>
<br>>>
<br>>> Is it possible to stop this redirection and view the good tab ?
<br>>>
<br>>> Thanks
<br>>>
<br>>> Christophe Leblanc
<br>>>
<br>>> --- You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960137&i=1" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960137&i=2" target="_top" rel="nofollow">eric.dalquist@...</a>
<br>>> To unsubscribe, change settings or access archives, see
<br>>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>>
<br>>
</div><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960137&i=3" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25960137&i=4" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25958071uPortal2.6 - Bad Request 400 Error2009-10-19T06:05:36Z2009-10-19T06:05:36ZHakan TekinaslanHello,<div><br></div><div>Some of our uPortal users faced 400 - Bad Request error while tryin to view our uPortal installation. It happened on different browsers and problem was fixed by cleaning cookies and cache. Did anyone else face with this? Is there any way to prevent this?</div>
<div><br></div><div>Thanks a lot, have a nice day...</div><div>--- <br>Hakan Tekinaslan<br>SABANCI UNIVERSITY<br>Software Development Specialist<br>+90 (216) 483 9195<br>
</div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25958071&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25958071&i=1" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25952324Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-18T18:50:32Z2009-10-18T18:50:32ZSusan Bramhall<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
We're running Tomcat Version 6.0.18 and using Oracle drivers. Resource
defined in conf/contenxt.xml looks like this:<br>
<br>
<Resource name="jdbc/uPortalDB" auth="Container"
type="javax.sql.DataSource" <br>
factory='org.apache.commons.dbcp.BasicDataSourceFactory' <br>
username="user" password="pw"<br>
driverClassName="oracle.jdbc.OracleDriver" <br>
url="jdbc:oracle:thin:@server:1521:SID"<br>
maxActive='50' maxIdle='10' maxWait='5000'<br>
poolPreparedStatements='true'<br>
testOnBorrow='true'<br>
validationQuery='Select user from dual'<br>
removeAbandoned='true'<br>
logAbandoned='true' <br>
connectionProperties="oracle.jdbc.ReadTimeout=10000;oracle.net.CONNECT_TIMEOUT=2000"<br>
/><br>
<br>
As I said, the portal uses this connection for all database access as
do a few portlets. Hope this helps.<br>
Susan<br>
<br>
Curtis Garman wrote:
<blockquote cite="mid:70ca076d0910161300s7f4b32b3j8d1eb10b6d910c2@mail.gmail.com" type="cite">
<pre wrap="">Susan what version of tomcat are you guys running? I'm sure that it
has nothing to do with that at all...since the error that I am getting
is all over the internet...but I'm curious anyway. I'm playing with
6.0.20
The error I'm getting seems to indicate that I haven't clearly stated
where it should look for the connection information or that it is
ignoring the application context.xml...I'm not sure how else to
configure it...the maddening thing is that the same configuration
works on our current portal :)
On Fri, Oct 16, 2009 at 2:18 PM, Susan Bramhall <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=0" target="_top" rel="nofollow">susan.bramhall@...</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We've been using jndi datasources successfully ever since we went to 3.1
with no problems... We have a shared pool used by several portlets and the
portal itself. It would be hard for us to do it without jndi since
developers don't have access to those credentials. They are all using
Spring. Not sure what we are doing right that others have stumbled on.
Sample snippet from a portlet context:
<bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/jdbc/uPortalDB"/>
</bean>
I'd be curious to know what your problems have been.
Susan
Eric Dalquist wrote:
This isn't very helpful for your current problem but we haven't used JNDI
managed DataSources in uPortal or our portlets since upgrading to 3.0. They
always seem to have some sort of issue and a locally declared DBCP
DataSource in the Spring app context seems to work much better.
-Eric
Curtis Garman wrote:
Since the connection pool is only used by a single portlet and there
is no need for any other webapp to see it, I placed my Resource in the
the context.xml of my application (portlet)...I had tried placing my
driver in the shared/lib too but that didn't help.
On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>
wrote:
Are you putting the jndi information in the server context.xml or in the
applicationContext.xml? It has to be in the server context to allow all the
portlets to share the connections. And the jdbc library has to be shared as
well.
Susan
Curtis Garman wrote:
Does anyone have experience using jndi database resources for portlets
that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
are running via jndi connection pooling in our uportal 2.6.1
environment on tomcat 5.5.25 and while they work great for 2.6.1, I
can't get the portlets to run on 3.1.1 unless I hard-code the
connection information into the portlets. The portlets are not
spring-based at this point. I keep getting the following exception
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
My context.xml configuration is as follows
<Resource name="jdbc/cancellation" auth="Container"
type="javax.sql.DataSource"
username="user" password="password"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
maxActive="10" maxIdle="5" maxWait="1000"
poolPreparedStatements="true"
removeAbandoned="true"
removeAbandonedTimeout="300"
logAbandoned="true"
/>
I usually do not use the web.xml resource-ref...it seems to work without
it...
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/cancellation</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
...and it actually starts throwing a different error when I include it
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
driver of class '' for connect URL 'null'
I tried moving my context.xml to conf/Catalina/localhost and changing
the name of the file to appname.xml and this gave me yet another error
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
driver class 'net.sourceforge.jtds.jdbc.Driver'
Does anyone have any ideas?
--
Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=2" target="_top" rel="nofollow">susan.bramhall@...</a>)
Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=3" target="_top" rel="nofollow">uportal-user@...</a> as:
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=4" target="_top" rel="nofollow">curt.garman@...</a>
To unsubscribe, change settings or access archives, see
<a class="moz-txt-link-freetext" href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a>
--
Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=5" target="_top" rel="nofollow">susan.bramhall@...</a>)
Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=6" target="_top" rel="nofollow">uportal-user@...</a> as:
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=7" target="_top" rel="nofollow">curt.garman@...</a>
To unsubscribe, change settings or access archives, see
<a class="moz-txt-link-freetext" href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered)">
<div class="Section1">
<p class="MsoNormal"><span style="color: blue;">Susan Bramhall</span> (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=8" target="_top" rel="nofollow">susan.bramhall@...</a>)<br>
Senior Developer, Infrastructure Systems and Architecture (formerly
T&P)<br>
Yale University Information Technology Services (ITS)<br>
25 Science Park, 150 Munson St, New Haven, CT 06520<br>
Phone: 203 432 6697</p>
</div>
</div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=9" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25952324&i=10" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25940115some question about the "default"2009-10-17T10:06:53Z2009-10-17T10:06:53Zcet6<DIV>In up3.1 the new user would be added to the default group named "PAGS" and the new fragment owner defined in dlm.xml would be added to the default group named "Fragment Owners" .</DIV>
<DIV>1.What about the up2.5? And a new user must be at a group?</DIV>
<DIV>2.what will happen if the import done and the old data don't contain these group in up3.1? Is it defined in some properties to use the default group?</DIV>
<DIV>3.Does the group_key of up_group_fragment match with member_service and the member_key of up_group_membership? </DIV>
<DIV>Thanks, all. </DIV><br><br><span title="neteasefooter" /><hr />
<a href="http://allyes.nie.163.com/main/adfclick?db=afanie&bid=1254,611,23&cid=145,4,1&sid=1351&show=ignore&url=http://tx2.163.com/fab.html" target="_top" rel="nofollow">0�����晋3D������������������������������������</a>
</span>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25940115&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25940115&i=1" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25932793Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T14:41:11Z2009-10-16T14:41:11ZCurtis Garmanhmm...I know you have to enable jmxremote
<br>(-Dcom.sun.management.jmxremote) in tomcat to get the jdni resources
<br>to show up in probe but I'm assuming that is a specific part of
<br>jmx...I really don't know anything about it.
<br><br>Also while I was peeking at jmxContext, I noticed jndiContext...any
<br>idea what that does?
<br><br>On Fri, Oct 16, 2009 at 2:07 PM, Eric Dalquist
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=0" target="_top" rel="nofollow">eric.dalquist@...</a>> wrote:
<div class='shrinkable-quote'><br>> Curtis Garman wrote:
<br>>
<br>> Actually that is somewhat helpful because I've noticed others in the
<br>> community are doing the same thing...I could easily enough convert the
<br>> before mentioned portlets to spring...however spring development
<br>> hasn't quite been sanctioned here yet. What you just said will be
<br>> helpful in lobbying for it :)
<br>>
<br>>
<br>> Glad to help ;)
<br>>
<br>> One reason why I am interested in using jndi over an internal pool is
<br>> because we use lamba probe to help monitor things and it provides a
<br>> nice web interface to be able to view jndi connection pools and how
<br>> many open connections there are for each. I really don't want to lose
<br>> that if possible.
<br>>
<br>>
<br>> You can take a look at jmxContext.xml in uPortal to see an example of using
<br>> Spring to easily expose things such as local DataSource pools via JMX. Not
<br>> sure if lamba prob can talk JMX but uPortal exposes a whole bunch of data
<br>> that way.
<br>>
<br>> Another thing that makes the jndi thing problematic is that related to
<br>> another thread I started too...I set up a portlet overlay to apply all
<br>> customizations to our portlets...but it seemes to loose all
<br>> context.xml files from the META-INF directory...which obviously hurts
<br>> when using this file to link to or provide credentials to your
<br>> datasource.
<br>>
<br>>
<br>> Does the default overlay configuration include any <excluded> paths? That
<br>> would be my first guess in diagnosing that. Perhaps add an explicit include
<br>> in the overlay config?
<br>>
<br>> Curtis
<br>>
<br>>
<br>> On Fri, Oct 16, 2009 at 1:51 PM, Eric Dalquist
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=1" target="_top" rel="nofollow">eric.dalquist@...</a>> wrote:
<br>>
<br>>
<br>> This isn't very helpful for your current problem but we haven't used JNDI
<br>> managed DataSources in uPortal or our portlets since upgrading to 3.0. They
<br>> always seem to have some sort of issue and a locally declared DBCP
<br>> DataSource in the Spring app context seems to work much better.
<br>>
<br>> -Eric
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Since the connection pool is only used by a single portlet and there
<br>> is no need for any other webapp to see it, I placed my Resource in the
<br>> the context.xml of my application (portlet)...I had tried placing my
<br>> driver in the shared/lib too but that didn't help.
<br>>
<br>> On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=2" target="_top" rel="nofollow">susan.bramhall@...</a>>
<br>> wrote:
<br>>
<br>>
<br>> Are you putting the jndi information in the server context.xml or in the
<br>> applicationContext.xml? It has to be in the server context to allow all the
<br>> portlets to share the connections. And the jdbc library has to be shared as
<br>> well.
<br>> Susan
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Does anyone have experience using jndi database resources for portlets
<br>> that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
<br>> are running via jndi connection pooling in our uportal 2.6.1
<br>> environment on tomcat 5.5.25 and while they work great for 2.6.1, I
<br>> can't get the portlets to run on 3.1.1 unless I hard-code the
<br>> connection information into the portlets. The portlets are not
<br>> spring-based at this point. I keep getting the following exception
<br>>
<br>> javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
<br>>
<br>> My context.xml configuration is as follows
<br>>
<br>> <Resource name="jdbc/cancellation" auth="Container"
<br>> type="javax.sql.DataSource"
<br>> username="user" password="password"
<br>> driverClassName="net.sourceforge.jtds.jdbc.Driver"
<br>> url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
<br>> maxActive="10" maxIdle="5" maxWait="1000"
<br>> poolPreparedStatements="true"
<br>> removeAbandoned="true"
<br>> removeAbandonedTimeout="300"
<br>> logAbandoned="true"
<br>> />
<br>>
<br>> I usually do not use the web.xml resource-ref...it seems to work without
<br>> it...
<br>>
<br>> <resource-ref>
<br>> <description>DB Connection</description>
<br>> <res-ref-name>jdbc/cancellation</res-ref-name>
<br>> <res-type>javax.sql.DataSource</res-type>
<br>> <res-auth>Container</res-auth>
<br>> </resource-ref>
<br>>
<br>> ...and it actually starts throwing a different error when I include it
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
<br>> driver of class '' for connect URL 'null'
<br>>
<br>> I tried moving my context.xml to conf/Catalina/localhost and changing
<br>> the name of the file to appname.xml and this gave me yet another error
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
<br>> driver class 'net.sourceforge.jtds.jdbc.Driver'
<br>>
<br>> Does anyone have any ideas?
<br>>
<br>>
<br>>
<br>> --
<br>>
<br>> Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=3" target="_top" rel="nofollow">susan.bramhall@...</a>)
<br>> Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
<br>> Yale University Information Technology Services (ITS)
<br>> 25 Science Park, 150 Munson St, New Haven, CT 06520
<br>> Phone: 203 432 6697
<br>>
<br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=4" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=5" target="_top" rel="nofollow">curt.garman@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>>
<br>>
<br>>
<br>>
<br>>
</div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=6" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932793&i=7" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25932012RE: Evaluating uPortal2009-10-16T13:39:03Z2009-10-16T13:39:03ZDwight RaumFang,
<br><br>I have to agree with some of the sentiments you've expressed. We see the era of portals as a heavy application stack coming to an end too. As much as possible, we've modeled our implementation of uPortal (myJohnsHopkins) to minimize heavyweight dependencies, and to use uPortal as more of a lightweight container for personalization and aggregation. To that end, here are some key things we've done:
<br><br>* Integration: We rely heavily upon existing services within the enterprise -- this includes our enterprise directory, groups management (Active Directory), content management (SiteExecutive), institutional calendar (ActiveData Calendar), and SSO (CA SiteMinder). uPortal is pretty good at doing this, especially on the directory side of things. We have configured the SmartLdapGroupStore against our Active Directory, and we also use PAGS extensively for dynamic group mappings, and as a result have become largely independent of uPortal's local groups management structures altogether.
<br><br>Also, we pretty much avoid using proper JSR-168 portlets, particularly since they must live within the same JVM as uPortal. Early on we experienced stability problems with the uPortal environment due to independent issues within a specific homegrown portlet. This lack of compartmentalization between the portal and portlets is significant, and affects not only reliability but also scalability.
<br><br>Instead, we make extensive use of the WebProxy portlet -- this is absolutely key to our content and apps strategy. We've developed a custom pre-interceptor for WebProxyPortlet to pass along person-attributes through the proxied requests. The reliance on WebProxyPortlet also allows us to scale our apps and content their source. There is still burden on uPortal to personalize and aggregate, but a resource intensive application has little effect on the overall performance of uPortal. The tradeoffs are that apps are not intimately intertwined with the portal stack, and can be 'limited' in their UI. By devolving our content/apps to most basic forms, we've effectively diminished our dependencies so we're not 'locked' into a portal framework.
<br><br>* Delegated administration: Hopkins is a very decentralized place -- apps and content are administered all over the place. It would be impossible, organizationally, to centralize administration of content for our audiences. With the Portal, our ultimate end goal is to pass off the drudgeries of simple content and layout management to non-technical "content owners" of each sub-section within our portal. Because we're trying to leverage our existing services for directory, groupings, apps and content, it made little sense to pull their administration into uPortal. Our constituent services already have a reasonable set of tools for delegated administration, and by relying on them to provide their services to uPortal we've sidestepped some administration issues. One area where we couldn't sidestep uPortal is DLM Fragment Administration; however, working with Unicon we've implemented tools within uPortal that allow for better delegated management. These tools are used extensively by our communities to manage and maintain their respective areas of myJohnsHopkins.
<br><br>* URL based personalization: Since we're so decentralized, we've extended our single instance of uPortal to support multiple identities. So for example:
<br> <a href="http://my.jhmi.edu" target="_top" rel="nofollow">http://my.jhmi.edu</a><br> <a href="http://my.jhu.edu" target="_top" rel="nofollow">http://my.jhu.edu</a><br> <a href="http://insider.sais-jhu.edu" target="_top" rel="nofollow">http://insider.sais-jhu.edu</a><br> <a href="http://myep.jhu.edu" target="_top" rel="nofollow">http://myep.jhu.edu</a><br>These are all actually part of the same instance of uPortal, but the environment is flexible enough that we can deliver a unique experience based upon entry URL. We also employ uPortal template users to dynamically apply the initial user skin setting derived from enterprise directory data.
<br><br>So, like many technology answers "it depends". We've been very successful in using uPortal as a lightweight framework to personalize and aggregate content & applications. We also have a lot of the services necessary to implement a portal in our environment, and little desire to re-invent the wheel. The model for personalization and use of groups for uPortal is quite good, and when coupled with delegation is incredibly powerful.
<br><br>Thanks,
<br><br>Dwight Raum
<br>Director Enterprise Services, Johns Hopkins
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=0" target="_top" rel="nofollow">draum@...</a>
<br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=1" target="_top" rel="nofollow">bounce-8018404-5729417@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=2" target="_top" rel="nofollow">bounce-8018404-5729417@...</a>] On Behalf Of Fang Lin
<br>Sent: Wednesday, October 14, 2009 1:12 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=3" target="_top" rel="nofollow">uportal-user@...</a>
<br>Subject: RE: [uportal-user] Evaluating uPortal
<br><br>Gary,
<br><br>Personally I do have some concerns about how long the conventional enterprise web portal will last. UW just adopted Google Apps Education Edition (GAEE). We did a brief investigation to see if iGoogle can be used as the portal platform; it is summarized below:
<br><br>"GAEE has no conventional enterprise portal. Alternatively, Google Sites are where we present personalized contents to users and have total control of the user interface. The personal contents are delivered on Google Sites via Google Gadgets, which may be further configured by the users. The users may add the gadgets onto their iGoogle pages where they have the total control. But users can not change the layout of the Google Sites.
<br>Google Sites can be configured to allow only authorized users to access to the content and gadgets."
<br><br>When we finish our evaluation we will be happy to share our report here.
<br><br>Warm regards,
<br>-Fang
<br><br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=4" target="_top" rel="nofollow">bounce-8017258-5729242@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=5" target="_top" rel="nofollow">bounce-8017258-5729242@...</a>] On Behalf Of Gary Weaver
<br>Sent: Wednesday, October 14, 2009 7:42 AM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=6" target="_top" rel="nofollow">uportal-user@...</a>
<br>Subject: Re: [uportal-user] Evaluating uPortal
<br><br>Fang,
<br><br>Glad that helped. I definitely was not suggesting for UW to abandon the
<br>concept of a portal. I was just trying to present both sides. Thanks for
<br>passing on the great post by Oren!
<br><br>The less people that people talk about something, the more that people
<br>will think it is not worth talking about. It would be great to hear some
<br>feedback on what the rest of the Jasig community thinks about uPortal
<br>vs. Liferay vs. other portals. Perhaps this could help identify
<br>features/enhancements that might benefit from more focus of development
<br>over others. I could be wrong though.
<br><br>Take care,
<br><br>Gary
<br><br><br>Fang Lin wrote:
<div class='shrinkable-quote'><br>> Hi Gray,
<br>>
<br>> I will share your inputs with my team, thank you!!
<br>>
<br>> On UW campus there are still a lot of expectations on the conventional enterprise web portal. It seems too early to let go with it.
<br>>
<br>> We also realize that the portal won't meet all the needs. See Oren Sreebny's blog:
<br>> <a href="http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/" target="_top" rel="nofollow">http://blog.orenblog.org/2009/10/12/take-out-or-dine-in-considering-the-future-of-the-enterprise-portal/</a> and comments made by David Lassner, CIO of University of Hawaii, and Cliff Frost, their chief tech architect.
<br>>
<br>> -Fang
<br>>
<br>>
<br>> -----Original Message-----
<br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=7" target="_top" rel="nofollow">bounce-8011050-5729242@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=8" target="_top" rel="nofollow">bounce-8011050-5729242@...</a>] On Behalf Of Gary Weaver
<br>> Sent: Tuesday, October 13, 2009 7:37 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=9" target="_top" rel="nofollow">uportal-user@...</a>
<br>> Cc: Janice C. Granberg; Leman Chung
<br>> Subject: Re: [uportal-user] Evaluating uPortal
<br>>
<br>> Fang,
<br>>
<br>> Here is a comparison (I'm not an expert on either, but this is what I've
<br>> noticed- others please jump in if I've left out anything or if what I'm
<br>> saying is incorrect):
<br>>
<br>> uPortal
<br>>
<br>> Miscellaneous:
<br>> * By default uPortal uses CAS for authN. Some info for how to get
<br>> Shibboleth setup is here:
<br>> <a href="http://www.ja-sig.org/wiki/display/UPM31/03+Shibboleth" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/UPM31/03+Shibboleth</a> and James Hong is
<br>> the last one to indicate that he Shibbolized a recent version. We plan
<br>> to eventually move to uP 3.1.1 (or later) and shibbolize it, but I just
<br>> did a quick spike (test) of shibbing it (I wasn't able to keep it from
<br>> hitting Login even on the guest view, but I'm guessing I was doing
<br>> something wrong). If you have any trouble Shibbolizing, let the list
<br>> know and maybe James can assist.
<br>> * uPortal has handful of portlets "under its wing" here:
<br>> <a href="https://www.ja-sig.org/svn/portlets/" target="_top" rel="nofollow">https://www.ja-sig.org/svn/portlets/</a><br>> (note that not all of the portlets in the list at
<br>> <a href="http://www.jasig.org/portlets" target="_top" rel="nofollow">http://www.jasig.org/portlets</a> are functional/have been tested in uPortal
<br>> 3.1.1, but I assume the ones in <a href="https://www.ja-sig.org/svn/portlets/" target="_top" rel="nofollow">https://www.ja-sig.org/svn/portlets/</a><br>> have although I'm not sure totally. There are also a few built-in to the
<br>> uPortal codebase itself (for administration, etc.).
<br>>
<br>> Pros:
<br>> * Community is more University/school focused: I think there are many
<br>> more universities/schools using uPortal vs. those using Liferay, but it
<br>> not strictly used by universities.
<br>> * Has a Jasig portlet adoption process so that if you do contribute
<br>> something that you can help get to the point where it meets standards
<br>> (including being Apache-licensed), you should have some help in
<br>> maintaining it.
<br>> * Works closely with Fluid group, so there is innovation in development
<br>> of UI that first was shown in uP 3.1.
<br>> * CAS is built-in. Since many use CAS, this is good for them!
<br>> * Webproxy portlet can be used to share existing/new web applications
<br>> and web content in the portal (but you'd need to use CSS classes
<br>> implemented in your uPortal skin(s)).
<br>> * They offer free use of their Jira, Confluence, and Subversion for
<br>> portlet and uPortal-related project development and community frequently
<br>> will work together on portlets.
<br>>
<br>> Cons:
<br>> * Not fully up-to-date on latest portlet standard: Although support was
<br>> added in preparation for JSR-286, the latest release version of uPortal
<br>> still uses JSR-168.
<br>> * Upgrades are non-trivial: Upgrades have been stated to be non-trivial
<br>> and probably will run into things that are not-documented, but recently
<br>> code was provided that should assist greatly in uP 2.5.3 and uP 2.6.1
<br>> upgrades to uPortal 3.x, and the community and developers are willing to
<br>> assist.
<br>> * Configuration/Usage/Development may be more difficult: From what I
<br>> read and hear from others, uPortal is just more difficult to use than
<br>> Liferay, however there is much greater support from the uPortal
<br>> community to help you through it.
<br>> * CAS is built-in. If you don't use CAS, it might not be as well-tested
<br>> with your type of authN.
<br>> * Wiki documentation is sometimes out-of-date and lacking. They welcome
<br>> anyone to assist with documentation that wants to help though.
<br>>
<br>> Liferay:
<br>>
<br>> Pros:
<br>> * Sun contributes to Liferay (Sun basically gave up with OpenPortal
<br>> project and took on Liferay).
<br>> * The latest release version of Liferay uses the latest portlet spec JSR286.
<br>> * Default portal is pretty slick/feels polished: while the UI of uPortal
<br>> quickstart has certainly greatly improved, Liferay's default
<br>> version/skin/UI of the portal feels more polished. However, this
<br>> probably doesn't mean much because you will end up needing to reskin it
<br>> for your implementation.
<br>> * There is a project for those interested in developing portlets using
<br>> JRuby on Rails (but it is Liferay and JSR-286 specific even though they
<br>> welcome development to make it work with other portals):
<br>> <a href="http://rails-portlet.rubyforge.org/" target="_top" rel="nofollow">http://rails-portlet.rubyforge.org/</a><br>> * There is a project for those interested in developing portlets using
<br>> Grails (may be is Liferay specific and I think still only supports
<br>> JSR-168): <a href="http://grails.org/plugin/portlets" target="_top" rel="nofollow">http://grails.org/plugin/portlets</a><br>> * There are probably more portlets available in Liferay and I think they
<br>> have more developers working on the project and more users, but am not sure.
<br>>
<br>> Cons:
<br>> * Community is less university/school focused
<br>> * CAS not built-in (if you are using CAS).
<br>> * Community/forums not nearly as helpful for universities or in-general
<br>> as responsive at getting people up-to-speed (at least that is from what
<br>> I hear. I can say for certain that the uPortal developers and community
<br>> are very helpful.
<br>>
<br>> Unsure:
<br>> * Don't know anything about ease of Liferay upgrades.
<br>>
<br>> Pros of both uPortal and Liferay:
<br>> * Both portals are Java-based: Integration with existing/new Java
<br>> libraries is easier. Since Java has a very large userbase and there is a
<br>> lot written in Java, you can develop portlets to do just about anything
<br>> you can think of and reuse existing libraries from Apache/Jakarta,
<br>> Sourceforge, Codehaus, Springsource, Hibernate, etc. along with plugins
<br>> for Maven 2, tasks for Ant, etc.
<br>> * Both are standards-based and have active development and user communities.
<br>>
<br>> Cons of both uPortal and Liferay:
<br>> * Portals in-general aren't as hot as they were years ago. There has
<br>> been a lot of movement towards applications that make it easier to
<br>> publish communication (Confluence/MediaWiki, Drupal/Joomla) or just in
<br>> web applications that are faster to develop ((J/C)Ruby on Rails, etc.).
<br>> However, there is still a place for them and the ability for users to
<br>> customize them and what content they see is a great asset, and as long
<br>> as you focus on continuing to provide things that the users actually
<br>> want and need (even things outside of the institution's normal realm),
<br>> the implementation will likely do well.
<br>>
<br>> Hope that helps,
<br>>
<br>> Gary
<br>>
<br>>
<br>> Fang Lin wrote:
<br>>
<br>>> Dear uPortal Community,
<br>>>
<br>>>
<br>>>
<br>>> At University of Washington we are about to start an evaluation
<br>>> project of portal frameworks as the replacement of our home-grown
<br>>> portal <a href="http://myuw.washington.edu/" target="_top" rel="nofollow">http://myuw.washington.edu/</a>). The two candidates that will be
<br>>> evaluated are uPortal 3.1.1 and Liferay 5.2.5. We would be very
<br>>> grateful if folks have gone through the portal evaluation process can
<br>>> provide some advices.
<br>>>
<br>>>
<br>>>
<br>>> Our implementation platform will be Linux, Apache, Tomcat or Jetty,
<br>>> and the Shibboleth SP software for SSO support. Should we set up the
<br>>> evaluation portal using the portal only installation or the Quick
<br>>> Start version? What might be the limitations of using the Quick Start
<br>>> version for evaluation?
<br>>>
<br>>>
<br>>>
<br>>> Has there been any comparative analysis of uPortal 3.x with Liferay 5.x?
<br>>>
<br>>>
<br>>>
<br>>> Thanks!
<br>>>
<br>>> Fang Lin
<br>>>
<br>>> Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=10" target="_top" rel="nofollow">fanglin@...</a>
<br>>>
<br>>> UW Technology, University of Washington
<br>>>
<br>>>
<br>>>
<br>>> --
<br>>>
<br>>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=11" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=12" target="_top" rel="nofollow">gary.weaver@...</a>
<br>>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>>
<br>>
<br>>
<br>> ---
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=13" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=14" target="_top" rel="nofollow">fanglin@...</a>
<br>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>> ---
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=15" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=16" target="_top" rel="nofollow">gary.weaver@...</a>
<br>> To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>>
</div><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=17" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=18" target="_top" rel="nofollow">fanglin@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=19" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=20" target="_top" rel="nofollow">draum@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=21" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25932012&i=22" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25931444Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T13:00:01Z2009-10-16T13:00:01ZCurtis GarmanSusan what version of tomcat are you guys running? I'm sure that it
<br>has nothing to do with that at all...since the error that I am getting
<br>is all over the internet...but I'm curious anyway. I'm playing with
<br>6.0.20
<br><br>The error I'm getting seems to indicate that I haven't clearly stated
<br>where it should look for the connection information or that it is
<br>ignoring the application context.xml...I'm not sure how else to
<br>configure it...the maddening thing is that the same configuration
<br>works on our current portal :)
<br><br>On Fri, Oct 16, 2009 at 2:18 PM, Susan Bramhall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=0" target="_top" rel="nofollow">susan.bramhall@...</a>> wrote:
<div class='shrinkable-quote'><br>> We've been using jndi datasources successfully ever since we went to 3.1
<br>> with no problems... We have a shared pool used by several portlets and the
<br>> portal itself. It would be hard for us to do it without jndi since
<br>> developers don't have access to those credentials. They are all using
<br>> Spring. Not sure what we are doing right that others have stumbled on.
<br>> Sample snippet from a portlet context:
<br>>
<br>> <bean id="dataSource"
<br>> class="org.springframework.jndi.JndiObjectFactoryBean">
<br>> <property name="jndiName" value="java:comp/env/jdbc/uPortalDB"/>
<br>> </bean>
<br>>
<br>> I'd be curious to know what your problems have been.
<br>> Susan
<br>>
<br>> Eric Dalquist wrote:
<br>>
<br>> This isn't very helpful for your current problem but we haven't used JNDI
<br>> managed DataSources in uPortal or our portlets since upgrading to 3.0. They
<br>> always seem to have some sort of issue and a locally declared DBCP
<br>> DataSource in the Spring app context seems to work much better.
<br>>
<br>> -Eric
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Since the connection pool is only used by a single portlet and there
<br>> is no need for any other webapp to see it, I placed my Resource in the
<br>> the context.xml of my application (portlet)...I had tried placing my
<br>> driver in the shared/lib too but that didn't help.
<br>>
<br>> On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>>
<br>> wrote:
<br>>
<br>>
<br>> Are you putting the jndi information in the server context.xml or in the
<br>> applicationContext.xml? It has to be in the server context to allow all the
<br>> portlets to share the connections. And the jdbc library has to be shared as
<br>> well.
<br>> Susan
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Does anyone have experience using jndi database resources for portlets
<br>> that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
<br>> are running via jndi connection pooling in our uportal 2.6.1
<br>> environment on tomcat 5.5.25 and while they work great for 2.6.1, I
<br>> can't get the portlets to run on 3.1.1 unless I hard-code the
<br>> connection information into the portlets. The portlets are not
<br>> spring-based at this point. I keep getting the following exception
<br>>
<br>> javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
<br>>
<br>> My context.xml configuration is as follows
<br>>
<br>> <Resource name="jdbc/cancellation" auth="Container"
<br>> type="javax.sql.DataSource"
<br>> username="user" password="password"
<br>> driverClassName="net.sourceforge.jtds.jdbc.Driver"
<br>> url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
<br>> maxActive="10" maxIdle="5" maxWait="1000"
<br>> poolPreparedStatements="true"
<br>> removeAbandoned="true"
<br>> removeAbandonedTimeout="300"
<br>> logAbandoned="true"
<br>> />
<br>>
<br>> I usually do not use the web.xml resource-ref...it seems to work without
<br>> it...
<br>>
<br>> <resource-ref>
<br>> <description>DB Connection</description>
<br>> <res-ref-name>jdbc/cancellation</res-ref-name>
<br>> <res-type>javax.sql.DataSource</res-type>
<br>> <res-auth>Container</res-auth>
<br>> </resource-ref>
<br>>
<br>> ...and it actually starts throwing a different error when I include it
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
<br>> driver of class '' for connect URL 'null'
<br>>
<br>> I tried moving my context.xml to conf/Catalina/localhost and changing
<br>> the name of the file to appname.xml and this gave me yet another error
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
<br>> driver class 'net.sourceforge.jtds.jdbc.Driver'
<br>>
<br>> Does anyone have any ideas?
<br>>
<br>>
<br>>
<br>> --
<br>>
<br>> Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=2" target="_top" rel="nofollow">susan.bramhall@...</a>)
<br>> Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
<br>> Yale University Information Technology Services (ITS)
<br>> 25 Science Park, 150 Munson St, New Haven, CT 06520
<br>> Phone: 203 432 6697
<br>>
<br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=3" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=4" target="_top" rel="nofollow">curt.garman@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>>
<br>>
<br>>
<br>> --
<br>>
<br>> Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=5" target="_top" rel="nofollow">susan.bramhall@...</a>)
<br>> Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
<br>> Yale University Information Technology Services (ITS)
<br>> 25 Science Park, 150 Munson St, New Haven, CT 06520
<br>> Phone: 203 432 6697
<br>>
<br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=6" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=7" target="_top" rel="nofollow">curt.garman@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a></div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=8" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931444&i=9" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25931281Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T12:48:10Z2009-10-16T12:48:10ZCurtis GarmanIt's quite possible that I missed something. I attached one of my
<br>overlay pom.xml files...there is nothing to it. I found a page Jen
<br>Bourey and Susan created and looked at how the other overlay portlets
<br>were set up. I assumed that since the only thing I'm really
<br>overriding anything is my log4j.properties file that everything in
<br>META-INF should be copied from the war file dependency
<br><br>Curtis
<br><br>On Fri, Oct 16, 2009 at 2:07 PM, Eric Dalquist
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=0" target="_top" rel="nofollow">eric.dalquist@...</a>> wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> Curtis Garman wrote:
<br>>
<br>> Actually that is somewhat helpful because I've noticed others in the
<br>> community are doing the same thing...I could easily enough convert the
<br>> before mentioned portlets to spring...however spring development
<br>> hasn't quite been sanctioned here yet. What you just said will be
<br>> helpful in lobbying for it :)
<br>>
<br>>
<br>> Glad to help ;)
<br>>
<br>> One reason why I am interested in using jndi over an internal pool is
<br>> because we use lamba probe to help monitor things and it provides a
<br>> nice web interface to be able to view jndi connection pools and how
<br>> many open connections there are for each. I really don't want to lose
<br>> that if possible.
<br>>
<br>>
<br>> You can take a look at jmxContext.xml in uPortal to see an example of using
<br>> Spring to easily expose things such as local DataSource pools via JMX. Not
<br>> sure if lamba prob can talk JMX but uPortal exposes a whole bunch of data
<br>> that way.
<br>>
<br>> Another thing that makes the jndi thing problematic is that related to
<br>> another thread I started too...I set up a portlet overlay to apply all
<br>> customizations to our portlets...but it seemes to loose all
<br>> context.xml files from the META-INF directory...which obviously hurts
<br>> when using this file to link to or provide credentials to your
<br>> datasource.
<br>>
<br>>
<br>> Does the default overlay configuration include any <excluded> paths? That
<br>> would be my first guess in diagnosing that. Perhaps add an explicit include
<br>> in the overlay config?
<br>>
<br>> Curtis
<br>>
<br>>
<br>> On Fri, Oct 16, 2009 at 1:51 PM, Eric Dalquist
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=1" target="_top" rel="nofollow">eric.dalquist@...</a>> wrote:
<br>>
<br>>
<br>> This isn't very helpful for your current problem but we haven't used JNDI
<br>> managed DataSources in uPortal or our portlets since upgrading to 3.0. They
<br>> always seem to have some sort of issue and a locally declared DBCP
<br>> DataSource in the Spring app context seems to work much better.
<br>>
<br>> -Eric
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Since the connection pool is only used by a single portlet and there
<br>> is no need for any other webapp to see it, I placed my Resource in the
<br>> the context.xml of my application (portlet)...I had tried placing my
<br>> driver in the shared/lib too but that didn't help.
<br>>
<br>> On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=2" target="_top" rel="nofollow">susan.bramhall@...</a>>
<br>> wrote:
<br>>
<br>>
<br>> Are you putting the jndi information in the server context.xml or in the
<br>> applicationContext.xml? It has to be in the server context to allow all the
<br>> portlets to share the connections. And the jdbc library has to be shared as
<br>> well.
<br>> Susan
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Does anyone have experience using jndi database resources for portlets
<br>> that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
<br>> are running via jndi connection pooling in our uportal 2.6.1
<br>> environment on tomcat 5.5.25 and while they work great for 2.6.1, I
<br>> can't get the portlets to run on 3.1.1 unless I hard-code the
<br>> connection information into the portlets. The portlets are not
<br>> spring-based at this point. I keep getting the following exception
<br>>
<br>> javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
<br>>
<br>> My context.xml configuration is as follows
<br>>
<br>> <Resource name="jdbc/cancellation" auth="Container"
<br>> type="javax.sql.DataSource"
<br>> username="user" password="password"
<br>> driverClassName="net.sourceforge.jtds.jdbc.Driver"
<br>> url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
<br>> maxActive="10" maxIdle="5" maxWait="1000"
<br>> poolPreparedStatements="true"
<br>> removeAbandoned="true"
<br>> removeAbandonedTimeout="300"
<br>> logAbandoned="true"
<br>> />
<br>>
<br>> I usually do not use the web.xml resource-ref...it seems to work without
<br>> it...
<br>>
<br>> <resource-ref>
<br>> <description>DB Connection</description>
<br>> <res-ref-name>jdbc/cancellation</res-ref-name>
<br>> <res-type>javax.sql.DataSource</res-type>
<br>> <res-auth>Container</res-auth>
<br>> </resource-ref>
<br>>
<br>> ...and it actually starts throwing a different error when I include it
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
<br>> driver of class '' for connect URL 'null'
<br>>
<br>> I tried moving my context.xml to conf/Catalina/localhost and changing
<br>> the name of the file to appname.xml and this gave me yet another error
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
<br>> driver class 'net.sourceforge.jtds.jdbc.Driver'
<br>>
<br>> Does anyone have any ideas?
<br>>
<br>>
<br>>
<br>> --
<br>>
<br>> Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=3" target="_top" rel="nofollow">susan.bramhall@...</a>)
<br>> Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
<br>> Yale University Information Technology Services (ITS)
<br>> 25 Science Park, 150 Munson St, New Haven, CT 06520
<br>> Phone: 203 432 6697
<br>>
<br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=4" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=5" target="_top" rel="nofollow">curt.garman@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>>
<br>>
<br>>
<br>>
<br>>
</div></div><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=6" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931281&i=7" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br /><?xml version="1.0" encoding="UTF-8"?>
<br><project xmlns="<a href="http://maven.apache.org/POM/4.0.0" target="_top" rel="nofollow">http://maven.apache.org/POM/4.0.0</a>" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" target="_top" rel="nofollow">http://www.w3.org/2001/XMLSchema-instance</a>"
<br> xsi:schemaLocation="<a href="http://maven.apache.org/POM/4.0.0" target="_top" rel="nofollow">http://maven.apache.org/POM/4.0.0</a> <a href="http://maven.apache.org/maven-v4_0_0.xsd" target="_top" rel="nofollow">http://maven.apache.org/maven-v4_0_0.xsd</a>">
<br><br> <parent>
<br> <groupId>org.jasig.portal.portlets-overlay</groupId>
<br> <artifactId>uportal-portlets-overlay-parent</artifactId>
<br> <version>3.1.1</version>
<br> </parent>
<br><br> <modelVersion>4.0.0</modelVersion>
<br> <artifactId>heartland-text-portlet</artifactId>
<br> <packaging>war</packaging>
<br><br> <name>heartland-text-portlet</name>
<br> <description>Overlay on heartland-text-portlet.</description>
<br><br> <dependencies>
<br> <dependency>
<br> <groupId>edu.heartland.portlet</groupId>
<br> <artifactId>heartland-text-portlet</artifactId>
<br> <version>${heartland.text.portlet.version}</version>
<br> <type>war</type>
<br> </dependency>
<br> </dependencies>
<br><br> <build>
<br> <plugins>
<br> <plugin>
<br> <groupId>org.apache.pluto</groupId>
<br> <artifactId>maven-pluto-plugin</artifactId>
<br> </plugin>
<br> </plugins>
<br> </build>
<br>
<br></project><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25931057Re:[jasig-ue] portlet UI design guidelines?2009-10-16T12:31:47Z2009-10-16T12:31:47ZGary Thompson-4<html><head></head><body><div style='font-family: Verdana; font-size: 12pt; color: #000000'><div style="font-family: Verdana; font-size: 12pt; color: rgb(0, 0, 0);"><div style="font-family: Verdana; font-size: 12pt; color: rgb(0, 0, 0);"><div style="font-family: Verdana; font-size: 12pt; color: rgb(0, 0, 0);">Gary,<br><br>(Great name, BTW.)<br><br>I am glad you asked. Having standards for portlet markup and CSS is significant in developing portlets efficiently and that result in good user experiences. <br><br>In developing the new <a href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet" target="_blank" rel="nofollow">Portlet Administration</a> (PA) portlet user experience for uPortal via Unicon's <a href="http://www.unicon.net/support/cooperative" target="_blank" rel="nofollow">Cooperative Support program</a>, I had the opportunity to give some focused thought and attention to such standards. The results of that work are built into the PA portlet and documented (to some degree) here:<br><br>* <span class="Object" id="OBJ_PREFIX_DWT540"><span class="Object" id="OBJ_PREFIX_DWT541"><a target="_blank" href="http://www.ja-sig.org/wiki/display/UPC/User+Interface" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/User+Interface</a></span></span><br>* <span class="Object" id="OBJ_PREFIX_DWT542"><span class="Object" id="OBJ_PREFIX_DWT543"><a target="_blank" href="http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions</a></span></span><br>* <span class="Object" id="OBJ_PREFIX_DWT544"><span class="Object" id="OBJ_PREFIX_DWT545"><a target="_blank" href="http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template" rel="nofollow">http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template</a></span></span><br><br>It's not perfect, but it's a start. Please feel empowered and encouraged to contribute to refining it.<br><br>Let me summarize a few high-level strategic thoughts and then try to answer a few of your more specific, tactical questions around the Mail portlet.<br><br>S1. JSR-168 CSS specification<br>Having many years of both broad and deep involvement in portal and portlet user interface design and development, my assessment is that the <a href="http://www.ja-sig.org/wiki/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions" target="_top" rel="nofollow">JSR-168 portlet CSS specification</a> is poorly designed, poorly defined, and woefully inadequate for modern portlet development. It also has not been updated in many years. This results in it being mostly useless as a standard, and therefore not worthy of significant effort to maintain as such in the Jasig community. For clarification, I am speaking of the CSS part of the JSR-168 specification, not the specification as a whole. Having concluded that it is a poor markup/CSS standard, that is not to say that it should be totally ignored or discarded - it is indeed still in use in uPortal and a few parts of it are usable. However, as a community we cannot base current and future efforts on it - it is not sufficient.<br><br>S2. Portlet user interface spans major releases of uPortal<br>I admire your efforts to achieve this, however I believe that you will find this effort not worthwhile when speaking of 2.5.x and 3.1.x. Especially in regards to the user interface layer, the differences between the two releases are rather un-spannable. Not impossible, but probably not worth the effort. I'll demonstrate this below in regards to your question about converting an unordered list into tabs. My recommendation is to press forward where possible - in most senses, uPortal and Jasig portlets are only now beginning to achieve the user experience standards that are prevalent conventions (and continuing to press forward) in the Web. We need not abandon the past, but we do need to press forward - that is where most of our energy and effort needs to be for our portal and portlets to remain viable.<br><br>S3. As much as we are able, let's not create our own standard<br>We can't sustain it, and if isolated to Jasig/uPortal, that doesn't make it much of a standard. However, I am of the opinion that Jasig should and must set some standards in this area where other standards are not sufficient. I am also of the opinion that where possible, we should push those needs into other open standards, like Fluid (see next).<br><br>S4. Fluid Skinning System<br>Incorporated into uPortal 3.1.x, the <a href="http://wiki.fluidproject.org/x/96M7" target="_top" rel="nofollow">Fluid Skinning System</a> is a CSS standard that uPortal (and Sakai, and several newer portlets) have adopted. Fluid also has a growing component library of many useful user interface "widgets" like <a href="http://wiki.fluidproject.org/x/PAAF" target="_top" rel="nofollow">Pagers, Reorderers, and Inline Editors</a>. The <a href="http://fluidproject.org/" target="_top" rel="nofollow">Fluid Project community</a> is a well-balanced mix of both designers and developers, and their processes result in friendly frameworks that accomplish modern best practices in programming, usability, and accessibility. As a Fluid Project community participant and member, and hands-on user of the FSS, I can say that from personal experience. Since the community is active and growing, the Jasig community is welcome and encouraged to participate in the growth of the standard, yet does not have to solely bear the burden of maintaining the standard. My recommendation, therefore, is to continue to standardize on Fluid and related good frameworks like jQuery.<br><br>S5. Portability<br>The hallmark of the JSR-168 portlet spec is portability - the concept that a portlet can be taken from one portal context and dropped into wholly different portal context and operate the same. Theoretically, it's an interesting concept, but frankly, I have never seen this work practically. Maybe it is an easier achievement with the technology (though my experience is that doesn't work well either), but on the user experience front, it fails miserably. Because in user experience, CONTEXT is critical. Let me give an example of a singer. A singer being someone who can sing music. But a singer can be as different as Britney Spears is from Bob Dylan is from Bob Marley is from Mick Jagger is from Snoop Dogg is from Luciano Pavarotti is from Elvis Presley is from Willie Nelson. If the Opera needs a singer, you can't just unplug Snoop Dogg from rap and send him to the Opera. He doesn't FIT. Especially when they were expecting the Fat Lady for costuming. So like singers in different contexts, we are trying to pass around portlets to different portal contexts, with similar results. They don't naturally fit the new context without a lot of re-work and makeup applied - and even then they are easily identified as counterfeit. So far I have seen portlet portability fall into one of two strategies. In one, the portlet is packaged with its context (interactions, interfaces, styling, etc.), so that it ALWAYS is an Opera singer, for example. That works well in the Opera, but clearly fails at the rock concert. The other strategy is to make the portlet as generic as possible. This is the equivalent of sending a B-rate singer (has to be because he can't focus on any one context) in his underwear to whatever gig comes up, hoping that there will be the appropriate, fitting clothes waiting for him. This also fails (except for maybe the rock concert, where pretty much every singer is B-rate and in his underwear) for pretty obvious reasons. From the user interface/user experience perspective, portlets are particularly troubling that way. The Jasig community is great about being open when building portlets, but that often comes at a price of generic (B-rate, shows-up-in-his-underwear) quality, even when placed in its own uPortal. As far as I have experienced, this issue has yet to be solved. There isn't a good way to package and include all of the resources - markup, CSS, images, js, etc. - into every portlet so that it can be portable; that defeats many other best practices, standards, and maintainability. Howver, there is neither a good way to ensure that those resources are available from the portal context, and in a way that the portlet needs them to be functional and a good user experience. We have need of solving this issue.<br><br>Now on to more tactical specifics.<br><br>T1. Portlet Administraton<br>The PA portlet in the 3.1 trunk is probably the best current, go forward example. It is not perfect, but shows how an older uPortal channel has been converted into a shiny, modern portlet. You should also refer to this CSS file in trunk for portlet development (which includes the JSR-168 spec and is amply commented):<br><br>\uportal-war\src\main\webapp\media\skins\universality\uportal3\uportal3_portlet.css<br><br>T2. FSS for grids and layout<br>FSS (included in uPortal) comes with an excellent layout/grid framework. The FSS layout framework is being used to render the main uPortal UI layout (multi-column and sidebars - all without tables!). Refer to this FSS primer: <a href="http://wiki.fluidproject.org/x/-gBS" target="_top" rel="nofollow">http://wiki.fluidproject.org/x/-gBS</a><br><br>T3. Making an unordered list into tabs<br>On the 3.1.x release with FSS, this is simple and quick (rather beautiful overall). Simply take your semantic unordered list markup and sprinkle in a few FSS classes (I would also encourage some meaningful ARIA roles for accessibility):<br><pre class="code-html"><span class="code-tag"><div class=<span class="code-quote">"fl-container-flex"</span>></span><br> <span class="code-tag"><ul</span><span class="code-tag"> role="tablist"</span><span class="code-tag"> class=<span class="code-quote">"fl-tabs fl-tabs-left"</span>></span><br> <span class="code-tag"><li role="tab" class=<span class="code-quote">"fl-activeTab"</span>></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Active Tab<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"><li role="tab"></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Tab #2<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"><li role="tab"></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Tab #3<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"></ul></span><br> <span class="code-tag"><div role="tabpanel" class=<span class="code-quote">"fl-tab-content"</span>></span><br> Content<br> <span class="code-tag"></div></span><br><span class="code-tag"></div></span><br></pre>Viola! And you don't have to edit CSS at all. FSS layout makes the unordered list into tabs, and FSS themes (uPortal skins) style the tabs to match the currently selected skin.<br><br>Sadly, this will produce no tangible result in uPortal 2.5.3 - you'll still have a basic, unordered list in the user interface. What to do? Here's where we clearly demonstrate the shortcomings of the JSR-168 CSS specification (I'll try not to be overly sarcastic in my example).<br><br>CSS classes are free (or at least cheap), so in most senses, there is no harm in layering on additional CSS classes into the markup. So let's think about layering in JSR-168 CSS classes to support non-FSS implementations. First, let's consult the JSR-168 spec to see what is available. After perusal, it looks like this section makes sense:<br><br>PLT.C.6. Menus<br>"Menu styles define the look-and-feel of the text and background of a
menu structure. This structure may be embedded in the aggregated page
or may appear as a context sensitive popup menu."<br><br>Umm, okay, that definition makes it clear how I am supposed to use the spec... or not. Let's see if we can make sense of the classes they give us:<br><br><table class="confluenceTable"><tbody><tr><td class="confluenceTd">portlet-menu</td>
<td class="confluenceTd">General menu settings such as background color, margins, etc.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-item</td>
<td class="confluenceTd">Normal, unselected menu item.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-item-selected</td>
<td class="confluenceTd">Selected menu item.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-item-hover</td>
<td class="confluenceTd">Normal, unselected menu item when the mouse hovers over it.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-item-hover-selected</td>
<td class="confluenceTd">Selected menu item when the mouse hovers over it.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-cascade-item</td>
<td class="confluenceTd">Normal, unselected menu item that has submenus.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-cascade-item-selected</td>
<td class="confluenceTd">Selected sub-menu item that has sub-menus.</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-description</td>
<td class="confluenceTd">Descriptive text for the menu (e.g. in a help context below the menu).</td>
</tr>
<tr>
<td class="confluenceTd">portlet-menu-caption</td>
<td class="confluenceTd">Menu caption.</td></tr></tbody></table><br>Why we need to specifically delineate "portlet-menu-item" on the <li> (when the <li> is contained in a <ul> already specified as a "portlet-menu") is lost on me, but okay. And we're supposed to put in a CSS class "portlet-menu-item-hover" for mouse-hover? Isn't there such a thing as :hover in the CSS spec itself? There's some stuff in there that could be used (though a Menu caption? Really? And the desciption is so helpful.), but the point is that even something as basic as a menu is not well designed or defined in the JSR-168 CSS spec. And note there is no JSR-168 class for the associated tabpanel. <br><br>Taking these classes we could add in the following to our markup:<br><br><pre class="code-html"><span class="code-tag"><div class=<span class="code-quote">"fl-container-flex"</span>></span><br> <span class="code-tag"><ul</span><span class="code-tag"> role="tablist"</span><span class="code-tag"> class=<span class="code-quote">"fl-tabs fl-tabs-left portlet-menu"</span>></span><br> <span class="code-tag"><li role="tab" class=<span class="code-quote">"fl-activeTab portlet-menu-item-selected"</span>></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Active Tab<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"><li role="tab" class="portlet-menu-item"></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Tab #2<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"><li role="tab"</span><span class="code-tag"> class="portlet-menu-item"</span><span class="code-tag">></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Tab #3<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"></ul></span><br> <span class="code-tag"><div role="tabpanel" class=<span class="code-quote">"fl-tab-content"</span>></span><br> Content<br> <span class="code-tag"></div></span><br><span class="code-tag"></div></span></pre>
And we would discover that this has done very little to our UI result in 2.5.3. Still no tabs, just an unordered list with maybe a bit of styling applied. Why? Because there is no context. What KIND of menu is this? Nothing in the JSR-168 spec specifies this as a TAB menu. Well, we could define that in the CSS by making all .portlet-menu .portlet-menu-item elements inline or floated and so forth. Super! (except that you had to figure out and test that across browsers on your own effort, which is painful, trust me). Now we have tabs from our unordered list. But wait - now EVERYWHERE that these classes are used will be converted to TABS, whether they are contextually tabs or not. The JSR-168 spec does not give us classes to define the context.<br><br>So, okay, we could add the context to the container <div>, like so:<br><br><pre class="code-html"><span class="code-tag"><div class=<span class="code-quote">"fl-container-flex portlet-menu-tabs"</span>></span><br> <span class="code-tag"><ul</span><span class="code-tag"> role="tablist"</span><span class="code-tag"> class=<span class="code-quote">"fl-tabs fl-tabs-left portlet-menu"</span>></span><br> <span class="code-tag"><li role="tab" class=<span class="code-quote">"fl-activeTab portlet-menu-item-selected"</span>></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Active Tab<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"><li role="tab" class="portlet-menu-item"></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Tab #2<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"><li role="tab"</span><span class="code-tag"> class="portlet-menu-item"</span><span class="code-tag">></span><span class="code-tag"><a href=<span class="code-quote">"#_bottom"</span>></span>Tab #3<span class="code-tag"></a></span><span class="code-tag"></li></span><br> <span class="code-tag"></ul></span><br> <span class="code-tag"><div role="tabpanel" class=<span class="code-quote">"fl-tab-content"</span>></span><br> Content<br> <span class="code-tag"></div></span><br><span class="code-tag"></div></span></pre>
And then solve the problem in the CSS with selectors like:<br><br>.portlet-menu-tabs .portlet-menu .portlet-menu-item {}<br><br>So that only those specifications are applied to make an unordered list into tabs when the parent .portlet-menu-tabs class is present. However, now we have broken the standard. No one will get the benefit of using these classes to achieve tabs from an unordered list without knowing to put the .portlet-menu-tabs class on the containing element. And even if that class is on the containing element, if you take the portlet out of uPortal and try to use it elsewhere, it will revert to an undesireable, plain unordered list. You could say the same about FSS (that it isn't portable), but it IS easily includable and relieves us from having to solve the problem, test the solution, and maintain the standard.<br><br>My recommendation: include FSS into your CSS includes in your 2.5.3 skin (minimally fss-layout.css), and you will at least get the basic structural benefits without doing any extra work and without complicating the markup with the JSR-168 classes. Besides, after including the JSR-168 classes, if you were to stumble on this markup, which classes do you use/modify? The FSS ones, or the JSR-168 ones? And if they are both (FSS and JSR-168) trying to make tabs out of an unordered list, you are going to get some ugly CSS conflicts. I like to Keep It Simple. The FSS markup is much cleaner, and does the job much better, with little effort required on your part as the implementor.<br><br>Hope that helps. I welcome more discussion on these matters.<br><br><br>Gary Thompson<br>User Experience Leader<br>Unicon | www.unicon.net<br><br><br>----- Original Message -----<br>From: "Gary Weaver" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931057&i=0" target="_top" rel="nofollow">gary.weaver@...</a>><br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931057&i=1" target="_top" rel="nofollow">jasig-ue@...</a><br>Sent: Thursday, October 15, 2009 10:51:42 AM GMT -07:00 U.S. Mountain Time (Arizona)<br>Subject: Re:[jasig-ue] portlet UI design guidelines?<br><br>I should probably clarify that in the MailPortlet when you click on a <br>tab, that it when it queries the pop3/imap server for mail, so I'm not <br>looking for a show/hide div type of thing, but rather either the <br>standard CSS classes that display line-items horizontally (in a way <br>friendly to various existing skins in both uPortal 2.5.3 and uPortal <br>3.1.1) or something (that I'm not guessing would be a simple?) that not <br>only display tabs but would use Ajax to load the chosen tab in the <br>background and to do this in a skin-friendly way (specifically in the <br>formatting of the tabs) that hopefully could work without much problem <br>in both uPortal 2.5.3 and 3.1.1. The following is basically what I'm <br>showing for tabs atop the mail message list table (I made up the class <br>names to show what I'm looking for):<br><br><ul <br>class="some-well-used-skin-class-to-indicate-these-are-tabs-and-therefore-this-unordered-list-should-be-composed-of-blocked-bordered-and-backgrounded-inline-line-items"><br> <li>...</li><br> <li <br>class="some-well-used-skin-class-to-indicate-this-inline-line-item-tab-is-selected">...</li><br> <li>...</li><br></ul><br><br>It looks like maybe the thing to use in uPortal 3.1.1 is fl-tabs as the <br>class name and fl-activeTab for the selected tab. But can I just define <br>those in the portlet's CSS so that it works in older versions without it <br>overriding the newer stuff in uPortal 3.1.1?<br><br>And for table formatting, I was just checking to see what the best way <br>to define the table and its classes are or what you would say is a <br>uPortal 2.5.3 and 3.1.1 friendly way to define a table in a portlet. I <br>currently have the following for the display of mail messages, but I'm <br>guessing I could do better?:<br><br> <%-- is there any nice column-resizing <br>javascript deal available via uP 3.1 and if so could we include that in <br>the portlet so that it could be used in both earlier and later versions <br>of uPortal? %--><br> <table <br>class="is-there-some-sort-of-standard-uportal-skin-class-that-should-be-used-here-that-might-add-a-border-or-similar"><br> <tbody><br> <c:forEach <br>items="${selectedMailAccountDetails.stubs}" var="stub" varStatus="counter"><br> <c:set var="className">${ (counter.index <br>% 2 == 0) ? 'portlet-section-body' : 'portlet-section-alternate'} <br>${stub.seen ? 'mailportlet-read-message' : <br>'mailportlet-unread-message'}</c:set><br> <tr class="${className}"><br> <td><br> <c:if test="${stub.flagged}"><br> <%-- am guessing maybe there <br>are famfamfam icons for these, but then should resource-server be a <br>requirement since it serves those in 3.1 or should they be included in <br>the portlet to be compatible with older uPortal versions? --%><br> <img <br>src="<%=request.getContextPath()%>/images/star.png"/><br> </c:if><br> <c:if test="${stub.answered}"><br> <img <br>src="<%=request.getContextPath()%>/images/answered.png"/><br> </c:if><br> <c:if test="${not stub.flagged <br>&& not stub.answered}"><br> <%-- it just looks bad when <br>there are no flags on any messages. assuming this column have some sort <br>of minimum width. --%><br> &nbsp;<br> </c:if><br> </td><br> <td><span class=${stub.deleted ? <br>'mailportlet-deleted-message' : ''}><br> <a <br>href="${selectedMailAccountDetails.link}"><c:choose><c:when <br>test="${empty stub.from}"><fmt:message <br>key="noSender"/></c:when><c:otherwise><c:out<br> <br>value="${stub.from}"/></c:otherwise></c:choose></a></span></td><br> <td><span class=${stub.deleted ? <br>'mailportlet-deleted-message' : ''}><a <br>href="${selectedMailAccountDetails.link}"><c:choose><c:when <br>test="${empty stub.subject}"><fmt:message <br>key="noSubject"/></c:when><c:otherwise><c:out<br> <br>value="${stub.subject}"/></c:otherwise></c:choose></a></span></td><br> <td><span class=${stub.deleted ? <br>'mailportlet-deleted-message' : ''}><a <br>href="${selectedMailAccountDetails.link}"><c:choose><c:when <br>test="${empty stub.received}"><fmt:message <br>key="noDate"/></c:when><c:otherwise><c:out<br> <br>value="${stub.received}"/></c:otherwise></c:choose></a></span></td><br> </tr><br> </c:forEach><br> </tbody><br> </table><br><br>Thanks,<br>Gary<br><br><br>Gary Weaver wrote:<div class='shrinkable-quote'><br>> (sorry to cross-post, but I don't know where to send this)<br>><br>> Am having a little bit of a dilemma working on the MailPortlet UI and <br>> thought maybe someone could provide some guidance.<br>><br>> * I want to use what I can of what standards I should from PLT.C CSS <br>> classes of JSR-168, and am trying to make it utilize the classes as <br>> defined in the default skin of uPortal 3.1.1 for reference <br>> (skins/universality/uportal3/jsr168_portlet_spec.css) just to have a <br>> better feel for what it would look like in the future if we were to <br>> upgrade uPortal 3.1+. I know that these classes were also defined in <br>> uPortal 2.5.3 skins, but I haven't looked at how those would look yet.<br>><br>> * Those classes in the default skin of uP 3.1.1 at least seem to just <br>> define background color, border color, change a few font sizes/bold a <br>> few things, and do some light padding/margin changes.<br>><br>> * Things like portlet-section-header, portlet-section-subheader, and <br>> portlet-form-label aren't defining "display: block;" and therefore <br>> also not defining margins/padding, so I'm unclear as to whether those <br>> should be headers (h3, h4, ...) or label elements (all seem like they <br>> should be headers I guess).<br>><br>> * I need other CSS classes to make nice (list item) tabs across the <br>> top of the main MailPortlet view<br>><br>> * I need other CSS classes to do some better formatting of the table <br>> containing the list of the most recent email messages for a specific <br>> account (which has columns for flags, sender, subject, and date like <br>> you'd expect in the main message list view a mail client)<br>><br>> * It would be great (but not totally necessary) to have resizeable <br>> columns in the table (so some standard javascript to assist with that <br>> might be nice) or at the very least to have it defined the table<br>><br>> My questions are:<br>><br>> * Were there CSS classes that did that in the standard skins that came <br>> with uPortal 2.5.3 (I'm looking through them now- not sure)? Do those <br>> still apply for uP 3.1.1?<br>><br>> * Could you point me at specific examples of portlets or other places <br>> in uPortal 3.1.1 that do a good job (list item) tabs and grid/table <br>> formatting like I'm talking about in a uPortal-skin friendly way?<br>><br>> * What level of header should portlet-section-header, <br>> portlet-section-subheader, and portlet-form-label be to have <br>> consistency throughout portlets and if they should be labels, what <br>> additional classes should be used if any to define that they should be <br>> display:block and to define their margins/padding?<br>><br>> * Do you think that ResourceServer should be a requirement for <br>> portlets to display correctly from here on out, and if so, do you know <br>> of anyone using it with older versions of uPortal?<br>><br>> I completely understand that at some point the past has to be left <br>> behind and newer portlets should only work with uPortal 3.1+, but for <br>> those of us that want to contribute in such a way that portlets can be <br>> used in both uPortal 3.1.1+ and uPortal 2.5.3, I want to make sure <br>> that I'm defining things correctly and defining portlet-specific CSS <br>> and/or reusing skin CSS in a way that is kosher for both environments <br>> (at least for now, if it makes sense).<br>><br>> Thanks!<br>><br>> Gary<br>></div><br><br>-- <br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931057&i=2" target="_top" rel="nofollow">jasig-ue@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931057&i=3" target="_top" rel="nofollow">gary@...</a><br>To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue<br></div></div></div></div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931057&i=4" target="_top" rel="nofollow">uportal-dev@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25931057&i=5" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev</pre>
</BODY></html><p>From forum: <a href="http://old.nabble.com/uPortal---Developer-f22545.html" embed="fixTarget[22545]" target="_top" >uPortal - Developer</a></p>tag:old.nabble.com,2006:post-25930869Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T12:18:31Z2009-10-16T12:18:31ZSusan Bramhall<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
We've been using jndi datasources successfully ever since we went to
3.1 with no problems... We have a shared pool used by several portlets
and the portal itself. It would be hard for us to do it without jndi
since developers don't have access to those credentials. They are all
using Spring. Not sure what we are doing right that others have
stumbled on. Sample snippet from a portlet context:<br>
<br>
<bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean"><br>
<property name="jndiName"
value="java:comp/env/jdbc/uPortalDB"/><br>
</bean><br>
<br>
I'd be curious to know what your problems have been.<br>
Susan<br>
<br>
Eric Dalquist wrote:
<blockquote cite="mid:4AD8C0C9.2090604@doit.wisc.edu" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
This isn't very helpful for your current problem but we haven't used
JNDI managed DataSources in uPortal or our portlets since upgrading to
3.0. They always seem to have some sort of issue and a locally declared
DBCP DataSource in the Spring app context seems to work much better.<br>
<br>
-Eric<br>
<br>
Curtis Garman wrote:
<blockquote cite="mid:17959_1255719027_ZZg0H3xk0xqrZ.00_70ca076d0910161150o31279f6dwb6ca36af45e81b71@mail.gmail.com" type="cite">
<pre wrap="">Since the connection pool is only used by a single portlet and there
is no need for any other webapp to see it, I placed my Resource in the
the context.xml of my application (portlet)...I had tried placing my
driver in the shared/lib too but that didn't help.
On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=0" target="_top" rel="nofollow">susan.bramhall@...</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Are you putting the jndi information in the server context.xml or in the
applicationContext.xml? It has to be in the server context to allow all the
portlets to share the connections. And the jdbc library has to be shared as
well.
Susan
Curtis Garman wrote:
Does anyone have experience using jndi database resources for portlets
that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
are running via jndi connection pooling in our uportal 2.6.1
environment on tomcat 5.5.25 and while they work great for 2.6.1, I
can't get the portlets to run on 3.1.1 unless I hard-code the
connection information into the portlets. The portlets are not
spring-based at this point. I keep getting the following exception
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
My context.xml configuration is as follows
<Resource name="jdbc/cancellation" auth="Container"
type="javax.sql.DataSource"
username="user" password="password"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
maxActive="10" maxIdle="5" maxWait="1000"
poolPreparedStatements="true"
removeAbandoned="true"
removeAbandonedTimeout="300"
logAbandoned="true"
/>
I usually do not use the web.xml resource-ref...it seems to work without
it...
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/cancellation</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
...and it actually starts throwing a different error when I include it
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
driver of class '' for connect URL 'null'
I tried moving my context.xml to conf/Catalina/localhost and changing
the name of the file to appname.xml and this gave me yet another error
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
driver class 'net.sourceforge.jtds.jdbc.Driver'
Does anyone have any ideas?
--
Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>)
Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=2" target="_top" rel="nofollow">uportal-user@...</a> as:
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=3" target="_top" rel="nofollow">curt.garman@...</a>
To unsubscribe, change settings or access archives, see
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered)">
<div class="Section1">
<p class="MsoNormal"><span style="color: blue;">Susan Bramhall</span> (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=4" target="_top" rel="nofollow">susan.bramhall@...</a>)<br>
Senior Developer, Infrastructure Systems and Architecture (formerly
T&P)<br>
Yale University Information Technology Services (ITS)<br>
25 Science Park, 150 Munson St, New Haven, CT 06520<br>
Phone: 203 432 6697</p>
</div>
</div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=5" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930869&i=6" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25930727Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T12:07:02Z2009-10-16T12:07:02ZEric Dalquist<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Curtis Garman wrote:
<blockquote cite="mid:18630_1255719839_ZZg0H3xs3yBAl.00_70ca076d0910161203s174e970dy1f404eb1df33ca25@mail.gmail.com" type="cite">
<pre wrap="">Actually that is somewhat helpful because I've noticed others in the
community are doing the same thing...I could easily enough convert the
before mentioned portlets to spring...however spring development
hasn't quite been sanctioned here yet. What you just said will be
helpful in lobbying for it :)
</pre>
</blockquote>
Glad to help ;)<br>
<blockquote cite="mid:18630_1255719839_ZZg0H3xs3yBAl.00_70ca076d0910161203s174e970dy1f404eb1df33ca25@mail.gmail.com" type="cite">
<pre wrap="">
One reason why I am interested in using jndi over an internal pool is
because we use lamba probe to help monitor things and it provides a
nice web interface to be able to view jndi connection pools and how
many open connections there are for each. I really don't want to lose
that if possible.
</pre>
</blockquote>
You can take a look at jmxContext.xml in uPortal to see an example of
using Spring to easily expose things such as local DataSource pools via
JMX. Not sure if lamba prob can talk JMX but uPortal exposes a whole
bunch of data that way.<br>
<blockquote cite="mid:18630_1255719839_ZZg0H3xs3yBAl.00_70ca076d0910161203s174e970dy1f404eb1df33ca25@mail.gmail.com" type="cite">
<pre wrap="">
Another thing that makes the jndi thing problematic is that related to
another thread I started too...I set up a portlet overlay to apply all
customizations to our portlets...but it seemes to loose all
context.xml files from the META-INF directory...which obviously hurts
when using this file to link to or provide credentials to your
datasource.
</pre>
</blockquote>
Does the default overlay configuration include any <excluded>
paths? That would be my first guess in diagnosing that. Perhaps add an
explicit include in the overlay config?<br>
<blockquote cite="mid:18630_1255719839_ZZg0H3xs3yBAl.00_70ca076d0910161203s174e970dy1f404eb1df33ca25@mail.gmail.com" type="cite">
<pre wrap="">
Curtis
On Fri, Oct 16, 2009 at 1:51 PM, Eric Dalquist
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930727&i=0" target="_top" rel="nofollow">eric.dalquist@...</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This isn't very helpful for your current problem but we haven't used JNDI
managed DataSources in uPortal or our portlets since upgrading to 3.0. They
always seem to have some sort of issue and a locally declared DBCP
DataSource in the Spring app context seems to work much better.
-Eric
Curtis Garman wrote:
Since the connection pool is only used by a single portlet and there
is no need for any other webapp to see it, I placed my Resource in the
the context.xml of my application (portlet)...I had tried placing my
driver in the shared/lib too but that didn't help.
On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930727&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>
wrote:
Are you putting the jndi information in the server context.xml or in the
applicationContext.xml? It has to be in the server context to allow all the
portlets to share the connections. And the jdbc library has to be shared as
well.
Susan
Curtis Garman wrote:
Does anyone have experience using jndi database resources for portlets
that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
are running via jndi connection pooling in our uportal 2.6.1
environment on tomcat 5.5.25 and while they work great for 2.6.1, I
can't get the portlets to run on 3.1.1 unless I hard-code the
connection information into the portlets. The portlets are not
spring-based at this point. I keep getting the following exception
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
My context.xml configuration is as follows
<Resource name="jdbc/cancellation" auth="Container"
type="javax.sql.DataSource"
username="user" password="password"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
maxActive="10" maxIdle="5" maxWait="1000"
poolPreparedStatements="true"
removeAbandoned="true"
removeAbandonedTimeout="300"
logAbandoned="true"
/>
I usually do not use the web.xml resource-ref...it seems to work without
it...
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/cancellation</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
...and it actually starts throwing a different error when I include it
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
driver of class '' for connect URL 'null'
I tried moving my context.xml to conf/Catalina/localhost and changing
the name of the file to appname.xml and this gave me yet another error
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
driver class 'net.sourceforge.jtds.jdbc.Driver'
Does anyone have any ideas?
--
Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930727&i=2" target="_top" rel="nofollow">susan.bramhall@...</a>)
Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930727&i=3" target="_top" rel="nofollow">uportal-user@...</a> as:
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930727&i=4" target="_top" rel="nofollow">curt.garman@...</a>
To unsubscribe, change settings or access archives, see
<a class="moz-txt-link-freetext" href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
<br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://old.nabble.com/attachment/25930727/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25930661Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T12:03:25Z2009-10-16T12:03:25ZCurtis GarmanActually that is somewhat helpful because I've noticed others in the
<br>community are doing the same thing...I could easily enough convert the
<br>before mentioned portlets to spring...however spring development
<br>hasn't quite been sanctioned here yet. What you just said will be
<br>helpful in lobbying for it :)
<br><br>One reason why I am interested in using jndi over an internal pool is
<br>because we use lamba probe to help monitor things and it provides a
<br>nice web interface to be able to view jndi connection pools and how
<br>many open connections there are for each. I really don't want to lose
<br>that if possible.
<br><br>Another thing that makes the jndi thing problematic is that related to
<br>another thread I started too...I set up a portlet overlay to apply all
<br>customizations to our portlets...but it seemes to loose all
<br>context.xml files from the META-INF directory...which obviously hurts
<br>when using this file to link to or provide credentials to your
<br>datasource.
<br><br>Curtis
<br><br><br>On Fri, Oct 16, 2009 at 1:51 PM, Eric Dalquist
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=0" target="_top" rel="nofollow">eric.dalquist@...</a>> wrote:
<div class='shrinkable-quote'><br>> This isn't very helpful for your current problem but we haven't used JNDI
<br>> managed DataSources in uPortal or our portlets since upgrading to 3.0. They
<br>> always seem to have some sort of issue and a locally declared DBCP
<br>> DataSource in the Spring app context seems to work much better.
<br>>
<br>> -Eric
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Since the connection pool is only used by a single portlet and there
<br>> is no need for any other webapp to see it, I placed my Resource in the
<br>> the context.xml of my application (portlet)...I had tried placing my
<br>> driver in the shared/lib too but that didn't help.
<br>>
<br>> On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>>
<br>> wrote:
<br>>
<br>>
<br>> Are you putting the jndi information in the server context.xml or in the
<br>> applicationContext.xml? It has to be in the server context to allow all the
<br>> portlets to share the connections. And the jdbc library has to be shared as
<br>> well.
<br>> Susan
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Does anyone have experience using jndi database resources for portlets
<br>> that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
<br>> are running via jndi connection pooling in our uportal 2.6.1
<br>> environment on tomcat 5.5.25 and while they work great for 2.6.1, I
<br>> can't get the portlets to run on 3.1.1 unless I hard-code the
<br>> connection information into the portlets. The portlets are not
<br>> spring-based at this point. I keep getting the following exception
<br>>
<br>> javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
<br>>
<br>> My context.xml configuration is as follows
<br>>
<br>> <Resource name="jdbc/cancellation" auth="Container"
<br>> type="javax.sql.DataSource"
<br>> username="user" password="password"
<br>> driverClassName="net.sourceforge.jtds.jdbc.Driver"
<br>> url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
<br>> maxActive="10" maxIdle="5" maxWait="1000"
<br>> poolPreparedStatements="true"
<br>> removeAbandoned="true"
<br>> removeAbandonedTimeout="300"
<br>> logAbandoned="true"
<br>> />
<br>>
<br>> I usually do not use the web.xml resource-ref...it seems to work without
<br>> it...
<br>>
<br>> <resource-ref>
<br>> <description>DB Connection</description>
<br>> <res-ref-name>jdbc/cancellation</res-ref-name>
<br>> <res-type>javax.sql.DataSource</res-type>
<br>> <res-auth>Container</res-auth>
<br>> </resource-ref>
<br>>
<br>> ...and it actually starts throwing a different error when I include it
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
<br>> driver of class '' for connect URL 'null'
<br>>
<br>> I tried moving my context.xml to conf/Catalina/localhost and changing
<br>> the name of the file to appname.xml and this gave me yet another error
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
<br>> driver class 'net.sourceforge.jtds.jdbc.Driver'
<br>>
<br>> Does anyone have any ideas?
<br>>
<br>>
<br>>
<br>> --
<br>>
<br>> Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=2" target="_top" rel="nofollow">susan.bramhall@...</a>)
<br>> Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
<br>> Yale University Information Technology Services (ITS)
<br>> 25 Science Park, 150 Munson St, New Haven, CT 06520
<br>> Phone: 203 432 6697
<br>>
<br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=3" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=4" target="_top" rel="nofollow">curt.garman@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br>>
<br>>
<br>>
</div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=5" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930661&i=6" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25930493Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T11:51:53Z2009-10-16T11:51:53ZEric Dalquist<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
This isn't very helpful for your current problem but we haven't used
JNDI managed DataSources in uPortal or our portlets since upgrading to
3.0. They always seem to have some sort of issue and a locally declared
DBCP DataSource in the Spring app context seems to work much better.<br>
<br>
-Eric<br>
<br>
Curtis Garman wrote:
<blockquote cite="mid:17959_1255719027_ZZg0H3xk0xqrZ.00_70ca076d0910161150o31279f6dwb6ca36af45e81b71@mail.gmail.com" type="cite">
<pre wrap="">Since the connection pool is only used by a single portlet and there
is no need for any other webapp to see it, I placed my Resource in the
the context.xml of my application (portlet)...I had tried placing my
driver in the shared/lib too but that didn't help.
On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930493&i=0" target="_top" rel="nofollow">susan.bramhall@...</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Are you putting the jndi information in the server context.xml or in the
applicationContext.xml? It has to be in the server context to allow all the
portlets to share the connections. And the jdbc library has to be shared as
well.
Susan
Curtis Garman wrote:
Does anyone have experience using jndi database resources for portlets
that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
are running via jndi connection pooling in our uportal 2.6.1
environment on tomcat 5.5.25 and while they work great for 2.6.1, I
can't get the portlets to run on 3.1.1 unless I hard-code the
connection information into the portlets. The portlets are not
spring-based at this point. I keep getting the following exception
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
My context.xml configuration is as follows
<Resource name="jdbc/cancellation" auth="Container"
type="javax.sql.DataSource"
username="user" password="password"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
maxActive="10" maxIdle="5" maxWait="1000"
poolPreparedStatements="true"
removeAbandoned="true"
removeAbandonedTimeout="300"
logAbandoned="true"
/>
I usually do not use the web.xml resource-ref...it seems to work without
it...
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/cancellation</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
...and it actually starts throwing a different error when I include it
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
driver of class '' for connect URL 'null'
I tried moving my context.xml to conf/Catalina/localhost and changing
the name of the file to appname.xml and this gave me yet another error
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
driver class 'net.sourceforge.jtds.jdbc.Driver'
Does anyone have any ideas?
--
Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930493&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>)
Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930493&i=2" target="_top" rel="nofollow">uportal-user@...</a> as:
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930493&i=3" target="_top" rel="nofollow">curt.garman@...</a>
To unsubscribe, change settings or access archives, see
<a class="moz-txt-link-freetext" href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
<br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://old.nabble.com/attachment/25930493/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25930464Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T11:50:10Z2009-10-16T11:50:10ZCurtis GarmanSince the connection pool is only used by a single portlet and there
<br>is no need for any other webapp to see it, I placed my Resource in the
<br>the context.xml of my application (portlet)...I had tried placing my
<br>driver in the shared/lib too but that didn't help.
<br><br>On Fri, Oct 16, 2009 at 1:06 PM, Susan Bramhall <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930464&i=0" target="_top" rel="nofollow">susan.bramhall@...</a>> wrote:
<div class='shrinkable-quote'><br>> Are you putting the jndi information in the server context.xml or in the
<br>> applicationContext.xml? It has to be in the server context to allow all the
<br>> portlets to share the connections. And the jdbc library has to be shared as
<br>> well.
<br>> Susan
<br>>
<br>> Curtis Garman wrote:
<br>>
<br>> Does anyone have experience using jndi database resources for portlets
<br>> that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
<br>> are running via jndi connection pooling in our uportal 2.6.1
<br>> environment on tomcat 5.5.25 and while they work great for 2.6.1, I
<br>> can't get the portlets to run on 3.1.1 unless I hard-code the
<br>> connection information into the portlets. The portlets are not
<br>> spring-based at this point. I keep getting the following exception
<br>>
<br>> javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
<br>>
<br>> My context.xml configuration is as follows
<br>>
<br>> <Resource name="jdbc/cancellation" auth="Container"
<br>> type="javax.sql.DataSource"
<br>> username="user" password="password"
<br>> driverClassName="net.sourceforge.jtds.jdbc.Driver"
<br>> url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
<br>> maxActive="10" maxIdle="5" maxWait="1000"
<br>> poolPreparedStatements="true"
<br>> removeAbandoned="true"
<br>> removeAbandonedTimeout="300"
<br>> logAbandoned="true"
<br>> />
<br>>
<br>> I usually do not use the web.xml resource-ref...it seems to work without
<br>> it...
<br>>
<br>> <resource-ref>
<br>> <description>DB Connection</description>
<br>> <res-ref-name>jdbc/cancellation</res-ref-name>
<br>> <res-type>javax.sql.DataSource</res-type>
<br>> <res-auth>Container</res-auth>
<br>> </resource-ref>
<br>>
<br>> ...and it actually starts throwing a different error when I include it
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
<br>> driver of class '' for connect URL 'null'
<br>>
<br>> I tried moving my context.xml to conf/Catalina/localhost and changing
<br>> the name of the file to appname.xml and this gave me yet another error
<br>>
<br>> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
<br>> driver class 'net.sourceforge.jtds.jdbc.Driver'
<br>>
<br>> Does anyone have any ideas?
<br>>
<br>>
<br>>
<br>> --
<br>>
<br>> Susan Bramhall (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930464&i=1" target="_top" rel="nofollow">susan.bramhall@...</a>)
<br>> Senior Developer, Infrastructure Systems and Architecture (formerly T&P)
<br>> Yale University Information Technology Services (ITS)
<br>> 25 Science Park, 150 Munson St, New Haven, CT 06520
<br>> Phone: 203 432 6697
<br>>
<br>> --
<br>>
<br>> You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930464&i=2" target="_top" rel="nofollow">uportal-user@...</a> as:
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930464&i=3" target="_top" rel="nofollow">curt.garman@...</a>
<br>> To unsubscribe, change settings or access archives, see
<br>> <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a></div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930464&i=4" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930464&i=5" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25930007XSLT Cache Behavior2009-10-16T11:16:42Z2009-10-16T11:16:42ZArlo Whiteportal.properties has the following section
<br><br># Controls whether or not pre-compiled stylesheets should be cached.
<br># Setting this to "on" improves performance, but then changes to
<br># any stylesheet files (.xsl) will not take effect until
<br># the portal has been restarted.
<br>#
<br>org.jasig.portal.utils.XSLT.stylesheet_root_caching=on
<br><br>This seems to indicate that .xsl files are cached permanently. However,
<br>some of our that channels pull in xsl files externally seem to update
<br>after a file change in about 4 hours. How does XSL caching work in the
<br>portal? Does the caching behavior change depending on whether the xsl
<br>files are local or external?
<br><br>To be clear, I'm talking about native uPortal channels where the .ssl
<br>file has external and/or internal urls, for example:
<br><?xml-stylesheet title="viewRecord"
<br>href="<a href="http://calpoly.edu/some/external/source/file.xsl" target="_top" rel="nofollow">http://calpoly.edu/some/external/source/file.xsl</a>" type="text/xsl"
<br>media="all"?>
<br><?xml-stylesheet title="viewHelp"
<br>href="/edu/calpoly/internal/channel/file.xsl" type="text/xsl"
<br>media="netscape"?>
<br><br /><tt>[awhite.vcf]</tt><br /><hr align="left" width="300" /><tt>begin:vcard
<br>fn:Arlo White
<br>n:White;Arlo
<br>org:ITS;Application Integration
<br>adr;dom:Calpoly;;Chase Hall, Room 215;San Luis Obispo;CA
<br>email;internet:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25930007&i=0" target="_top" rel="nofollow">awhite@...</a>
<br>title:Analyst/Programmer
<br>tel;work:(805) 756-5211
<br>x-mozilla-html:TRUE
<br>version:2.1
<br>end:vcard
<br><br></tt><hr align="left" width="300" /><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (4K) <a href="http://old.nabble.com/attachment/25930007/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25929848Re: trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T11:06:16Z2009-10-16T11:06:16ZSusan Bramhall<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Are you putting the jndi information in the server context.xml or in
the applicationContext.xml? It has to be in the server context to
allow all the portlets to share the connections. And the jdbc library
has to be shared as well.<br>
Susan<br>
<br>
Curtis Garman wrote:
<blockquote cite="mid:70ca076d0910161027i32922a1eqee9dd3c7a67686bc@mail.gmail.com" type="cite">
<pre wrap="">Does anyone have experience using jndi database resources for portlets
that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
are running via jndi connection pooling in our uportal 2.6.1
environment on tomcat 5.5.25 and while they work great for 2.6.1, I
can't get the portlets to run on 3.1.1 unless I hard-code the
connection information into the portlets. The portlets are not
spring-based at this point. I keep getting the following exception
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
My context.xml configuration is as follows
<Resource name="jdbc/cancellation" auth="Container" type="javax.sql.DataSource"
username="user" password="password"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
maxActive="10" maxIdle="5" maxWait="1000"
poolPreparedStatements="true"
removeAbandoned="true"
removeAbandonedTimeout="300"
logAbandoned="true"
/>
I usually do not use the web.xml resource-ref...it seems to work without it...
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/cancellation</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
...and it actually starts throwing a different error when I include it
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
driver of class '' for connect URL 'null'
I tried moving my context.xml to conf/Catalina/localhost and changing
the name of the file to appname.xml and this gave me yet another error
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
driver class 'net.sourceforge.jtds.jdbc.Driver'
Does anyone have any ideas?
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered)">
<div class="Section1">
<p class="MsoNormal"><span style="color: blue;">Susan Bramhall</span> (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929848&i=0" target="_top" rel="nofollow">susan.bramhall@...</a>)<br>
Senior Developer, Infrastructure Systems and Architecture (formerly
T&P)<br>
Yale University Information Technology Services (ITS)<br>
25 Science Park, 150 Munson St, New Haven, CT 06520<br>
Phone: 203 432 6697</p>
</div>
</div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929848&i=1" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929848&i=2" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25929354portlet-overlay method and context.xml2009-10-16T10:33:19Z2009-10-16T10:33:19ZCurtis GarmanI seem to loose my META-INF/context.xml when deploying portlets via
<br>the portlet overlay method...has anyone else experienced this or know
<br>why this is the case?
<br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929354&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929354&i=1" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25929244trouble with jndi database resource, uportal 3.1.1, and tomcat 6.0.202009-10-16T10:27:20Z2009-10-16T10:27:20ZCurtis GarmanDoes anyone have experience using jndi database resources for portlets
<br>that deploy in uportal 3.1.1 on tomcat 6. I've got some portlets we
<br>are running via jndi connection pooling in our uportal 2.6.1
<br>environment on tomcat 5.5.25 and while they work great for 2.6.1, I
<br>can't get the portlets to run on 3.1.1 unless I hard-code the
<br>connection information into the portlets. The portlets are not
<br>spring-based at this point. I keep getting the following exception
<br><br>javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
<br><br>My context.xml configuration is as follows
<br><br> <Resource name="jdbc/cancellation" auth="Container" type="javax.sql.DataSource"
<br> username="user" password="password"
<br> driverClassName="net.sourceforge.jtds.jdbc.Driver"
<br>url="jdbc:jtds:sqlserver://server:1433;databaseName=database"
<br> maxActive="10" maxIdle="5" maxWait="1000"
<br> poolPreparedStatements="true"
<br> removeAbandoned="true"
<br> removeAbandonedTimeout="300"
<br> logAbandoned="true"
<br> />
<br><br>I usually do not use the web.xml resource-ref...it seems to work without it...
<br><br> <resource-ref>
<br> <description>DB Connection</description>
<br> <res-ref-name>jdbc/cancellation</res-ref-name>
<br> <res-type>javax.sql.DataSource</res-type>
<br> <res-auth>Container</res-auth>
<br> </resource-ref>
<br><br>...and it actually starts throwing a different error when I include it
<br><br>org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
<br>driver of class '' for connect URL 'null'
<br><br>I tried moving my context.xml to conf/Catalina/localhost and changing
<br>the name of the file to appname.xml and this gave me yet another error
<br><br>org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC
<br>driver class 'net.sourceforge.jtds.jdbc.Driver'
<br><br>Does anyone have any ideas?
<br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929244&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25929244&i=1" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25928682Handling CAS timeouts and proxy tickets2009-10-16T09:53:46Z2009-10-16T09:53:46ZPaul Gazda<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal>We are running CAS 2 and will be updating to CAS 3. We have
a uPortal directory services channel backed by ldap that allows updates to
personal, department and group data that uses CAS proxy tickets to authenticate
to ldap. When CAS times out every 2 hours, proxy tickets cannot be obtained
until the user authenticates again. Sometimes the expiry can happen while the
user is entering data on an update page. When a submit button is finally
clicked, the CAS credentials have expired and the program’s attempt to
get a proxy ticket can potentially fail, generating an error and requiring that
the user re-enter the data.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>To avoid this, we have filter that traps the browser
request, determines if the CAS ticket is about to expire, and if it is, saves the
request, forces a re-authentication, then replays the request. The problem is
that this approach required significant modifications to the CAS code. We would
like to avoid having to make modifications to the CAS 3 code, but have not yet
come up with a way to either guarantee that a proxy ticket will be available
when a request is made, or seamlessly handle a CAS re-authentication and re-try
getting the proxy ticket to continue the processing stream.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I would appreciate hearing how other institutions have dealt
with the problem of proxy tickets being unavailable in the midst of a
processing stream due to CAS credential expiration.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Thanks.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Paul
Gazda<o:p></o:p></span></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<pre>-- <br />
You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25928682&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25928682&i=1" target="_top" rel="nofollow">lists@...</a><br />To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user</pre>
</BODY>
</html>
<p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25928276Re:Trunk 46830 will not deploy for me2009-10-16T09:15:55Z2009-10-16T09:15:55ZMoore, WilliamThat worked OK. Of course, then I didn't know for sure what I was supposed to do for the deployment. I went ahead and ran ant deploy-ear (without a clean). That also built correctly. I have not yet initialized the database for this version and exported/imported--so that's as far as I can get.
<br><br>I did go ahead and try to log in and it looks like CAS didn't clean. It seems I often need to delete the cas directory in webapps when I apply significant changes to cas. Is that 'normal'? I did run an ant clean before I did anything today.
<br><br>Is there somewhere that the targets are documented a bit more clearly?
<br><br>Thanks much.
<br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25928276&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25928276&i=1" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25927982Re:minimize channels/portlets2009-10-16T09:06:56Z2009-10-16T09:06:56ZMoore, WilliamCan you provide a bit more context for this message about minimizing channels/portlets? It looks like maybe it's in universality.xsl, but it still is not obvious to me where it goes.
<br><br>Thanks.
<br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927982&i=0" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927982&i=1" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25927729Re: uportal 3.1.1 and build filtering2009-10-16T08:53:10Z2009-10-16T08:53:10ZaaronbrownCurtis Garman wrote:
<br>> Aaron, one more question...you mentioned you have three servers...how
<br>> do you handle your project source code? Do you have a copy of the
<br>> project files on each server to be able to redeploy or do you have a
<br>> script or something that deploys across servers or what?
<br><br>We have a test system, used by our QA team for final testing before
<br>release, which is as close a copy to our production system as possible.
<br> We build our production code there (as .war files) and use a script to
<br>deploy to all the servers/tomcats. We have more production servers than
<br>the ones I mentioned, but the others are VMs with one tomcat each -
<br>their performance isn't as good as a real hardware server, so they're
<br>mostly useful during peak usage times. In all, it makes for quite a few
<br>tomcat instances, so we've been using deployment scripts for some time
<br>now and it works pretty well for us.
<br><br> - Aaron
<br><br>--
<br>Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927729&i=0" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>University of Kansas
<br> Information Services
<br> System Design
<br> Enterprise System Integration
<br> Developer
<br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (9K) <a href="http://old.nabble.com/attachment/25927729/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25927573Re: uportal 3.1.1 and build filtering2009-10-16T08:42:45Z2009-10-16T08:42:45ZCurtis GarmanAaron, one more question...you mentioned you have three servers...how
<br>do you handle your project source code? Do you have a copy of the
<br>project files on each server to be able to redeploy or do you have a
<br>script or something that deploys across servers or what?
<br><br>Curtis
<br><br>On Fri, Oct 16, 2009 at 10:29 AM, Curtis Garman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927573&i=0" target="_top" rel="nofollow">curt.garman@...</a>> wrote:
<div class='shrinkable-quote'><br>> Aaron, that worked beautifully...exactly what I was needing to
<br>> accomplish...I still may do some filtering too later too but that is
<br>> definitely a much cleaner way to handle the log4j config...seems to me
<br>>
<br>> log4j.appender.R.File=${catalina.base}/logs/portal.log
<br>>
<br>> should be the default config for the portal and all jasig
<br>> portlets...seems like a good "convention over configuration"
<br>>
<br>>
<br>> On Thu, Oct 15, 2009 at 3:50 PM, Curtis Garman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927573&i=1" target="_top" rel="nofollow">curt.garman@...</a>> wrote:
<br>>> hmm...ok, I'll try it...that's exactly what I'm trying to accomplish
<br>>>
<br>>> On Thu, Oct 15, 2009 at 3:47 PM, Aaron Brown <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927573&i=2" target="_top" rel="nofollow">aaronb@...</a>> wrote:
<br>>>> Curtis Garman wrote:
<br>>>>> Are your tomcat instances on the same server or different servers?
<br>>>>> Mine are on the same server...so not sure that ${catalina.base} would
<br>>>>> do it...each instance of tomcat would need it's own environment
<br>>>>> variable wouldn't it?...I don't want my build dependent on a list of
<br>>>>> environment variables that are dependent on one machine. If you can
<br>>>>> explain your setup further, I would appreciate it.
<br>>>>
<br>>>> In our production environment, we have three servers with six tomcat
<br>>>> instances each. They are each fully self-sufficient copies (no shared
<br>>>> files between them), and they all use identical log4j.properties files,
<br>>>> thanks to the ${catalina.base} property.
<br>>>>
<br>>>> Here is the relevant snippet from our log4j.properties file, with some
<br>>>> placeholder names:
<br>>>>
<br>>>> log4j.appender.Whatever.File=${catalina.base}/logs/SomeLogFile.log
<br>>>>
<br>>>> Log4j is smart enough to detect the root of the tomcat which executed
<br>>>> it, and uses that for its path.
<br>>>>
<br>>>> - Aaron
<br>>>>
<br>>>> --
<br>>>> Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927573&i=3" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>>>> University of Kansas
<br>>>> Information Services
<br>>>> System Design
<br>>>> Enterprise System Integration
<br>>>> Developer
<br>>>>
<br>>>
<br>>>
<br>>>
<br>>> --
<br>>> Curtis Garman
<br>>> Web Programmer
<br>>> Heartland Community College
<br>>>
<br>>
<br>>
<br>>
<br>> --
<br>> Curtis Garman
<br>> Web Programmer
<br>> Heartland Community College
<br>>
</div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927573&i=4" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927573&i=5" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25927311Re: uportal 3.1.1 and build filtering2009-10-16T08:29:06Z2009-10-16T08:29:06ZCurtis GarmanAaron, that worked beautifully...exactly what I was needing to
<br>accomplish...I still may do some filtering too later too but that is
<br>definitely a much cleaner way to handle the log4j config...seems to me
<br><br>log4j.appender.R.File=${catalina.base}/logs/portal.log
<br><br>should be the default config for the portal and all jasig
<br>portlets...seems like a good "convention over configuration"
<br><br><br>On Thu, Oct 15, 2009 at 3:50 PM, Curtis Garman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927311&i=0" target="_top" rel="nofollow">curt.garman@...</a>> wrote:
<div class='shrinkable-quote'><br>> hmm...ok, I'll try it...that's exactly what I'm trying to accomplish
<br>>
<br>> On Thu, Oct 15, 2009 at 3:47 PM, Aaron Brown <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927311&i=1" target="_top" rel="nofollow">aaronb@...</a>> wrote:
<br>>> Curtis Garman wrote:
<br>>>> Are your tomcat instances on the same server or different servers?
<br>>>> Mine are on the same server...so not sure that ${catalina.base} would
<br>>>> do it...each instance of tomcat would need it's own environment
<br>>>> variable wouldn't it?...I don't want my build dependent on a list of
<br>>>> environment variables that are dependent on one machine. If you can
<br>>>> explain your setup further, I would appreciate it.
<br>>>
<br>>> In our production environment, we have three servers with six tomcat
<br>>> instances each. They are each fully self-sufficient copies (no shared
<br>>> files between them), and they all use identical log4j.properties files,
<br>>> thanks to the ${catalina.base} property.
<br>>>
<br>>> Here is the relevant snippet from our log4j.properties file, with some
<br>>> placeholder names:
<br>>>
<br>>> log4j.appender.Whatever.File=${catalina.base}/logs/SomeLogFile.log
<br>>>
<br>>> Log4j is smart enough to detect the root of the tomcat which executed
<br>>> it, and uses that for its path.
<br>>>
<br>>> - Aaron
<br>>>
<br>>> --
<br>>> Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927311&i=2" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>>> University of Kansas
<br>>> Information Services
<br>>> System Design
<br>>> Enterprise System Integration
<br>>> Developer
<br>>>
<br>>
<br>>
<br>>
<br>> --
<br>> Curtis Garman
<br>> Web Programmer
<br>> Heartland Community College
<br>>
</div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927311&i=3" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25927311&i=4" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25915823Re: uportal 3.1.1 and build filtering2009-10-15T13:50:37Z2009-10-15T13:50:37ZCurtis Garmanhmm...ok, I'll try it...that's exactly what I'm trying to accomplish
<br><br>On Thu, Oct 15, 2009 at 3:47 PM, Aaron Brown <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915823&i=0" target="_top" rel="nofollow">aaronb@...</a>> wrote:
<div class='shrinkable-quote'><br>> Curtis Garman wrote:
<br>>> Are your tomcat instances on the same server or different servers?
<br>>> Mine are on the same server...so not sure that ${catalina.base} would
<br>>> do it...each instance of tomcat would need it's own environment
<br>>> variable wouldn't it?...I don't want my build dependent on a list of
<br>>> environment variables that are dependent on one machine. If you can
<br>>> explain your setup further, I would appreciate it.
<br>>
<br>> In our production environment, we have three servers with six tomcat
<br>> instances each. They are each fully self-sufficient copies (no shared
<br>> files between them), and they all use identical log4j.properties files,
<br>> thanks to the ${catalina.base} property.
<br>>
<br>> Here is the relevant snippet from our log4j.properties file, with some
<br>> placeholder names:
<br>>
<br>> log4j.appender.Whatever.File=${catalina.base}/logs/SomeLogFile.log
<br>>
<br>> Log4j is smart enough to detect the root of the tomcat which executed
<br>> it, and uses that for its path.
<br>>
<br>> - Aaron
<br>>
<br>> --
<br>> Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915823&i=1" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>> University of Kansas
<br>> Information Services
<br>> System Design
<br>> Enterprise System Integration
<br>> Developer
<br>>
</div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915823&i=2" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915823&i=3" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25915766Re: uportal 3.1.1 and build filtering2009-10-15T13:47:05Z2009-10-15T13:47:05ZaaronbrownCurtis Garman wrote:
<br>> Are your tomcat instances on the same server or different servers?
<br>> Mine are on the same server...so not sure that ${catalina.base} would
<br>> do it...each instance of tomcat would need it's own environment
<br>> variable wouldn't it?...I don't want my build dependent on a list of
<br>> environment variables that are dependent on one machine. If you can
<br>> explain your setup further, I would appreciate it.
<br><br>In our production environment, we have three servers with six tomcat
<br>instances each. They are each fully self-sufficient copies (no shared
<br>files between them), and they all use identical log4j.properties files,
<br>thanks to the ${catalina.base} property.
<br><br>Here is the relevant snippet from our log4j.properties file, with some
<br>placeholder names:
<br><br>log4j.appender.Whatever.File=${catalina.base}/logs/SomeLogFile.log
<br><br>Log4j is smart enough to detect the root of the tomcat which executed
<br>it, and uses that for its path.
<br><br> - Aaron
<br><br>--
<br>Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915766&i=0" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>University of Kansas
<br> Information Services
<br> System Design
<br> Enterprise System Integration
<br> Developer
<br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (9K) <a href="http://old.nabble.com/attachment/25915766/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25915340Re: uportal 3.1.1 and build filtering2009-10-15T13:18:41Z2009-10-15T13:18:41ZCurtis GarmanAaron,
<br><br>Are your tomcat instances on the same server or different servers?
<br>Mine are on the same server...so not sure that ${catalina.base} would
<br>do it...each instance of tomcat would need it's own environment
<br>variable wouldn't it?...I don't want my build dependent on a list of
<br>environment variables that are dependent on one machine. If you can
<br>explain your setup further, I would appreciate it.
<br><br>Curtis
<br><br>On Thu, Oct 15, 2009 at 1:38 PM, Aaron Brown <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915340&i=0" target="_top" rel="nofollow">aaronb@...</a>> wrote:
<div class='shrinkable-quote'><br>> Curtis Garman wrote:
<br>>> I'm setting up an environment with multiple instances of tomcat per
<br>>> server and was wondering if someone can give me a tip on setting up my
<br>>> build to take my server.home defined in my build.properties and use
<br>>> this as the base path for my tomcat log4j configuration files via
<br>>> swapping it in in place of a variable or something so that literally
<br>>> the only thing I have to do to deploy the same configuration to each
<br>>> jvm is change the server.home value.
<br>>
<br>> What exactly do you need to customize in log4j configs for each tomcat?
<br>> We use multiple tomcats per server and use log4j's built-in
<br>> ${catalina.base} property to automagically reference each individual
<br>> tomcat's root. The same log4j config file is distributed to every
<br>> tomcat, and they all use their own "logs" directories.
<br>>
<br>> - Aaron
<br>>
<br>> --
<br>> Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915340&i=1" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>> University of Kansas
<br>> Information Services
<br>> System Design
<br>> Enterprise System Integration
<br>> Developer
<br>>
</div><br><br><br>--
<br>Curtis Garman
<br>Web Programmer
<br>Heartland Community College
<br><br>---
<br>You are currently subscribed to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915340&i=2" target="_top" rel="nofollow">uportal-user@...</a> as: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915340&i=3" target="_top" rel="nofollow">lists@...</a>
<br>To unsubscribe, change settings or access archives, see <a href="http://www.ja-sig.org/wiki/display/JSG/uportal-user" target="_top" rel="nofollow">http://www.ja-sig.org/wiki/display/JSG/uportal-user</a><br><br><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>tag:old.nabble.com,2006:post-25915236Re: uportal 3.1.1 and build filtering2009-10-15T11:38:45Z2009-10-15T11:38:45ZaaronbrownCurtis Garman wrote:
<br>> I'm setting up an environment with multiple instances of tomcat per
<br>> server and was wondering if someone can give me a tip on setting up my
<br>> build to take my server.home defined in my build.properties and use
<br>> this as the base path for my tomcat log4j configuration files via
<br>> swapping it in in place of a variable or something so that literally
<br>> the only thing I have to do to deploy the same configuration to each
<br>> jvm is change the server.home value.
<br><br>What exactly do you need to customize in log4j configs for each tomcat?
<br> We use multiple tomcats per server and use log4j's built-in
<br>${catalina.base} property to automagically reference each individual
<br>tomcat's root. The same log4j config file is distributed to every
<br>tomcat, and they all use their own "logs" directories.
<br><br> - Aaron
<br><br>--
<br>Aaron Brown (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25915236&i=0" target="_top" rel="nofollow">aaronb@...</a> | 785-864-0462)
<br>University of Kansas
<br> Information Services
<br> System Design
<br> Enterprise System Integration
<br> Developer
<br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>smime.p7s</strong> (9K) <a href="http://old.nabble.com/attachment/25915236/0/smime.p7s" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/uPortal---User-f22547.html" embed="fixTarget[22547]" target="_top" >uPortal - User</a></p>