January 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Retrieving credentials from session for single-sign-on.

by dpaterson

I have a simple portlet which I use to post to another web application in a new browser window. The portal username and password are posted to the other application providing single-sign-on into the other web application. I have this working in another portal vendor but now I need to integrate into JBOSS Portal. Are there API hooks in JBOSS Portal 2.6 where this information can be retrieved? I have an interface CredentialProvider which has three methods: public String getUsername() throws Exception; | public String getPassword() throws Exception; | public void createContext(RenderRequest request, RenderResponse response, PortletContext pContext)throws Exception; What I need to do is implement a JBOSS Portal specific implementation of this interface which my portlet will then instantiate via reflection. Could anyone point me in the right direction? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119836#4119836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119836

18 years, 2 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test

by ryan.campbell＠jboss.com

Ok. sounds good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119754#4119754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119754

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Something up with the in vm transport

by jmesnil

"timfox" wrote : "jmesnil" wrote : | | | | Agreed. No need for a timeout - just execute it on the same thread. | | Done. I've checked it in the trunk in r3562. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119730#4119730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119730

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Something up with the in vm transport

by timfox

"jmesnil" wrote : | | That is not the case: the execution on the server-side is not done from the same thread. It uses a Executors.newSingleThreadExecutor() to run the code on the server-side. | it should all run on the same thread - we don't want to introduce the overhead of unnecessary context switches. anonymous wrote : | To be frank, the more I think about it and the more I think I should get rid of the Executors.newSingleThreadExecutor() and not provide any timeout feature for the invm optimization. | Agreed. No need for a timeout - just execute it on the same thread. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119710#4119710 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119710

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Something up with the in vm transport

by jmesnil

"timfox" wrote : When I run in vm tests on TRUNK I notice a typical stack trace to a server method looks something like this: | | | | at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397) | | at org.jboss.jms.server.endpoint.ServerSessionEndpoint$SessionAdvisedPacketHandler.handle(ServerSessionEndpoint.java:1803) | | at org.jboss.messaging.core.remoting.PacketDispatcher.dispatch(PacketDispatcher.java:93) | | at org.jboss.messaging.core.remoting.impl.invm.INVMSession$PacketDispatcherCallable.call(INVMSession.java:118) | | at org.jboss.messaging.core.remoting.impl.invm.INVMSession$PacketDispatcherCallable.call(INVMSession.java:103) | | at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) | | at java.util.concurrent.FutureTask.run(FutureTask.java:123) | | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | | at java.lang.Thread.run(Thread.java:595) | | | | So the INVM transport is being used, but I would expect to see the execution done on the same thread all the way from the client. | That is not the case: the execution on the server-side is not done from the same thread. It uses a Executors.newSingleThreadExecutor() to run the code on the server-side. I did that to provide the same behavior for the in vm optimization than for the remoting code. There is a given timeout for the server to reply to the client. If the server did not reply on time, an exception is raised. The use of a Executors.newSingleThreadExecutor() is needed to apply a timeout on the Callable object. To be frank, the more I think about it and the more I think I should get rid of the Executors.newSingleThreadExecutor() and not provide any timeout feature for the invm optimization. Do you see a case where it'd make sense to keep this feature to avoid the client being stuck if the server is stuck (which should never happen anyway)? wdyt? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119707#4119707 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119707

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Should HibernateSaveOperation be saveOrUpdate?

by brittm

I've heard down the line that Gavin and company somewhat regret introducing a difference between 'save' and 'saveOrUpdate', and that given an opportunity to do it again they would not bother with only 'save'ing. In fact, its my understanding that JPA itself only supports a 'saveOrUpdate' concept. But I'm simply repeating what I've heard rather than what I know myself. Perhaps someone could ping Gavin and he could comment on any nuances between the two that might affect us. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119681#4119681 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119681

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by bstansberry＠jboss.com

No problem not being in CR3. For now, the biggest benefit to me from this (saving memory on the values) I can implement myself at the AS level. If we rush it into JBC before we've thought it all through and there's a problem, then I'm kind of hosed for AS 5 beta4 and Hibernate 3.3. So caution is good. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119680#4119680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119680

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Extendable Transports List

by mark.little＠jboss.com

Transports at what level? If it's the gateways, then you can always add more capabilities to JCA: it's just vanilla JCA inflow that we use after all. If you create JIRAs and attach the code, then the development team will look at it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119677#4119677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119677

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Extendable Transports List

by acure

Hi First) - i cant wait :) - than i have to do it. Do you have some advices ? Did you think about this - how to implement more extendable transports? Second) - jboss esb licence id LGPL - than if i will change source i have to share this changes. How to do it ? I have to solve others task from jboss esb jira too. Thanks - Antony View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119655#4119655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119655

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by manik.surtani＠jboss.com

Hmm, not including the MarshalledValues patch in CR3. It needs more thought. My current implementation calculates (and caches) hashcodes off the deserialized instance, so when this is replicated, if the key in an attrib map is a MarshalledValue, then hashcode() is called when putting this key in a node and this forces deserialization. Beats the purpose of lazy deserialization as well as re-introduces the need for region-based marshalling since this deserialization is done by the JGroups thread that deals with the incoming replication rather than a user thread on the remote cache. Note that this is only with using MarshalledValues to wrap keys. Works fine for values. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119653#4119653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119653

18 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2008