A short update on this:
- we have a first version of the interceptor library at https://svn.jboss.org/repos/jbossas/projects/interceptors
- as far as I can tell by now, it has all what we need for implementing JSR-299 on top of it
- as discussed, the library supports
- interceptor metadata storage (what interceptor classes apply to what intercepted entity - the registry is generic and supports different types of indices (EjbDescriptor, Class)
- interceptor class parsing (given an interceptor class, what methods need to be executed per interception type, including methods inherited from superclass, properly ordered according to the spec, considering overriding and shadowing)
- proxy instance generation - either as proxy wrapping an instance, or creating an object of the instrumented class directly (I somehow favour the latter, as invocations on 'this' will be intercepted out of the box)
There are still tests to be implemented and javadoc to be added, but I think what we have there is is good for looking at, especially for assessing what we need to put more in there in order to have a suitable implementation of a common registry library for EJB 3.1.
In other notes, a snapshot will follow shortly to be used as a dependency for WB.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257688#4257688
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257688
Right now, the only way I see being able to do this, which I find rather ugly, is to have a 2nd jopr maven project with only the generator doclet in it. The main jopr plugin project would then run the doclet from that artifact and generate the xml at the process-classes phase.
One thing I've realised that even if I could get hold of the classpath in the executable to run on the main jopr plugin project, this project would need to have dependencies in all the rest of projects that could contain classes that need scanning, and this could have issues in the future.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257684#4257684
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257684
In Infinispan, we do some post processing of classes to generate JMX documentation by scanning annotations. We do this via a javadoc Doclet that gives us com.sun.javadoc.RootDoc instance which we can loop to check all classes for annotations.
Now, I'd like to use a similar approach that allowed me to generate jopr plugin's rhq-plugin.xml and this processing should involve a similar annotation scanning process before building the infinispan jopr plugin jar.
The obvious thing to do looks to me to have a executable class that is executed before process-classes and that generates the plugin xml. However, how do I get access to the list of maven dependency classes?
I could maybe use a doclet cos I'd get a RootDoc instance but this expects some kind of docletArtifcact where to lookup the doclet is precisely before this artifact is generated that I want to execute this doclet.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257672#4257672
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257672
I am not sure why spend the effort creating a new global section to the jboss-esb.xml. I have never thought that there should be more than one "service" per jboss-esb.xml file even though we allow it. In a service oriented architecture each service should be independently deployed, so from a best practice standpoint, I think having a separate jboss-esb.xml file for each service makes more sense.
What I would like to understand is that even when authentication is performed by the container, the EBWS gateway will add the security token to the ESB message context, and that the ESB will use this for authorization to ESB services, i.e. rolesAllowed and runAs would be supported. Also, that this security context would be available through the API for other programs to access.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257671#4257671
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257671
I agree they need to be decoupled. When combined the interface has a bit of mismatch. This may simply be due to Discritptor being in the name. The following looks very strange to me:
| WebArchiveDescriptor webArchiveDescriptor = ...
| webArchiveDescriptor.add(path, archive)
| .addWebResource(path, asset);
The issue I have is neither of those operations really affects the descriptor for the archive, but nothing would tell me that from the usage.
If the archive behavior was kept as it is today and the WebArchiveDescriptor actually implemented Asset (which is what it is in the end) that will serialize the content to xml prior in the getStream call. There could then be a builder that creates a unified interface to both WebArchive, and WebArchiveDescriptor. Internally the builder creates the WebArchiveDescriptor(extends asset), adds it as the web.xml asset for the archive, and delegates to the archive, descriptor, or both as needed.
Could look like the following:
| WebArchive webArchive = ....
| WebArchiveBuilder builder = new WebArchiveBuilder(webArchive);
It may be the builder is too generic, but it does seem to better describe what you are doing. It would also be possible to do the following:
| WebArchive webArchive = ....
| WebArchiveDescriptor descriptor = new WebArchiveDescriptor(webArchive);
There is a bit more code, but it is more clear when operations affect the archive structure/contents, and when they affect the descriptor. The nice thing about some unified interface like the builder is there are cases where the operation affects both, like addServlet adding the both the descriptor information and the asset.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257661#4257661
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257661
Regardless of the Descriptors, we need the basic function that "specializes" gives us. A way of moving a nested archive into a new 'extension' type.
The best example I have as for now is:
| EnterpriseArchive ear = ..
| WarArchive war = ear.getPathAsA("my.war", WebArchive.class)
In this case, since EnterpriseArchive and WebArchive have a relation it's probably better to have WebArchive archive = EnterpriseArchive.getWebModule(path); but i would like this to be just a struct impl over something like archive.getPathAsA(path, WebArchive.class)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257657#4257657
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257657
"epbernard" wrote : That being said, I think that not providing a unified experience for archive building + configuration building is a bad idea as it would make the "configuration" code look like unreadable code rather than readable configuration.
Yep, let's mull over this a bit. I rank "intuition" highly as a priority for usability.
But take the case of web.xml>"name" element. We can't make a "setName" on WebArchive as this would conflict with the name of the archive. So it'd have to be setWebXmlName or something. This doesn't match up with "addServlet" name forms. So I keep coming back to separating out the descriptor.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257655#4257655
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257655