September 2006 - jboss-dev-forums

[Design of JBoss Portal] - Re: JBOSS Portal, JSF, XHTML and AJAX !!!finally!!! :-)

by julien＠jboss.com

first you need to sign an agreement that you can find here : http://labs.jboss.com/portal/con?noproject=true then create a jira task with a fix version for 2.6 and assign it to me upon creation. for the component chose "core". also a couple of other questions : 1/ is the feature tested ? 2/ do you have written documentation for that feature ? thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970067#3970067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970067

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - MessageService and JMS

by mteira

Hello. Sorry for crossposting, but I sent this yesterday to the jBPM-users forum, and after knowing the existence of this other forum, I think it matches better here: Hello. I'm interested into implementing a clustered capable workflow system, and started reading the user tutorial of jBPM and also some of the source code to see how the thing works. I need to support concurrent execution for the actions associated with parallel tokens into process instances (and also for tokens from different process instances). Having into account that I want to run inside a J2EE server, I'm observing the following facts: 1.-CommandExecutorThread is not the way to go for me, because it consumes the messages in a single thread, so, a Task with two simultaneous Tokens is not going to execute the two branches at the same time. I think that with this approach, different tasks are not running actions in parallel neither. The running thread is another problem to deploy it inside a J2EE application server. 2.-Using DbMessageService as MessageService implementation needs the messages to be consumed from a central point. This seems also a not J2EE friendly approach. So, I think that the most natural way to implement it is to use a JMS message service, and so, implement MDBs to consume those messages and run the required actions, in a similar way CommandExecutorThread is working but only consuming the J2EE provided message. This will probably be a good starting point to provide clustering capabilities, since the JMS component can be clustered, and we could consume the messages from different J2EE servers. Do you think this is a right approach? Any comments about this? I've also seen that there's a org.jbpm.msg.jms package that seems to be an effort to implement just this, a MessageService JMS implementation. But it seems it's under construction (as I can see some TODO comments in the code , and some methods remain unimplemented). I'm I right. Is this an effort to do what I'm trying to do? Is somebody working into this? Where could I find more information about it? Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970062#3970062 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970062

19 years, 7 months

1
0
0 / 0

[Design of JBoss IIOP on JBoss] - Re: IIOP CSIv2 Kerberos authentication

by kc7bfi

I resorted to using the SAS interceptors written for JacORB. To do this, I had to write a small modification to the JBoss launcher to run under a kerberos login. For the modification see the attached file on JIRA issue JBAS-3538. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970056#3970056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970056

19 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBOSS Portal, JSF, XHTML and AJAX !!!finally!!! :-)

by dajevtic

Yes, of course! I figured that. So, can I supply you with the source code so that you can check and see if it's worth putting into version control for 2.6? If so, should I just mail you my code? Kind regards, Danijel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970050#3970050 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970050

19 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBOSS Portal, JSF, XHTML and AJAX !!!finally!!! :-)

by julien＠jboss.com

No you need to have two explicit stacks. The jboss-service.xml contains declarations and is not a scripting language. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970045#3970045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970045

19 years, 7 months

1
0
0 / 0

[Design of JBoss Web Services] - JBAS-3630 - JMSTransportSupport Portability

by darran.lofthouse＠jboss.com

http://jira.jboss.com/jira/browse/JBAS-3630 The current implementation of JMSTransportSupport is not portable across different JMS providers, the problem is that the format of the name returned from the destination is dependent on the JMS provider. We however assume that the name will always match the name it was bound to JNDI with. Some possible fixes: - 1 - Require the client to set a property on the incomming message that can be used to identify the web service. 2 - As part of deploying the WS lookup the detination the MDB is configured to use and check the name instead of using the JNDI name. 3 - Lookup a value bound to the ENC that identifies the web service. i - The user deploying the web service could define this in the ejb-jar.xml ii - The JBossWS deployer could bind the value to the ENC of the MDB as part of the deployment process. For backwards compatibility if the value for the chosen fix is not available we can fall back to using the current logic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970027#3970027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970027

19 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Specifying Default Client Binding

by romanchr

Hi guys, I came accross the same problem. What I saw is that it doesn't matter if your remote object are using the @service annotation or just @remote. As long as the configuration is set to anything else then "ports-default" (example ports-01, see earlier post) then JBoss 4.0.4GA is not able to execute any kind of function on any remote object (in my case stateless session bean). On the client side you end up with the earlier in this thread posted exception. If you set the configuration to ports-default, everything works fine. We would be realy glad if this bug is resolved as fast as possible. A patch release before RC9 woudl be great. Regards, Christoph View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969990#3969990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969990

19 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBOSS Portal, JSF, XHTML and AJAX !!!finally!!! :-)

by dajevtic

Dear Julien, I have managed to get my code running as you suggested. I changed the jboss-service.xml as needed, configured the portal servlet to listen under /ajax/*, created an AjaxController and an AjaxPortletRenderer. Here is one small snippet of the jboss-service.xml that I have a question for: | ... | <mbean | code="org.jboss.portal.server.impl.invocation.JBossInterceptorStackFactory" | name="portal:service=InterceptorStackFactory,type=Ajax" | xmbean-dd="" | xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean"> | <xmbean/> | <depends-list optional-attribute-name="InterceptorNames"> | <depends-list-element>portal:service=Interceptor,type=Server,name=Transaction</depends-list-element> | <depends-list-element>portal:service=Interceptor,type=Server,name=SessionInvalidator</depends-list-element> | <depends-list-element>portal:service=Interceptor,type=Server,name=User</depends-list-element> | <depends-list-element>portal:service=Interceptor,type=Server,name=Locale</depends-list-element> | <depends-list-element>portal:service=Interceptor,type=Server,name=ContentType</depends-list-element> | <depends-list-element>portal:service=Interceptor,type=Server,name=AjaxController</depends-list-element> | </depends-list> | </mbean> | ... | My question now is: Since I mainly just use another Controller and another Renderer (the rest is the same as in the regular stack), is it possible to define a conditional "depends-list-element" or do I always have to define my own complete action, command and render stack? I am thinking of something like | if (ajax) { | <depends-list-element>portal:service=Interceptor,type=Server,name=AjaxController</depends-list-element> | </depends-list> | } else { | <depends-list-element>portal:service=Interceptor,type=Server,name=Controller</depends-list-element> | </depends-list> | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969987#3969987 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969987

19 years, 7 months

1
0
0 / 0

[Design of JBoss IIOP on JBoss] - Re: IIOP CSIv2 Kerberos authentication

by info＠connext.co.za

Good Day, Could you please indicate how these inteceptors could be designed to support this functionality? I need this to work in 4.0.4 GA and I am willing to write the inteceptors, I just need someone to give pointers on how this could be done. Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969964#3969964 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969964

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: implementing undo

by prassib

Is there a way to prevent a ProcessInstance from not moving on to the next state despite it being signalled? For example, I call the signal method on a ProcessInstance but can I write code inside any of the ActionHandlers to prevent the ProcessInstance from moving to the next state & continue to stay at the same state it was at. In another words, I am trying to override the signal. Is it possible? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969908#3969908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969908

19 years, 7 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 September 2006