[IronJacamar Development] - Testsuite -refactoring to make test easier to run
by Stefano Maestri
Stefano Maestri [http://community.jboss.org/people/maeste] created the discussion
"Testsuite -refactoring to make test easier to run"
To view the discussion, visit: http://community.jboss.org/message/572765#572765
--------------------------------------------------------------
Hi all,
I'm working on our test suite. I'm trying to figure out not only how to achieve a better coverage, but also how to make current and future tests easier to read, write and run. Currently a lot (almost all) of our unit tests are deploying something on an embedded version of ironjacamar standalone server and then verify the deployment is correct and or stress some behavior of deployment environment.
And it's fine, since it is stressing an almost real environment. The problem there is this test need to deploy a rar file, and this rar have to be packaged before. We are hitting this goal with a dedicated ant task called prepare-test that is getting right classes and xmls and package all the rar needed for a group of tests.
The problem with this approach is that we always need to run them with ant, making much more difficult to run them inside an IDE and/or in a debug mode. Moreover, the opportunity for potential new contributor to sit in front of or code and play with a particular feature would be much easier if they can just take a unit tests and run it in debug mode and go step-by-step through our code.
Anyway to make this long story short, I'd like to purpose a refactoring of our test suite to make it possible like what I've done for this single test:
https://github.com/maeste/IronJacamar/commit/902423fdd0f6976a0c1d1d386d3b... https://github.com/maeste/IronJacamar/commit/902423fdd0f6976a0c1d1d386d3b...
Of course some minor refinement should be done (like rename the test method calling it something like "shouldRegisterJndiNameAsSpecifiedByIronjacamarXml()"....much easier to understand for new contributors what is the purpose of the test), but you this commit should give you an idea. Please take a look and let me know your feedack
best regards
S.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572765#572765]
Start a new discussion in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
[EJB3 Development] - EJBTHREE-2198 EJB resource providers for switchboard and the dependency issues
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"EJBTHREE-2198 EJB resource providers for switchboard and the dependency issues"
To view the discussion, visit: http://community.jboss.org/message/571870#571870
--------------------------------------------------------------
Here's a quick overview of what the @EJB, ejb-ref, ejb-local-ref resource provider is expected to do. More details about what a ResourceProvider is and what role it plays can be found in this wiki http://community.jboss.org/docs/DOC-15954 http://community.jboss.org/wiki/Switchboard
h5. Goal:
Consider this @EJB reference (in a servlet, for example):
public class MyServlet
{
@EJB
private MyBeanIntf bean;
}
And then consider this EJB:
@Stateless
public class MySLSB implements MyBeanIntf
{
...
}
So ultimately, when the web application is being deployed, the servlet container shouldn't "start" unless the Resource (check the above wiki for what it means) corresponding to:
@EJB
private MyBeanIntf bean;
is made available in the ENC (java:comp/env) of the servlet.
h5. EJB container implementation details:
The JBoss EJB3 container in AS6 is a MC bean. When the JBoss EJB3 container finds a EJB (MySLSB in this case), among various other things, it binds the proxies to (JBoss specific) jndi names during its "start" (MC) lifecycle method. This has been legacy since AS5.
Starting AS6 when we started supporting EJB3.1, we also bind the EJB proxies to a spec compliant JNDI name (along with the JBoss specific jndi names). The binding to EJB3.1 compliant JNDI names is done by the EJBBinder https://github.com/jbossejb3/jboss-ejb3-jndi/blob/master/binder/src/main/... https://github.com/jbossejb3/jboss-ejb3-jndi/blob/master/binder/src/main/... and has no interaction with the EJB containers. i.e. binding to EJB3.1 spec compliant jndi names is (intentionally) completely decoupled from EJB containers. The EJBBinder is deployed as a MC bean by the EJBBinderDeployer https://github.com/jbossejb3/jboss-ejb3-jndi/blob/master/deployers/src/ma... https://github.com/jbossejb3/jboss-ejb3-jndi/blob/master/deployers/src/ma..., so that the binding happens during the "start" lifecycle of that MC bean (when any necessary dependencies on the EJBBinder are satisfied)
Currently in AS6, we bind the EJB3.1 jndi names as LinkRefs to jboss specific jndi names. So the EJBBinder creates and returns a LinkRef to the JBoss specific jndi name which will be created by the JBoss EJB3 containers.
h5.
The ResourceProvider details and the problem:
The ResourceProvider for @EJB, ejb-local-ref and ejb-ref is responsible for resolving the MC bean name of the EJBBinder from a ejb-ref, ejb-local-ref and @EJB. How the resolution is done is currently not relevant for this discussion. Let's just assume that we somehow manage to resolve it to a EJBBinder. The ResourceProvider then return this EJBBinder back to switchboard which converts this to a MC dependency. i.e. SwitchBoard adds a dependency on the servlet container for this EJBBinder MC bean to be installed before the servlet container can make available the servlet. Ideally, this should all work out, but there's a minor little detail in this implementation which causes it to fail. Let's see why:
1) Web container (through SwitchBoard and RPs) adds a dependency on the EJBBinder responsible for setting up EJB3.1 spec compliant java:global jndi name of MySLSB
2) EJBBinder is added as a MC bean
3) EJBContainer corresponding to MyBean is added as a MC bean
4) MC starts installing MC beans. Let's assume it picks up EJBBinder first. EJBBinder "starts" and binds to java:global a LinkRef
5) MC sees that the EJBBinder dependency for web container is now satisfied and triggers the web container startup
6) Web container starts initialzing instances (like load-on-startup servlets, filters etc...)
7) While injecting from ENC to filter/servlet, container runs into error because the EJBContainer (#3) which is responsible for setting up the JBoss specific JNDI names, which are the target of the LinkRef created in #4, hasn't yet been triggered for "start" by MC.
h5.
Solution:
For AS6 we somehow need to add a dependency on the EJBBinder such that it isn't installed until the JBoss specific jndi names aren't bound into JNDI. It isn't easy because the code responsible for deploying EJBBinder as a MC bean (i.e. EJBBinderDeployer) somehow needs to know what the JBoss specific JNDI names are for each of the exposed view of the bean.
Note that this may not be the only solution and there might be other ways to get past this. But the goal is to get this up and running as quickly as possible without having to change a lot of stuff.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/571870#571870]
Start a new discussion in EJB3 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
[JBoss ESB Development] - listener for ESBAware message+Socket communication
by Sandeep Gowda
Sandeep Gowda [http://community.jboss.org/people/SandeepGowda] created the discussion
"listener for ESBAware message+Socket communication"
To view the discussion, visit: http://community.jboss.org/message/572447#572447
--------------------------------------------------------------
Hi,
I am trying to use Jboss ESB as an interceptor for IP socket comunication.
Usecase:
Simple message, which used to get communicated through IP socket client & server program. But now i need to do the same communication through Jboss ESB queues.
Configured the Jboss-esb.xml as below.
1)Using the Jbr-provider
2)Client code placed below(i am able to get the connection properly)
3)Listener code is placed below.
Queues are created properly,But listener java class is not getting invoked.(so that i get the message which has been transfered from client).
*console of jboss esb server 4.9 below*
*15:29:38,519 INFO [JBoss4ESBDeployer] create esb service, Socket.esb
15:29:38,769 INFO [QueueService] Queue[/queue/socket_in_q] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:32:22,518 INFO [JBossRemotingGatewayListener] JBoss Remoting Gateway listener 'listener' started.*
*<?xml version="1.0"?>
<jbossesb parameterReloadSecs="5"
xmlns=" http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml... http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..."
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=" http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml... http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml... http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schem... http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schem...">
<providers>
<jbr-provider host="localhost" name="JBR-Socket"
protocol="socket">
<jbr-bus busid="sockettest" port="6969" />
</jbr-provider>
<jms-provider connection-factory="ConnectionFactory"
name="socket-jms-provider">
<jms-bus busid="socketJmsProvider">
<jms-message-filter dest-name="queue/socket_in_q"
dest-type="QUEUE" />
</jms-bus>
</jms-provider>
</providers>
<services>
<service category="Socket" description="testSocket" name="socket-JMS-Service">
<listeners>
<jbr-listener busidref="sockettest" is-gateway="true"
name="socketGateway" />
<jms-listener busidref="socketJmsProvider" name="JMSEsbAware" />
</listeners>
<actions>
<action class="listener.SocketListener" name="socketlistener"
process="process" />
</actions>
</service>
</services>
</jbossesb>*
Client Code:
*public class SendMessage {*
* public static void main(String args[]) throws Throwable {
SendMessage sm = new SendMessage();*
* sm.sendMessageToJBRListener("http", 8080, "sandeep gowda");*
* }*
* private void sendMessageToJBRListener(String protocol, int port,
String message) throws Throwable {
String locatorURI = protocol + "://localhost:" + port;
InvokerLocator locator = new InvokerLocator(locatorURI);
System.out
.println("Calling JBoss Remoting Listener using locator URI: "
+ locatorURI);*
* Client remotingClient = null;
try {
remotingClient = new Client(locator);
remotingClient.connect();*
* // Deliver the message to the listener...
Object response = remotingClient.invoke(message);
System.out.println("JBR Class: " + response.getClass().getName());
System.out.println("Response from JBoss Remoting Listener '"
+ locatorURI + "' was '" + response + "'.");
} finally {
if (remotingClient != null) {
remotingClient.disconnect();
}
}
}
}*
Listener code:
*public class SocketListener extends AbstractActionPipelineProcessor{
protected ConfigTree _config;*
* public SocketListener(ConfigTree config) {
_config = config;
}
public Message process(Message arg0) throws ActionProcessingException {*
* arg0.getContext();
return arg0;
}*
*}*
*Thanks*
*Sandeep
*
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572447#572447]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month
[JBoss AS7 Development] - Re: Running AS7 embedded in Arquillian
by David Bosschaert
David Bosschaert [http://community.jboss.org/people/bosschaert] created the discussion
"Re: Running AS7 embedded in Arquillian"
To view the discussion, visit: http://community.jboss.org/message/572698#572698
--------------------------------------------------------------
> Jason Greene wrote:
> As you know, I never really bought into the reasons behind packaged deps. I think OSGi is the only modularity spec that advocates them, and even they are moving away from them with their capabilities and requirements notion.
No - OSGi is not moving away from the package dependency model, that is an incorrect observation. The generic capabilities and requirements provide an additional level of declaring dependencies in cases where you don't have this information available as packages. Examples are the existence of an IoC (beans that are being injected typically don't have a package dependency on the IoC container) or some other type of extender.
OSGi is the most mature modularity system around today and although it supports other types of dependency declaration the package dependency model has been found the best dependency model by all OSGi experts that I know of.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572698#572698]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 1 month