October 2007 - jboss-dev-forums - Jboss List Archives

[Design the WSRP implementation] - Unable to Consume Remote Portlet

by vinuneelu

Hi, I am Vinu. I am a new user in JBoss. I was trying its WSRP Services. But when I tried to consume Remote portlet from Websphere Portal Sever, it is giving the error as follows "javax.xml.rpc.soap.SOAPFaultException: EJPWC1104E: The Producer environment has timed out. The Consumer needs to invoke initCookie() again". How can I configure my JBoss consumer so that it can invoke initCookie() method of Websphere Portal Producer? My OS is WindowsXP. Remote OS is also the same. Looking forward for a solution. Thank You Vinu View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098351#4098351 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098351

17 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by julien＠jboss.com

I don't understand why you want so hard to mutualize a set of POJOs + an hibernate configuration. It's trivial software to write. In portal world, a lot of things are done rather around LDAP and database is a good default option (for out of the box). "tom.baeyens(a)jboss.com" wrote : "sohil.shah(a)jboss.com" wrote : tom- | | | | what you are talking about at this point is the Identity Management Framework. As far as the ACL component is concerned (topic of discussion in this thread), it should be Identity Management Framework agnostic with ability to plugin different Identity Management implementations. | | | | Thanks | | if i understand you correctly, that is exactly the opposite of what I'm trying to promote. | | i think we can build 1 implementation so that all the projects can leverage it as an implementation for project specific identity interfaces. | | that way, in the platforms, it would be possible to configure all the components to use 1 and the same component implementation. | | at a minimum, a database schema has to be defined so that we all can work with a single DB repository. And IMO, a set of POJO's+hibernate mappings should accompany the common identity database schema. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098350#4098350 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098350

17 years, 2 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by tom.baeyens＠jboss.com

"sohil.shah(a)jboss.com" wrote : tom- | | what you are talking about at this point is the Identity Management Framework. As far as the ACL component is concerned (topic of discussion in this thread), it should be Identity Management Framework agnostic with ability to plugin different Identity Management implementations. | | Thanks if i understand you correctly, that is exactly the opposite of what I'm trying to promote. i think we can build 1 implementation so that all the projects can leverage it as an implementation for project specific identity interfaces. that way, in the platforms, it would be possible to configure all the components to use 1 and the same component implementation. at a minimum, a database schema has to be defined so that we all can work with a single DB repository. And IMO, a set of POJO's+hibernate mappings should accompany the common identity database schema. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098344#4098344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098344

17 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: run jbosscache1.4.1sp5 in oc4j 10.1.3

by manik.surtani＠jboss.com

please post to the user forum; this has absolutely nothing to do with JBC design. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098296#4098296 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098296

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: duplicate jndi-name in jboss_5_0.xsd

by wolfc

Bugrit, in the end it still gets to convoluted, so I'm not going to override your fix. I've committed the mode construct though, it might be useful in the future. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098243#4098243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098243

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: duplicate jndi-name in jboss_5_0.xsd

by wolfc

I'm working out an alternative assertJndiName where a mode argument can be passed. This way we can still make sure that a jndi-name overrides a mapped-name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098232#4098232 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098232

17 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-4890:EJBAccessException: Caller unauthorized

by thomas.diesler＠jboss.com

Please note, that you will need to modify [url] https://svn.jboss.org/repos/jbossws/stack/native/branches/jbossws-native-... [/url] to enable some tests View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098226#4098226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098226

17 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-4890:EJBAccessException: Caller unauthorized

by thomas.diesler＠jboss.com

Richard, I think Anil knows all that. Before he became security lead he was in our team just like you are ;-) Anil, sorry about the the broken test build, please try again. Yes, that branch is the one | jbossws/stack/native/jbossws-native-2.0.2 | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098224#4098224 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098224

17 years, 2 months

1
0
0 / 0

[QA of JBoss Portal] - Re: Portlet Container test framework update

by julien＠jboss.com

The @JoinPoint annotation would actually contains 4 members: /** | * @author <a href="mailto:julien@jboss.org">Julien Viet</a> | * @version $Revision: 1.1 $ | */ | public @interface JoinPoint | { | | /** | * The request count. | * | * @return the request count | */ | int count() default 0; | | /** | * The portlet id. | * | * @return the portlet id | */ | String portletId(); | | /** | * The node id. | * | * @return the node id | */ | NodeId node() default NodeId.DEFAULT; | | /** | * The phase id. | * | * @return the phase id | */ | PhaseId phase() default PhaseId.RENDER; | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098219#4098219 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098219

17 years, 2 months

1
0
0 / 0

[QA of JBoss Portal] - Portlet Container test framework update

by julien＠jboss.com

It is about migrating the portlet container test framework in order to take advantage of Java 5 and make the different tests easier to write (as we plan to add lot of new tests for the JSR 286 implementation). It will only leverage for now annotations which are helpful to describe the sequence of the different methods composing a test case. Now we have something like package org.jboss.portal.test.portlet.jsr168.tck.portletinterface; | | public class PortletInterfaceSequenceBuilder extends PortletTestSuite | { | /** | * @portlet.specification assert="SPEC:4 - After the portlet object is instantiated, the portlet container must | * initialize the portlet before invoking it to handle requests" | */ | public void createInitializeBeforeHandleCase(PortletTestDriver registry) | { | PortletTest seq = new PortletTest(); | registry.addSequence("InitializeBeforeHandle", seq); | seq.addAction(0, InitializeBeforeHandlePortlet.RENDER_JOINPOINT, new PortletRenderTestAction() | { | protected DriverResponse run(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context) | { | assertTrue(InitializeBeforeHandlePortlet.init); | return new EndTestResponse(); | } | }); | } | } Each test case should be migrated to a single class which will help to isolate the test cases from each other and will be constitued of methods annotated with @JoinPoint annotation describing when and where this methods should be executed during a portal request. There will be also the @TCK annotation that will be optional and will annotate methods that test TCK assertions present in the spec. package org.jboss.portal.test.portlet.jsr168.tck.portletinterface; | | public class InitializeBeforeHandle | { | @TCK(4) | @JoinPoint(count = 0, portletId = InitializeBeforeHandlePortlet.NAME) | public DriverResponse run(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context) | { | assertTrue(InitializeBeforeHandlePortlet.init); | return new EndTestResponse(); | } | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098218#4098218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098218

17 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007