Re: [jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion
"Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/559150#559150
--------------------------------------------------------------
> > I can look into it what would be the best way to do this.
> > Unless you wanna do it yourself.
> Thanks! You can go ahead. :-)
OK, I have a few things ready, but now I need to know what do you need to make this work.
Currently I have this in place:
public synchronized Set<BeanDeploymentArchive> getLibraries() throws Exception
{
if (libs == null || checked.get() == false)
{
List<VirtualFile> excludedFiles = null;
Map<Module, Set<URL>> modules = provider.getMatchingModules();
for (Map.Entry<Module, Set<URL>> entry : modules.entrySet())
{
Set<URL> urls = entry.getValue();
if (excludedUrls != null && excludedFiles == null)
{
excludedFiles = new ArrayList<VirtualFile>();
for (URL eu : excludedUrls)
excludedFiles.add(VFS.getChild(eu));
}
Set<VirtualFile> files = new HashSet<VirtualFile>();
for (URL u : urls)
{
VirtualFile vf = VFS.getChild(u);
boolean include = true;
if (excludedFiles != null)
{
for (VirtualFile ef : excludedFiles)
{
if (vf.getParentFileList().contains(ef))
{
include = false;
break;
}
}
}
if (include)
files.add(vf);
}
if (files.isEmpty() == false)
{
ClassLoader cl = ClassLoading.getClassLoaderForModule(entry.getKey());
// is this module already installed; past CL stage -- should be
if (cl != null)
{
// TODO <----- your input needed here
}
}
}
checked.set(true);
}
return libs;
}
I can now return a set of matching modules, which have beans.xml as part of its resources.
This is mostly aimed at system deployments, though it can serve all deployments.
(it will be disabled once get past PS' DEPLOYERS phase)
Each module is mapped to beans.xml' owners; e.g. some-cdi-lib.jar.
Will this info be enough for you?
Or at which example / use case / code should I look for more info?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559150#559150]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months
[JBoss Web Services Development] - Choreography Implementation
by Xuan Song
Xuan Song [http://community.jboss.org/people/songxuanss] created the discussion
"Choreography Implementation"
To view the discussion, visit: http://community.jboss.org/message/559146#559146
--------------------------------------------------------------
Hi there,
Right now I'm studying service composition and already finished my study on Orchestration. When I turn to Choreography, however, I found it really hard for to come up with a solution to really implement a Choreography based composition.
WS-CDL is only used for description or simulation (work with pi4soa) and it is just a W3C Candidate recommendation, BPMN2 seems cannot be used for real implementation as well.
To be precise,
If i have 3 web services A, B, and C, How can I really build a Choreography based composition, to make A, B and C have a real peer-to-peer communication between one another?
Moreover, according to some search, few researchers have built engines to really execute ws-cdl liked file to really implement Choreography (such as OpenKnowledge and WS-CDL+), with the help of these engines, service A, B and C can really collaborate with one another (something like, once A sends B some message, B will have some kinds of reaction). However, they ar not really integrated with any IDE which makes it time consuming.
Is there any well supported solution to implement Choreography?
Kind Regrads~ and Thanks for your help.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559146#559146]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months
[EJB 3.0 Development] - EJB reference resolvers
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] modified the document:
"EJB reference resolvers"
To view the document, visit: http://community.jboss.org/docs/DOC-15746
--------------------------------------------------------------
h1. Purpose of this document:
This wiki briefly explains the EJB reference resolvers in the JBoss EJB3 project.
h1. Background
Assuming a @EJB has to injected into a component or a component has a ejb-ref, this reference needs to be resolved to a JNDI name. The JNDI name can then be used by various service providers (like EJB containers, Weld or any other framework which does the injection) to lookup the proxy of the reference EJB.
A short example:
@Stateless
public class A
{
// local business interface view of B bean
@EJB
private BLocal otherBeanLocal;
// remote business interface view of B bean
@EJB
private BRemote otherBeanRemote;
// no-interface view of B bean
@EJB
private B nointerfaceViewOfSomeOtherBean;
....
}
@Stateless
@LocalBean
@Local(BLocal.class)
@Remote (BRemote.class)
public class B
{
....
}
As can be seen above, the "A" SLSB is being injected with various different views of "B" bean. Each of these @EJB will internally have to be resolved, by containers, to a jndi-name to inject the appropriate proxies.
h1. Details:
Each of the @EJB, above, can be represented as a http://github.com/jbossejb3/jboss-ejb3-ejbref-resolver/blob/master/spi/sr... EjbReference. The EjbReference can then be passed to a http://github.com/jbossejb3/jboss-ejb3-ejbref-resolver/blob/master/spi/sr... EjbReferenceResovler to resolve the jndi-name. The EjbReferenceResolver has one simple method:
package org.jboss.ejb3.ejbref.resolver.spi;
import org.jboss.deployers.structure.spi.DeploymentUnit;
/**
* EjbReferenceResolver
*
* @author ALR* @version $Revision: $
*/
public interface EjbReferenceResolver
{
// --------------------------------------------------------------------------------||
// Contracts ----------------------------------------------------------------------||
// --------------------------------------------------------------------------------||
/**
* Returns the JNDI Name of the proxy described by the specified
* arguments.
*
* @param du The DeploymentUnit in question
* @param reference The EJB reference used
* @throws UnresolvableReferenceException If the reference cannot be resolved within scope
* @return
*/
String resolveEjb(DeploymentUnit du, EjbReference reference) throws UnresolvableReferenceException;
}
As can be seen the "resolveEjb" method accepts the EjbReference and a org.jboss.deployers.structure.spi.DeploymentUnit. The org.jboss.deployers.structure.spi.DeploymentUnit represents a deployment unit in a MC based deployment framework. Implementations ot EjbReferenceResolver can use the passed deployment unit to resolve the jndi name of the EjbReference.
h1. Out-of-box implementations:
* EJB 3.0:
** http://github.com/jbossejb3/jboss-ejb3-ejbref-resolver/blob/master/ejb30-... org.jboss.ejb3.ejbref.resolver.ejb30.impl.FirstMatchEjbReferenceResolver
** http://github.com/jbossejb3/jboss-ejb3-ejbref-resolver/blob/master/ejb30-... org.jboss.ejb3.ejbref.resolver.ejb30.impl.ScopedEJBReferenceResolver
The above 2 EjbReferenceResolver implementations are meant for EJB 3.0 deployments. These resolvers have no notion of EJB3.1 nointerface views (or for that matter any EJB3.1 specific semantics). As such these resolvers cannot be used to resolve the jndi-name for the EjbReference of a no-interface view of a bean. Specifically, in the previous code example, these 2 resolvers wont be able to resolve:
// no-interface view of B bean
@EJB
private B nointerfaceViewOfSomeOtherBean;
* EJB 3.1:
** http://github.com/jbossejb3/jboss-ejb3-ejbref-resolver/blob/master/ejb31-... org.jboss.ejb3.ejbref.resolver.ejb31.impl.FirstMatchEjbReferenceResolver
** http://github.com/jbossejb3/jboss-ejb3-ejbref-resolver/blob/master/ejb31-... org.jboss.ejb3.ejbref.resolver.ejb31.impl.ScopedEJBReferenceResolver
(Even though the resolver classnames are the same, note the difference in the package names for EJB 3.0 and EJB 3.1).
These 2 EJB3.1 EjbReferenceResolver implementations can be used for both EJB3.0 and EJB3.1 deployments. As such these resolvers can be used to resolve even the EjbReference of no-interface views of beans. So in the previous code example, these 2 resolvers will be able to resolve the jndi-name of all those @EJB references.
h1. Usage example:
@Stateless
public class A
{
// local business interface view of B bean
@EJB
private BLocal otherBeanLocal;
// remote business interface view of B bean
@EJB
private BRemote otherBeanRemote;
// no-interface view of B bean
@EJB
private B nointerfaceViewOfSomeOtherBean;
....
}
@Stateless
@LocalBean
@Local(BLocal.class)
@Remote (BRemote.class)
public class B
{
....
}
import org.jboss.deployers.structure.spi.DeploymentUnit;
import org.jboss.ejb3.ejbref.resolver.ejb31.impl.FirstMatchEjbReferenceResolver;
import org.jboss.ejb3.ejbref.resolver.spi.EjbReference;
import org.jboss.ejb3.ejbref.resolver.spi.EjbReferenceResolver;
public class Usage
{
public void resolveEjbReferenceForDeployment(DeploymentUnit du)
{
// Note, the process of getting hold of the DeploymentUnit is out of scope
// of this article.
// Let's just assume that the passed DeploymentUnit corresponds to a .jar
// containing the A and B beans show above
// 1. Let's first resolve the jndi-name for:
// local business interface view of B bean
// @EJB
// private BLocal otherBeanLocal;
// first let's create the EjbReference for the BLocal ejb reference
EjbReference ejbRefToBLocal = new EjbReference(null, BLocal.class.getName(), null);
// now let's use the (EJB3.1) FirstMatchEjbReferenceResolver to resolve the ejb reference
EjbReferenceResolver ejbRefResolver = new FirstMatchEjbReferenceResolver();
String jndiNameToBLocal = ejbRefResolver.resolve(du,ejbRefToBLocal);
// just print out the jndi-name
System.out.println("jndi-name for @EJB to BLocal is: " + jndiNameToBLocal);
// 2. Let's now resolve the jndi-name for:
// remote business interface view of B bean
// @EJB
// private BRemote otherBeanRemote;
// first let's create the EjbReference for the BRemote ejb reference
EjbReference ejbRefToBRemote = new EjbReference(null, BRemote.class.getName(), null);
// Let's use the same (EJB3.1) FirstMatchEjbReferenceResolver to resolve the ejb reference
String jndiNameToBRemote = ejbRefResolver.resolve(du,ejbRefToBRemote);
// just print out the jndi-name
System.out.println("jndi-name for @EJB to BRemote is: " + jndiNameToBRemote);
// 3. Let's now resolve the jndi-name for:
// no-interface view of B bean
// @EJB
// private B nointerfaceViewOfSomeOtherBean;
// first let's create the EjbReference for the no-interface view of the ejb reference
// Note that for the no-interface view, the second parameter (i.e. the beanInterfaceName) to EjbReference
// is the fully qualified class name of the EJB implementation class
EjbReference ejbRefToBNoInterfaceView = new EjbReference(null, B.class.getName(), null);
// Let's use the same (EJB3.1) FirstMatchEjbReferenceResolver to resolve the ejb reference
String jndiNameToBNoInterfaceView = ejbRefResolver.resolve(du,ejbRefToBNoInterfaceView);
// just print out the jndi-name
System.out.println("jndi-name for @EJB to B (no-interface view) is: " + jndiNameToBNoInterfaceView);
}
h1. Maven co-ordinates:
The EjbReference and EjbReferenceResolver SPI reside in org.jboss.ejb3.ejbref.resolver:ejbref-resolver-spi artifact. The EJB3.0 implementations reside in org.jboss.ejb3.ejbref.resolver:ejbref-resolver-ejb30-impl artifact. The EJB3.1 implementations reside in org.jboss.ejb3.ejbref.resolver:ejbref-resolver-ejb31-impl artifact.
h1. Outdated references
Before the org.jboss.ejb3.ejbref.resolver project was created, similar EjbReference resolution resided in org.jboss.ejb3:jboss-ejb3-common artifact. The EjbReference, EjbReferenceResolver and the implementations from org.jboss.ejb3:jboss-ejb3-common are now deprecated and will not be supported in the long term. JBoss EJB3 and other projects are encouraged to use the new org.jboss.ejb3.ejbref.resolver:* artifacts.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15746]
Create a new document in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 4 months