I haven't looked at the details of the Liferay chat portlet, but if it's based
on the portlet specifications JSR168 or JSR286, it should work.
That said, I doubt it's completely standard; it most likely relies on Liferay
proprietary APIs or external data sources, etc.
View the original post :
I'm not sure if JBoss SSO supports IIS directly, but if you're using NTLM
authentication w/IIS, the Portal can be configured for NTLM security as well.
Hope this helps.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4266071#4266071
Reply to the post :
I'd check what version of portal the portlet you're trying to deploy was
developed and tested on. I'm assuming it doesn't work with Portal 2.7.X.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4265635#4265635
Reply to the post :
No, both the POST and GET http methods are supported. Have you had problems
with POST?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4265636#4265636
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4265636
You should be able to use the new JSR286 method: serveResource to stream the
PDF data. Pre-JSR286, you'd have to use a side servlet for this functionality.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4264725#4264725
Reply to the post :
Does your javascript function send an HTTP get (ie: window.location) or an HTTP
post (ie: dynamically set the action= in your form)?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4258947#4258947
Reply to the post :
This sounds more like a business component than a Portal component (ie: not a
portlet) that the EJB3 timer service would be well-fit for:
http://java-x.blogspot.com/2007/01/ejb-3-timer-service.html
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4258703#4258703
The message you're getting may be resolved by configuring your
jboss-portlet.xml with a transaction attribute, otherwise your two portlets
won't be able to generate URLs to eachother:
portlet-nameYourPortlet/portlet-name
trans-attributeRequired/trans-attribute
Agreed; I decided against using Spring Security in the Portal environment. Most
of what Spring Security offers at least from an authentication/basic
authorization (ie: not ACLs) perspective, JBoss Portal offers out of the box
with appropriately used LoginModules, etc.
View the original post :
We've enabled Tomcat's SSO valve which is effectively very similar to what
you're trying to do:
http://www.andypemberton.com/jboss/securing-ajax-servlets-in-jboss-portal/
Though, can you further describe your apps and the four different containers
they run in? Are the consumed with WSRP? How
To your first question, there is a sample portlet WAR deployed that contains
*-object.xml files that replaces those pages when the server starts. Simply
remove the *-object.xml files or those portlets entirely and they should be
gone.
View the original post :
Public Render URLs are a special type of Render URL as defined by the JSR286
(Portlet 2) specification. They are retained through multiple renders (and
re-renders) of a given portlet and other portlets setup to use the shared
parameter.
This is standard behavior for render parameters in the
I don't have experience specifically migrating websphere apps to jboss, but I
do have extensive experience with both websphere and jboss portal.
The first place to start with this kind of task is to ensure you're not using
any vendor proprietary APIs (IBM in this case). You'll want to use the
Yes, this is no problem. You can package all of your portlets inside a single
.war file.
You'll just define each portlet in your (single) portlet.xml file:
?xml version=1.0 encoding=UTF-8?
portlet-app ...
display-namePortletOne/display-name
I think JSR168/286 define that the WindowState change won't be propagated until
the subsequent RenderRequest (after your ActionRequest).
From JSR286:
anonymous wrote : The setWindowState method allows a portlet to change its
current window state. The new window state will be effective in the
Agreed with Chris here. The default value for the javax.portlet.escapeXml
runtime option should be true. See:
http://www.andypemberton.com/portal/jsr286-tag-library-and-xml-escaping/
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239845#4239845
Reply to the
http://static.springframework.org/spring/docs/2.5.x/reference/portlet.html
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4238275#4238275
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4238275
Not sure if the original author achieved success, but one way to handle this
would be to access the servlet's session from the portlet through the
PortletSession scope.
JSR168 and 286 allow sharing of a web-application's session with a portlet if
they're pacakged together by accessing the
Sourav: correct - to my understanding the PortalNodeEvent mechanism can only
swap events in and out of the event chain, and so is fairly limited in terms
of IPC.
What we've done to handle this limitation is, in a small set of cases, use the
Navigation API to store some data in the global
In short, a call to ActionURL will return an entire portal page (with theme,
renderers, and all), whereas a ResourceURL serves your markup raw but still
provides access to the portal context.
Pre-JSR286, this was accomplished with backing servlets, which did not have
implicit access to the
Packaging a portlet is very similar to a standard JavaEE web app, except it
includes a portlet.xml (in addition to the standard web.xml).
Typically portlets are packaged as WAR files, the structure of which is defined
by JSR168 / 286: http://jcp.org/en/jsr/detail?id=286
I recommend giving the
Let me try to restate your problem to see if I'm understanding: you can render
your actual portlet, but on clicking the hyperlink in the JSP page, the
hyperlink is not working?
Unless the forum stripped your HTML there, I'm assuming it's because you don't
have a protocol (http://) before your
You should be able to access the PortalRuntimeContext using the Navigation
class's static accessor:
PortalRuntimeContext prc = Navigation.getPortalRuntimeContext();
See:
If you're using a custom theme (or maybe even if you're not), I'd recommend
adding jQuery to your theme directory. That way, you can maintain it there and
reference it from all of your other portlets as necessary.
View the original post :
If the JBoss Portlet Bridge is still a bit too cutting edge for your shop,
we've used Spring Portlet MVC successfully in several large scale JBoss Portlet
projects. Though, it does come with the typical spring headaches (verbose xml,
type safety issues).
The answer here depends on a number of
This is a standard part of the portlet lifecycle (portlet 2-phase,
action/render lifecycle).
Off the cuff, I can think of a few ways to help with your scenario:
don't load data from the database in your render (doView) calls
check out the out of the box ajax/partial-refresh features to see if
Not sure what version of Portal you're on, but you should check out the
UserEvent API:
http://docs.jboss.com/jbportal/v2.6.5/javadoc/org/jboss/portal/api/user/event/UserEvent.html
There's an example (for 2.6.X) that describes building a user counter using the
UserAuthenticatedEvent:
If your portlets are packaged in the same WAR, the sample code you provided
will actually work.
Otherwise, you'll have to employ interportlet-communication or use JBoss's
proprietary APIs to achieve session sharing.
View the original post :
What version of JBoss Portal are you using? In Portal 2.6, your
PageCustomizerInterceptor stores the userProfile as a request attribute:
Controller controller = controllerCtx.getController();
| Map userProfile = controllerCtx.getUserProfile();
|
Should be located at:
PS_HOME/server/default/deploy/jboss-portal.sar/lib/jboss-portlet-api-lib.jar
Also, you should check out the JBoss Tattletale project, which can help you
locate classes in jars, etc:
http://blog.hibernate.org/Bloggers/IntroducingJBossTattletale10BETA1
View the original
No worry, fuchs - just trying to be helpful. =)
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4218854#4218854
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4218854
___
jboss-user
One technique we've used in the past to do what you're describing is somewhat
similar to fuchs recommendation.
We extended our custom decoration renderers to look for a window property to
disable certain mode/state links.
Example property:
property
|
Sorry; hard to diagnose a fairly generic problem like that.
I'd recommend using a JavaScript debugging tool (like FireBug for FireFox) to
look at the details of the error your receiving.
Are you using a custom theme? If so, you may want to just include the jQuery
libraries in the theme
First, as an FYI: it usually doesn't help get responses to your forum requests
by explaining the urgency of your problem. If someone has time to help, they
will.
Second, the problem you're seeing is a result of setting a session attribute in
the portal-server.war web application and trying
Note that Fuchs's solution mentioned below enables session-replication for
setting up JBoss Portal in a clustered environment; it does not solve the
problem of attempting to access session attributes across web applications.
View the original post :
I don't think you'd want to set overflow, you'd want to set either visibility,
display, or use positioning to push the element off the screen:
display:none;
| visibility:hidden;
| position:absolute;left:-em;
This solution would still render the links in the markup, but use CSS to hide
Hm - not quite sure I understand your use case here, but off the cuff, one way
you could accomplish this is with security.
Example:
- If User A (or User Role A) logs in and has access to Page A, they'll get that
page
- If User B (or User Role B) logs in and has access to Page B (and not Page
See the notes on upgrading from 2.6 to 2.7 on accessing the JBoss-specific
portlet requests:
http://docs.jboss.com/jbportal/v2.7.0/referenceGuide/html/changelog.html
Relevant text:
anonymous wrote : Usage of JBossActionRequest is not available directly
anymore. From now on it is only
JBoss Portal 2.7 uses JBoss AS 4.2.3, which in turn uses Tomcat 5.5 under the
covers as the servlet engine.
Tomcat 5.5 is Servlet 2.4/JSP 2.0 compatible, so you can't use the JSP 2.1
trimDirectiveWhiteSpaces feature.
You can, however, use the trimSpaces init-param per
Well, this would depend on your installation scenario a bit.
For example, if you front your portal server with Apache web server, you can
use mod_deflate to GZip your response:
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html.
If you're hitting the portal server directly, you could
JBoss Portal takes a very literal interpretation of JSR168 when it comes to
managing user roles. So, any roles that you want to use from your JAAS security
context, you'll have to define (at least a role-name, not necessarily
role-link) in your portlet.xml:
security-role-ref
You can use the following in a tag extending SimpleTagSupport:
PortalNode currentNode = (PortalNode)
getJspContext().findAttribute(org.jboss.portal.api.PORTAL_NODE);
| currentNode.getName();
| currentNode.getDisplayName(locale);
Your PageCustomizerInterceptor stores the current PortalNode
So, unless I misunderstood your problem, it sounds to me that there's a problem
with your approach.
The HTML iframe tag takes a URL in its src attribute, much like an img tag.
Your web browser then downloads the src of the iframe just as it would an image.
In other words, with iframes,
Understood. The classic http requests you're referring to would be
PortletRequests, no? The difference being that your PortletRequests are routed
through the PortletContainer's command stack where your ajax requests are
handled by the servlet engine, so it would make sense that the servlet
As for the portlet, in order to have a portlet share in the portal's JTA
transaction, you can add the following to your jboss-portlet.xml:
portlet-app
| portlet
| portlet-nameYourPortlet/portlet-name
| transaction
|
It sounds like you may be facing some other challenges, not necessarily related
to those you describe.
If you've been developing portlets with html, head, and body tags, that's a
problem. Your layout should contain those tags, but as you point out - because
portlets are aggregated onto a
This is a fairly nebulous question and would really depend on your
requirements, but I'll toss in my two cents.
First, to your comparison - Trac is a custom app written in Python.
Second, you have to think about what a Portal platform and specifically what
JSR168 and JSR286 buy you. The
Sure; Portal themes run as (or inside) a typical Java EE WAR. There's no reason
your custom Spring-based web apps can't directly reference your Portal's CSS
files.
You shouldn't have to copy the CSS selectors, you should be able to reference
your Portal's theme CSS files directly:
link
Anyone have an idea here?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4183700#4183700
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4183700
___
jboss-user mailing list
Brian:
Thanks for the dilligence; I'm having a similar issue on JBoss Portal 2.6.5.
Basically, if I have two portlets on PageA: PortletA and PortletB, PortletA can
only access its own portlet window on the given page.
So, the following code can access any page below PageA and PortletA itself:
In JBoss Portal 2.4, the NavigationPortlet instance was added manually to each
portal page.
Has this changed for Portal 2.6? I don't see the NavigationPortlet instance in
the page layout interface. It appears as though the navigation portlet is
injected into the entire portal, but I am unable
51 matches
Mail list logo
