[EJB3] - JBoss AS 7.1 - How to create application Client that uses a deployed EJB
by Essam Raafat
Essam Raafat [https://community.jboss.org/people/e_rafaat] created the discussion
"JBoss AS 7.1 - How to create application Client that uses a deployed EJB"
To view the discussion, visit: https://community.jboss.org/message/746877#746877
--------------------------------------------------------------
Hello all,
I created a simple EJB called ProducerBean, and i want to test it using application client,
public class Main {
public static void main(String[] args) {
// TODO Auto-generated method stub
InitialContext ctx;
try {
Properties jndiProps = new Properties();
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
jndiProps.put(Context.PROVIDER_URL,"remote://localhost:4447");
jndiProps.put(Context.SECURITY_PRINCIPAL,"adminUser");
jndiProps.put(Context.SECURITY_CREDENTIALS, "93842b358571ba9fd3a537e47f36c26b");
ctx = new InitialContext(jndiProps);
Producer bean = (Producer) ctx.lookup("java:global/JMS-tut1/ProducerBean");
System.out.println(bean.add(2,3));
} catch (NamingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
/* (non-Java-doc)
* @see java.lang.Object#Object()
*/
public Main() {
super();
}
}
but when running this code, it throws the following exception
Jul 09, 2012 11:49:28 AM org.jboss.remoting3.remote.RemoteConnection handleException
ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:121)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)
at Main.main(Main.java:23)
Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.naming.remote.protocol.IoFutureHelper.get(IoFutureHelper.java:87)
at org.jboss.naming.remote.client.NamingStoreCache.getRemoteNamingStore(NamingStoreCache.java:56)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateCachedNamingStore(InitialContextFactory.java:166)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateNamingStore(InitialContextFactory.java:139)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:104)
... 5 more
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
at org.jboss.naming.remote.client.NamingStoreCache.getRemoteNamingStore(NamingStoreCache.java:55)
... 8 more
any ideas ??
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/746877#746877]
Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
[jBPM] - Human Task Module Refactoring
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task Module Refactoring"
To view the document, visit: https://community.jboss.org/docs/DOC-18789
--------------------------------------------------------------
This document aims to explain how the human task module should look after applying some refactorings which were the results of several experiments.
You can more about this experiments here: https://github.com/Salaboy/human-task-poc-proposal https://github.com/Salaboy/human-task-poc-proposal
The following sections describe how the module will look like after the refactorings
h1. APIs and Service Structure
All the Services Proposed by this refactoring are CDI managed beans. For the ones not familiar with CDI, you need to think about it as JPA for Dependency Injection frameworks. So we can say
that CDI is to Spring/Guice/Weld what JPA is to Hibernate/Top Link. CDI propose some very cool out of the box features that we definitely want to use to make our services more clear, robust, easy to maintain. Some of the things provided by CDI that I'm using in the experiments are:
* Configuration based on annotations: We can inject services instances without needing to specify the implementation, so we keep it pluggable and decoupled all the time.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see there, we can define at service level which characteristic the service implementation will need to be injected inside a service, but then we can provide several alternatives
for that implementation and configure them for different environments. The CDI container will do the rest for us, it will choose wisely the implementation that fits with all the characteristic required and it will inject the services implementation when it's need.
* Event Producers and Observers
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
and: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
As you can see a simple and out of the box (and defined by an specification) Event mechanism is provided, allowing us to keep our Event Producers completely Decoupled from our Event Observers. We can also configure the obsevers to be instantiated by teh CDI container or we can decide how many instances of our observer do we need for a particular use case.
* Decorators/Interceptors:
We can use both to improve a specific technical or business policy should be applied to the execution of our service methods.
Look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
Decorators and Interceptors can be enabled and disabled based on configurations, which give us once again a great flexibility to add or remove things based on what we want to achieve.
At the end of the day we have a set of services which can leverage the power of the CDI container. We can also hide that we are using CDI/Weld (weld is the implementation of the CDI interfaces/spec), look at: https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
We can use it internally and if the user wants to get access to the container he/she can.
The next section describe more advantages about using the CDI/Weld proposed programming model to keep our services simple and take out all the code that is not related with Human Interaction logic.
h1. Services Working Together
The following image shows how the interactions with the human task module will happen. The diagram shows the interfaces and implementations required to interact with a TaskInstance
https://community.jboss.org/servlet/JiveServlet/showImage/102-18789-2-190... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-18789-2...
The previous figure shows all the components interacting when we want to interact with a task instance that was already created.
So let's say for example that we want to start a task. From the client perspective he/she can use the TaskServiceEntryPoint to
start the task. This TaskServiceEntryPoint will delegate the calls to the different service implementations. In this case if we are
starting a task the TaskInstanceService implementation will delegate the action to the LifeCycleManager. As you can see
the LifeCycleManager, no matter the implementation is being decorated by an UserGroupDecorator which in charge of handling the
resolution of the identities associated with the operation. The LifeCycleManager is also an Event Producer, which means that is in charge
of generating events to communicate to the external world the LifeCycle changes of each task. We can then attach external listeners to
Observer these events to audit what is happening or as callback mechanisms to execute actions when a task is completed for example.
Classes and Interfaces to look at this point:
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task... https://github.com/Salaboy/human-task-poc-proposal/blob/master/human-task...
h3. Shared Persistence Context and Transactional Behavior
If you take a look at the previous links you will notice that all the Services, for example TaskInstanceServiceImpl and TaskDefServiceImpl are all using an Inject EntityManager.
And there is no code related with transactions or loading and merging detached entities (em.getTransaction(), ut.begin(), em.merge()).
The EntityManager that is being injected is being managed by Seam Persistence (ASL 2.0) ( http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/ http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html_single/) which give us a transparent
way of having all the advantages of the unified programming model of being in Managed and Transaction Persistence Context without the hassle of taking care of how to share different
instances of an EntityManager or demarcate the transactions based on what is available in our context. Seam Persistence provide us a declarative way to deal with all this topics, and take all the code
related with these tasks out of the Human Task Module. This also give us the possibility to integrate with Spring only configuring our environment and not changing our code
( http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html)
h1. Integration with the Outside World
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18789]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 5 months
[JBoss Remoting] - Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException
by Ron Sigal
Ron Sigal [https://community.jboss.org/people/ron_sigal] created the discussion
"Re: WorkerThread exception occured .... InvocationTargetException / SocketTimeoutException"
To view the discussion, visit: https://community.jboss.org/message/724880#724880
--------------------------------------------------------------
Hi Werner,
re: "For example with netstat I can see, that *2437* is a used port. I am wondering that I could recognize that this port is used by my testprogram istself"
It really wouldn't do any good. When you make a call on an EJB, it filters down to Remoting, which, if it can't find a pooled connection to reuse, will create a new socket, leading to ServerSocket.accept() returning a socket on the server.
It seems like something is preventing the client from completing the initialization of the connection, but I can't imagine what it is. You could use Wireshark to monitor what bytes, if any, get sent from the client to the server.
-Ron
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/724880#724880]
Start a new discussion in JBoss Remoting at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
[JBoss Remoting] - Re: How to use always the same port for ejb-call
by Ron Sigal
Ron Sigal [https://community.jboss.org/people/ron_sigal] created the discussion
"Re: How to use always the same port for ejb-call"
To view the discussion, visit: https://community.jboss.org/message/748589#748589
--------------------------------------------------------------
Hi Werner,
Sorry for the delay.
Once a worker thread is created, it will be reused. In particular, once it completes an invocation, it will sit in a read() waiting for the next invocation. If you do no more than one invocation at a time, the same worker thread should handle all of them.
If you do more than one invocation at a time, you could limit the number of worker threads to one. That way, if an invocation comes in while the single worker thread is busy, the server will wait until the worker thread finishes processing its invocation and then use it for the new invocation. You can limit the number of worker threads in the configuration file $JBOSS_HOME/server/$CONFIG/deploy/ejb3-connectors-jboss-beans.xml by changing the line
<parameter>socket://${jboss.bind.address}:${port}</parameter>
to
<parameter>socket://${jboss.bind.address}:${port}/?maxPoolSize=1</parameter>
-Ron
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/748589#748589]
Start a new discussion in JBoss Remoting at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
[JBoss Web Services] - Duplicate WS requests
by Milan Paul
Milan Paul [https://community.jboss.org/people/milan.paul] created the discussion
"Duplicate WS requests"
To view the discussion, visit: https://community.jboss.org/message/748575#748575
--------------------------------------------------------------
Dear Friends,
We are exposing one WS to a thirdparty from JBoss. Due to some issue our WS is not responding back some times to the request coming from third party application for more than one hour. The reason of the late response is found in our system which is a logical issue. We need to fix the issue which will take some time. However, exactly after one hour of the 1st request if the response is not sent back to the 3rd party a second request iis coming to our WS. According to the third party, they are not invoking the WS second time rather waiting for the response. Is there any configuration settings on our side which is resending the request. Please help. This is a production issue which has a huge impact on our system.
Thanks in advance.
Regards,
Milan
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/748575#748575]
Start a new discussion in JBoss Web Services at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
[Beginner's Corner] - How to prevent direct access to files?
by Francisco Palma
Francisco Palma [https://community.jboss.org/people/fpalma] created the discussion
"How to prevent direct access to files?"
To view the discussion, visit: https://community.jboss.org/message/748845#748845
--------------------------------------------------------------
Hello to all,
I'm using JSF 2, and I have all my xhtml files under "/src/main/webapp/", so I can access directly to this files writing his name on the navigator.
I want to hide the files in "/src/main/webapp/WEB-INF/views" for example.
If I modify the file faces-config.xml with this:
<from-view-id>/home.xhtml</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/WEB-INF/views/welcome.xhtml</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>nowelcome</from-outcome>
<to-view-id>/WEB-INF/views/nowelcome.xhtml</to-view-id>
</navigation-case>
It functions halfway, for example I can navigate from home.xhtml to welcome.xhtml, but I can not make actions from welcome.xhtml to itself (this works with the files under /src/main/webapp/)
How can I do to prevent direct access to the files? I'm not using web.xml.
Thank you very much,
Fran
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/748845#748845]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
