[uportal-dev] uPortal 4.1 RC1 soon
Greetings uPortal Developers, I am happy to announce that we are looking to finish up uPortal 4.1 RC1 within the next 2 weeks. Please have all finalized pull requests posted as soon as logically possible. We will most likely cut the release on May 5th or 6th. If you have any questions or concerns please let us know. Thanks, Tim Levett levett*AT*wisc.edu smime.p7s Description: S/MIME Cryptographic Signature
[uportal-dev] Configuration of WebProxyPortlet with Shibboleth
Hello,
We develop an uPortal solution for our university. We shibbolized uPortal and
now we try to call a .php from Moodle thanks to a WebProxyPortlet. But we have
a problem with SSL
java.util.concurrent.ExecutionException:
org.jasig.portal.portlet.PortletDispatchException: The portlet window
'PortletWindow [portletWindowId=86_ctf3_61, delegationParentId=null,
portletMode=view, windowState=maximized, expirationCache=null,
renderParameters={}, publicRenderParameters={}, portletEntity=PortletEntity
[portletEntityId=86_ctf3_61, layoutNodeId=ctf3, userId=61,
portletDefinition=PortletDefinition [portletDefinitionId=86,
fname=coursesMoodle, portletDescriptorKey=PortletDescriptorKey
[frameworkPortlet=false, webAppName=/WebProxyPortlet,
portletName=WebProxyPortlet], portletType=PortletTypeImpl [internalId=7,
name=Web Proxy Portlet, descr=Web Proxy Portlet,
cpdUri=/org/jasig/portal/portlets/webproxy/WebProxyPortlet.cpd.xml' threw
an exception while executing renderMarkup.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:202)
at
org.jasig.portal.portlet.rendering.worker.PortletExecutionWorker.get(PortletExecutionWorker.java:273)
at
org.jasig.portal.portlet.rendering.worker.PortletRenderExecutionWorker.getOutput(PortletRenderExecutionWorker.java:74)
at
org.jasig.portal.portlet.rendering.PortletExecutionManager.getPortletOutput(PortletExecutionManager.java:677)
at
org.jasig.portal.rendering.PortletRenderingIncorporationComponent$PortletIncorporatingEventReader.filterEvent(PortletRenderingIncorporationComponent.java:106)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.internalNext(FilteringCharacterEventReader.java:76)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.peek(FilteringCharacterEventReader.java:61)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.hasNext(FilteringCharacterEventReader.java:43)
at
org.jasig.portal.character.stream.CharacterEventReaderDelegate.hasNext(CharacterEventReaderDelegate.java:48)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.hasNext(FilteringCharacterEventReader.java:43)
at
org.jasig.portal.rendering.DynamicRenderingPipeline.renderState(DynamicRenderingPipeline.java:94)
at
org.jasig.portal.rendering.PortalController.renderRequest(PortalController.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:424)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.jasig.portal.utils.web.CreatePortletCookieFilter.doFilterInternal(CreatePortletCookieFilter.java:60)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.jasig.portal.url.UrlCanonicalizingFilter.doFilterInternal(UrlCanonicalizingFilter.java:155)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at
[uportal-dev] Using CDN vs. Resource Server
I'd like to discuss the merits of using a CDN for common resources (jQuery, bootstrap, fontawesome, etc.) instead of copying them to the resource server. CDN - Users benefit from caching with non-uPortal apps. Helpful in particular for slow-bandwidth connections or devices with greater cache limitations. - We don't have to manage releases of Resource Server for common resources, nor modify pom.xml files to make sure the resource server overlay process copies the files. Resource Server -- - Makes it easier to know what versions of resources are in use so we consolidate on a few versions instead of a plethora of versions I generally favor the CDN approach; why duplicate what is freely and readily available to us with some extra advantages (potential pre-caching of content by other web sites). Community thoughts? -- James Wennmacher - Unicon 480.558.2420 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Jasig/uPortal/master initdb broken
uPortal developers, Jasig/master seems to be broken at this moment in that `ant clean initportal` will fail on entity import. I think this changeset will fix it https://github.com/Jasig/uPortal/pull/311 by reverting recently introduced portlet-types-as-permission-targets which seems to have introduced an unfulfilled dependency in the entity import process. More discussion of this in today's IRC. http://echelog.com/logs/browse/jasig-uportal/1398722400 Anyway, this is the heads up lest you pull down latest Jasig/master and then struggle. (But @Tim Raymond, you're not continually pulling down master anymore, are you? :) ) Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Using CDN vs. Resource Server
I too favor preferring CDN-sourcing resources when feasible and relying on ResourceServer-sourcing resources only when a viable CDN is unavailable. Makes it easier to know what versions of resources are in use so we consolidate on a few versions instead of a plethora of versions To the extent that this is a real advantage of the Resource Server approach, the same advantage can be accomplished by adding a layer of abstraction to the CDN invocation, as in externalizing the URL to a message bundle message or property or so. On 4/29/14, 2:35 PM, James Wennmacher wrote: I'd like to discuss the merits of using a CDN for common resources (jQuery, bootstrap, fontawesome, etc.) instead of copying them to the resource server. CDN - Users benefit from caching with non-uPortal apps. Helpful in particular for slow-bandwidth connections or devices with greater cache limitations. - We don't have to manage releases of Resource Server for common resources, nor modify pom.xml files to make sure the resource server overlay process copies the files. Resource Server -- - Makes it easier to know what versions of resources are in use so we consolidate on a few versions instead of a plethora of versions I generally favor the CDN approach; why duplicate what is freely and readily available to us with some extra advantages (potential pre-caching of content by other web sites). Community thoughts? -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Configuration of WebProxyPortlet with Shibboleth
Unsure. Have you verified the spPrivateKey and spCertificate from
ShibbolethEnabledHttpManagerImpl passed into
setSSLClientPrivateKeyAndCert(String pkFile, String certFile) are valid
file paths and have the correct key relationship? It strikes me as a
configuration issue with the WebProxy portlet.
James Wennmacher - Unicon
480.558.2420
On 04/29/2014 12:08 PM, Bastien Corbaye wrote:
Hello,
We develop an uPortal solution for our university. We shibbolized
uPortal and now we try to call a .php from Moodle thanks to a
WebProxyPortlet. But we have a problem with SSL
java.util.concurrent.ExecutionException:
org.jasig.portal.portlet.PortletDispatchException: The portlet window
'PortletWindow [portletWindowId=86_ctf3_61, delegationParentId=null,
portletMode=view, windowState=maximized, expirationCache=null,
renderParameters={}, publicRenderParameters={}, portletEntity=PortletEntity
[portletEntityId=86_ctf3_61, layoutNodeId=ctf3, userId=61,
portletDefinition=PortletDefinition [portletDefinitionId=86,
fname=coursesMoodle, portletDescriptorKey=PortletDescriptorKey
[frameworkPortlet=false, webAppName=/WebProxyPortlet,
portletName=WebProxyPortlet], portletType=PortletTypeImpl [internalId=7,
name=Web Proxy Portlet, descr=Web Proxy Portlet,
cpdUri=/org/jasig/portal/portlets/webproxy/WebProxyPortlet.cpd.xml' threw
an exception while executing renderMarkup.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:202)
at
org.jasig.portal.portlet.rendering.worker.PortletExecutionWorker.get(PortletExecutionWorker.java:273)
at
org.jasig.portal.portlet.rendering.worker.PortletRenderExecutionWorker.getOutput(PortletRenderExecutionWorker.java:74)
at
org.jasig.portal.portlet.rendering.PortletExecutionManager.getPortletOutput(PortletExecutionManager.java:677)
at
org.jasig.portal.rendering.PortletRenderingIncorporationComponent$PortletIncorporatingEventReader.filterEvent(PortletRenderingIncorporationComponent.java:106)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.internalNext(FilteringCharacterEventReader.java:76)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.peek(FilteringCharacterEventReader.java:61)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.hasNext(FilteringCharacterEventReader.java:43)
at
org.jasig.portal.character.stream.CharacterEventReaderDelegate.hasNext(CharacterEventReaderDelegate.java:48)
at
org.jasig.portal.character.stream.FilteringCharacterEventReader.hasNext(FilteringCharacterEventReader.java:43)
at
org.jasig.portal.rendering.DynamicRenderingPipeline.renderState(DynamicRenderingPipeline.java:94)
at
org.jasig.portal.rendering.PortalController.renderRequest(PortalController.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:424)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.jasig.portal.utils.web.CreatePortletCookieFilter.doFilterInternal(CreatePortletCookieFilter.java:60)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
Re: [uportal-dev] Jasig/uPortal/master initdb broken
Jasig/master now `ant clean initportal`'s fine again. :) On 4/29/14, 2:58 PM, Andrew Petro wrote: uPortal developers, Jasig/master seems to be broken at this moment in that `ant clean initportal` will fail on entity import. I think this changeset will fix it https://github.com/Jasig/uPortal/pull/311 by reverting recently introduced portlet-types-as-permission-targets which seems to have introduced an unfulfilled dependency in the entity import process. More discussion of this in today's IRC. http://echelog.com/logs/browse/jasig-uportal/1398722400 Anyway, this is the heads up lest you pull down latest Jasig/master and then struggle. (But @Tim Raymond, you're not continually pulling down master anymore, are you? :) ) Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Bootstrap-enabled portlets and new portlet preference
FYI. I wrote up https://issues.jasig.org/browse/UP-4077 proposing adding a new portlet preference ' usePortalBootstrap' that similar to the 'usePortalJSLibs' portlet preference is used by Bootstrap-enabled portlets to determine whether to include Bootstrap Javascript and a name-spaced Bootstrap CSS in the portlet, or rely on the portal to have already imported both Bootstrap and Bootstrap CSS. I'm also adding into 4.1.0 Universality including the Bootstrap Javascript and name-spaced Bootstrap CSS. The motivation for this is that you cannot have 2 imports of Bootstrap Javascript on a page since it is not name-spaced and does not play well with itself, whether included on the portal and in the portlet, or by two portlets on the page. At minimum it causes the Options drop-down to not work for any portlet on the page. I propose best practice is the default of this portlet preference be set to true so including the portlet into a uPortal 4.1 system (Universality or Respondr) will just work. As a bonus it is slightly more efficient. If a bootstrap-enabled portlet is included into an earlier uPortal the portlet itself may have issues until you set the portlet preference 'usePortalBootstrap' to true in the portlet publishing process, or modify the portal to include Bootstrap and name-spaced Bootstrap CSS. Best practice is for portlets to be designed to display well in both Universality and Respondr, or at least well in Respondr and adequately in Universality, though this may not always be the case and the portlet may require Bootstrap Javascript to function properly. As a related note (and I'm told documentation will be forthcoming), the name-spaced Bootstrap CSS that will be included in 4.1.0 Universality (and Bootstrap-enabled portlets) requires the portlet have a container element with a class 'bootstrap-styles' to pick up the bootstrap styling in Universality within the portlet. The class insures the name-spaced Bootstrap CSS will not impact other portlets on the page that are not designed for Bootstrap. Of course sites may need to add CSS overrides to match their color theme for these particular Bootstrap-enabled portlets in pre-4.1 Universality. If there are concerns with this approach, a need for more discussion, or better solutions, please let me know! -- James Wennmacher - Unicon 480.558.2420 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
