[Design of JBoss Web Services] - Re: JBossWS Deployers Integration
by richard.opalka＠jboss.com
This is the brain dump of current JBossWS AS integration architecture.
We completely rewrote/reviewed our JBossWS AS integration layer.
However there are still some TODOs. We need to review our SPI and our EJB integration in the future. Also our current injection impl isn't ideal. We'll deal with these issues in near future.
Regarding the current state of AS IL (JBossWS AS integration layer) here are some notes:
We removed the notion of WS EJB deployer, WS PRE JSE deployer and WS POST JSE Deployer. All three deployer were alligned to one processing pipeline.
We also removed the notion of WS deployer hooks.
There are 5 deployers now in AS IL:
* WSDescriptorDeployer - Object model based webservice.xml files parsing deployer (PARSE stage deployer)
* WSEJBAdapterDeployer - WS deployer adapting EJB classes to provide EJB agnostic meta/data fasade for the rest of JBossWS code base (REAL stage deployer)
* WSTypeDeployer - detects webservice deployment type (can be JAXWS JSE, JAXRPC JSE, JAXWS EJB3 and JAXRPC EJB21) (REAL stage deployer)
* WSDeploymentDeployer - builds AS agnostic WS metadata (creates API abstraction over AS IL) (REAL stage deployer)
* WSDeploymentAspectDeployer - wrapper for all JBossWS deployment aspects (replacement for old JBossWS DeploymentAspectManager) (REAL stage deployer)
WSAspectizedDeployersFactory provides mechanism for un/registering JBossWS aspectized deployers
We also completely removed support for AS 4.x series from our AS IL
and updated the codebase to leverage AS 5.x architecture.
The previous suggestion to move some DAs to servlet lifecycle methods showed to wrong (i.e. all JBossWS deployment aspects reside in deployers processing pipeline).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250826#4250826
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250826
16 years, 7 months
[Design of Embedded JBoss] - Re: Covarient returns from a storage delagate
by aslak
The storage engines will be wrapped up/delegated to by the Java/WebArchive spec impls and never exposed directly through the chaining in the Archive interface.
The thought was to let the Storage Engines have there own Archive interfaces and not depended on the specs.
The spec impls would wrap up the storage engines(handeled by a support Superclass) like:
| public JavaArchive add(Asset... assets)
| {
| archive.add(assets);
| return this;
| }
|
They do not extend the storage engines nor do they expose them directly in this way:
| public JavaArchiveImpl extends MemoryArchiveImpl {
| }
|
|
| public JavaArchive add(Asset... assets)
| {
| return archive.add(assets);
| }
|
Here is a more complete stack example:
| public interface ServiceProviderDelegate
| {
| Archive<?> getDelegate();
| }
|
| public interface MemoryArchive extends Archive<MemoryArchive>
| {
| }
|
| public class MemoryArchiveImpl implements MemoryArchive
| {
| }
|
| public class JavaArchiveImpl implements JavaArchive, ServiceProviderDelegate
| {
| Archive<?> archive;
|
| public JavaArchiveImpl(Archive<?> archive)
| {
| this.archive = archive;
| }
|
| public JavaArchive add(Asset... assets)
| {
| archive.add(assets);
| return this;
| }
|
| @Override
| public Archive<?> getDelegate()
| {
| return archive;
| }
| }
|
| JavaArchive jar = new JavaArchiveImpl(new MemoryArchiveImpl());
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250798#4250798
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250798
16 years, 7 months
[Design of JBoss Web Services] - Re: Removing JACC Permissions Hack
by richard.opalka＠jboss.com
"anil.saldhana(a)jboss.com" wrote : JBossWS creates a transient webapp to deal with ws invocations. The original problem was that this web app metadata was not being fed to the security deployer which happens very early in the pipeline of deployers. For this reason, we generated the JACC permissions for this particular transient web app in the webservices module.
|
Yes, this is how it works now. Almost all JBossWS deployers (except WSDescriptorDeployer)) are REAL stage deployers.
"anil.saldhana(a)jboss.com" wrote :
| The fix would be to get the metadata of this transient web app to go through the chain of deployers just like regular standard web apps that get deployed in AS.
OK, I'll investigate whether our dependency on EJB real deployers is really necessary or not and I will try to move our deployers to lower stage.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250791#4250791
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250791
16 years, 7 months
[Design of Embedded JBoss] - Covarient returns from a storage delagate
by johnbailey
I ran into some interesting gotchas when implementing the MemoryMapArchive. The chaining API breaks down a bit when implementing a storage archive. The difficulty is the return type of the storage implementation is set to be the actual type of the archive (JavaArchive, WebArchive, etc...). So it would be expected that each method that allows chaining would have a covarient return type of the actual archive type (JavaArchive, etc...). This can't be handled just by capturing the actual class to use and performing a cast, as the storage archive is only a delegate and is not guaranteed to be an instance of the return archive type. Without multiple inheritance, I don't think we can get this to work without one of the following:
1. The storage archives don't follow the same chaining API:
| void add(Path target, String name, Asset asset) throws IllegalArgumentException;
|
instead of...
| T add(Path target, String name, Asset asset) throws IllegalArgumentException;
|
2. The storage archive must maintain a reference to be used by any chaining methods.
| /** From some storage archive **/
|
| private T primaryArchive;
|
| public void initialize(T archive)
| {
| this.primaryArchive = archive;
| }
|
| protected T covarientReturn()
| {
| return primaryArchive;
| }
|
It would be unfortunate to go the first route as Storage archives would no longer be API compliant. Option two seems to make more sense. Since it is assumed the storage archive is going to be provided to the containers, this may be problematic as there will not be a strict contract to make sure the reference is set on the storage archive. I have an impl working with the second approach, but as this is early on I want to get input on it.
Any thoughts?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250781#4250781
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250781
16 years, 7 months
[Design of POJO Server] - Binding the CDI BeanManager into JNDI
by pete.muir＠jboss.org
The CDI spec requires us to make the BeanManager available in JNDI at java:comp/BeanManager.
I understand java:comp/ has special meaning, so I'm wondering how best to bind the BeanManager there?
Furthermore, the BeanManager instance to return depends on which module of the application the call is made from. Currently we provide an ObjectFactory in Web Beans, which can locate the application in use, but not the module in use. One way to locate the module, would be for the object factory to request the container, via an SPI, identify which module (or BeanDeploymentArchive in Web Beans parlance) is currently being accessed. For example
interface JndiServices {
|
| BeanDeploymentArchive getBeanDeploymentArchive(HashTable environment);
|
| }
An alternative approach would be to pass the responsibility for attaching the correct BeanManager to JNDI depending on module. In that case, we would need to add an API like:
interface DeploymentServices {
|
| BeanManager getBeanManager(BeanDeploymentArchive bda);
| }
which the container could query. We would require that, for each BeanDeploymentArchive, java:comp/BeanManager is made available, with the return value specified by DeploymentServices.
I also believe an API like this would be useful in general.
I favor the latter approach (I'll code this up tomorrow), but what do our JNDI experts think?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250766#4250766
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250766
16 years, 7 months
[Design of POJO Server] - VFSClassLoaderPolicy backed jboss-cl performance issue
by jaikiran
While debugging through performance and boot time issues, we have been seeing that the BaseClassLoader.loadClass() which is backed by a VFSClassLoaderPolicy is consistently expensive. A call to BaseClassloader.loadClass() results in the following flow:
1) BaseClassLoader.loadClass() leads to loadFromDomain
2) The BaseClassLoaderDomain internally starts looking for loaders through findLoader()
3) The findLoader() invokes findLoaderInExports() which tries to look for the correct loader in the "EXPORT"
4) This ultimately leads to the VFSClassLoaderPolicy.getResource() which through it's findChild() API, starts
traversing the jar(s).
5) This traversing ultimately leads to AbstractVirtualFileHandler.structuredFindChild which consistently appears as an expensive operation given that it does:
* ZipEntryHandler.isLeaf() - Haven't looked at why the isLeaf implementation contains the logic that it has right now.
* PathTokenizer.getTokens() - Lot of string manipulations
* ZipEntryHandler.createChildHandler() - Haven't looked at it.
Here's the code from AbstractVirtualFileHandler.structuredFindChild http://anonsvn.jboss.org/repos/jbossas/projects/vfs/branches/Branch_2_1/s...:
| /**
| * Structured implementation of get child
| *
| * @param path the path
| * @return the handler or <code>null</code> if it doesn't exist
| * @throws IOException for any error accessing the virtual file system
| * @throws IllegalArgumentException for a null name
| */
| public VirtualFileHandler structuredFindChild(String path) throws IOException
| {
| checkClosed();
|
| // Parse the path
| List<String> tokens = PathTokenizer.getTokens(path);
| if (tokens == null || tokens.size() == 0)
| return this;
|
| // Go through each context starting from ours
| // check the parents are not leaves.
| VirtualFileHandler current = this;
| for (int i = 0; i < tokens.size(); ++i)
| {
| if (current == null)
| return null;
|
| String token = tokens.get(i);
| if (PathTokenizer.isCurrentToken(token))
| continue;
|
| if (PathTokenizer.isReverseToken(token))
| {
| VirtualFileHandler parent = current.getParent();
| if (parent == null) // TODO - still IOE or null?
| throw new IOException("Using reverse path on top file handler: " + current + ", " + path);
| else
| current = parent;
|
| continue;
| }
|
| if (current.isLeaf())
| {
| return null;
| }
| else if (current instanceof StructuredVirtualFileHandler)
| {
| StructuredVirtualFileHandler structured = (StructuredVirtualFileHandler)current;
| current = structured.createChildHandler(token);
| }
| else
| {
| String remainingPath = PathTokenizer.getRemainingPath(tokens, i);
| return current.getChild(remainingPath);
| }
| }
|
| // The last one is the result
| return current;
| }
|
I haven't yet browsed completely through any of this code. But the classloader performance is appearing as one of the expensive operations in every profiled snapshot that i have, not just at deployment time but at runtime too.
Thoughts on how this can be improved?
P.S: Although during boot time analysis of AS, i had mentioned that classloading backed by VFS was showing up as one of the expensive operation, at that time i had highlighted that it was affecting deployment time of the application. That issue is a separate one where the deployer used to traverse the jar(s) to find the package name capabilities of that jar.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250746#4250746
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250746
16 years, 7 months