September 2009 - jboss-dev-forums

[EJB 3.0 Development] - EJB 3.1 Interceptor Support Library

by marius.bogoevici

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. Cheers, Marius 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

15 years, 3 months

1
0
0 / 0

[JBoss Build System Development] - Re: Accessing maven dependency class from exec-maven-plugin

by galder.zamarreno＠jboss.com

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

15 years, 3 months

1
0
0 / 0

[JBoss Build System Development] - Accessing maven dependency class from exec-maven-plugin clas

by galder.zamarreno＠jboss.com

Hi, 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. Thoughts? 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

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: EBWS Security Support

by jeffdelong

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

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: EBWS Security Support

by beve

Perhaps this might be a little better: Description 'war-security' Security configuration that is global to the jboss-esb.xml file. These configuration settings are shared for all http-providers and EBWS that are defined in jboss-esb.xml. | <globals> | <war-security method="BASIC" domain="JBossWS" /> | </globals> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257668#4257668 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257668

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: EBWS Security Support

by beve

Hi Anil, Kev an I discussed this in a call just a while ago and it was decided to introduce a new top level configuration element. This element will contain configurations that are global to the jboss-esb.xml file. So we will put the authentication method and authentication domain for the war in this new element. This is what I'm using at the moment: <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..." parameterReloadSecs="5"> | | <globals> | <auth method="BASIC" domain="JBossWS" /> | </globals> | ... | </jbossesb> Since the there is one war per jboss-esb.xml (if you have a http-provider or expose a esb service as a web service (EBWS)) it makes sense to have this outside of the http-provider and separate from the esb service security configuration. Any thought on this? Any better suggestion for the 'globals' element name? Regards, /Daniel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257662#4257662 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257662

15 years, 3 months

1
0
0 / 0

[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors

by johnbailey

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); | | builder.addLibrary(...) | .addWebResource(...) | .addServlet(...); | | 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); | | webArchive.addWebResource(descriptor); | | descriptor.addFilter(...) | .addServlet(...); | | 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

15 years, 3 months

1
0
0 / 0

[JBoss ESB Development] - Re: EBWS Security Support

by anil.saldhana＠jboss.com

I guess the Container security kicks in by default at the war level if the security constraints etc exist in web.xml (the same applies to WS deployed as a war). Probably, you should be looking at ESB security only and selectively introducing a separate security processor in the interceptor chain, based on some configuration? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257659#4257659 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257659

15 years, 3 months

1
0
0 / 0

[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors

by aslak

@ALR @epbernard 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

15 years, 3 months

1
0
0 / 0

[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors

by ALRubinger

"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. S, ALR 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

15 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2009