[JBoss ESB Development] - Re: Advanced MessageStore implementation
by jack lista
jack lista [http://community.jboss.org/people/jackalista] created the discussion
"Re: Advanced MessageStore implementation"
To view the discussion, visit: http://community.jboss.org/message/572551#572551
--------------------------------------------------------------
Hello. This post from Thomas P expresses my interest in functionality for the MessageStore quite well, but I am having some trouble figuring out what the state of things are in this implementation. I am indeed interested in thye possible use of JCR technology to provide aforementioned features butalso saw this post in anotherthread that made it appear that only the payloads were being saved to the store so that makes me wonder if the existing implementation can deliver the features mentioned in this thread. That other post is here:
http://community.jboss.org/thread/105751 http://community.jboss.org/thread/105751?start=0&tstart=0
Can anyone comment on the state of things WRT use of JCR to provide features as described in this thread? Also, is the whole message now being stored? (I can't tell with finality, though there is code referenced in the above link I mentioned that looks like it may just be a payload rather than the whole message which may be problematic). What is the best current thinking on provision of features as mentioned in this thread for the ESB dist? We have unclear requirements at the moment but I would like to position us to take advantage of the platform as it evolves, it's just that I'm having a tough time figuring out what's there now and many of the threads talking about it are a coiuple years old. I would love to hear from Mark, BIll, Derek or any others directly involved to find out what the best facilities are that are currently available, what the road map looks like for the future of this MessageStore and how we can get the most out of existing features and stay well positioned to take advantage of new developments as they occur.
Thank you much,
-=j=-
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572551#572551]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months
[JBoss Web Services Development] - AS7: Re-thinking WS container integration
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] created the discussion
"AS7: Re-thinking WS container integration"
To view the discussion, visit: http://community.jboss.org/message/572530#572530
--------------------------------------------------------------
JBossWS 4 is going to be the jbossws integration layer for JBoss AS 7. This is both a chance of working on major spi changes / cleanup [1] as well as revisiting the whole way the installed ws stack (CXF or Native) is used for deploying endpoints.
*DOMAIN MODEL*
One of the idea AS7 comes with is exposing a domain for centralized control of the application server(s). JBossWS is going to contribute a ws subsystem to that domain, at least for setting the server level configuration aspects of the webservice engine.
The most obvious element being included in ws subsystem of the AS7 domain are the information required for setting the "WS config", i.e. what we currently have in the WSServerConfig bean declared in stack-agnostic-jboss-beans.xml (webServiceHost, modifySoapAddress, etc.).
We'll then have the records' management configuration, which is also something configured at server level (WSMemoryBufferRecorder, WSLogRecorder, etc. currently in stack-specific-jboss-beans.xml).
Besides the easy things above, we should probably allow for pre-configuring a given application server instance with default endpoints (perhaps clients too in the future), meaning users can specify an endpoint configuration and have that endpoint included as part of the application server, the same way they would have had if they deployed an archive with the corresponding endpoint declaration [2].
*API REVIEW*
In the process of revisiting the JBossWS SPI, we need to properly split the current jbossws-spi project contents into:
- a set of classes/interfaces required for proper abstraction of jbossws components (pretty much what we have today, 2 stacks, perhaps multiple supported target container[3], ...) and to have a defined interface towards other related jboss projects (EJB3 for instance)
- a public API meant for actual user consumption, which would end up in a AS7 module visible to user deployments
The latter is going to include the classes/interfaces the domain model maps to (ws config, records stuff, service/endpoint/deployment basic stuff like endpoint class, publish address, ...) and what's required for tooling (wsconsume / wsprovide Ant tasks, command classes, etc.)
*CONTAINER INTEGRATION*
For integrating into AS7, we need to rethink the way jbossws handles deployments in terms of services (which are one of the key elements of AS7). At the end of the day, what the ws subsystem is supposed to do is providing facilities for starting/stopping webservice endpoints (and clients). Given the management requests of AS7, the domain model, etc. it's time to think about that as something not directly tied to the deployment process only, but generally available as a service instead. Other services in the application server might depend on or simply make use of this service [2]. The deployers (DeploymentUnitProcessors in AS7) should just be "clients" of this service.
To a certaint extent this way of thinking about the container integration fits with what has been done in JAXWS 2.2 Endpoint API and -for instance- the way an Apache CXF endpoint is started. We should be able to parse and digest an endpoint configuration, properly setup the transport layer and then simply trigger the endpoint deployment.
Currently (AS 5/6) the ws deployment goes through many ws deployers, most of which wrap jbossws "deployment aspects" (DA). Those can probably be splitted into few groups:
1) DAs dealing with figuring out / processing basic and container related informations (context root, url pattern, endpoint address, endpoint name)
2) DAs converting information coming from merged metadata (descriptors + annotations) into the jbossws-spi metadata
3) DAs dealing with the transport (creating / modifying the jbossweb metadata for ws endpoints)
4) DAs dealing with ws stack internals (for native: UMDM creating, eventing, rm, eager init, ... for cxf: jbossws-cxf descriptor creation, bus creation, ...)
Some of these are most probably meant for remaining part of the deployers (probably 1,2,3), the rest (probably 4) is actually going to become part of the services providing facilities for starting/stopping an endpoint.
The jbossws-spi should be seen as the interface for feeding the ws services that deal with endpoints.
http://community.jboss.org/servlet/JiveServlet/showImage/2-572530-10658/A... http://community.jboss.org/servlet/JiveServlet/downloadImage/2-572530-106...
While the AS7 / domain management system is going to simply make use of the public api part of jbossws-spi, the deployers are probably going to process all the metadata information coming from annotations and deployment descriptors into the jbossws-spi metadata and then feed the endpoint creation service. Deployers will also deal with / set required dependencies on other services involved in the deployment phase, for instance the web server service (which for instance will be required to properly create a context for the endpoint(s)).
*WS SERVICES*
What is then required to be a (WS) service? Apart from some obvious facilities like the endpoint registry and a server configuration provider service, the main service is the one meant for starting/stopping endpoints.
We need to carefully define a stable interface for this service, so that it can be maintained without much changes in the future. This mainly implies establishing the inputs for creating/starting an endpoint, basically the metadata carrying the required information for that. Ideally that should already be covered by what we have in jbossws-spi, plus stack specific configuration stuff.
For CXF that's everything that can be included in the jbossws-cxf.xml / cxf.xml, for Native it's what comes from the union of the info in endpoint configurations (configName / configFile...) and other additional optional descriptors (e.g. the jboss-wsse-*.xml).
For the sake of practically supporting future extensions / changes, the stuff above should most probably be modelled as AS7 extensions, each coming with its own parser bound to a given xsd namespace. For supporting advanced usecases (iow WS-*), the domain model should probably simply accept a pointer to additional xml configuration (beyond what's in the basic user API which is part of jbossws-spi, etc. - see above). Depending on the default namespace of the provided xml, the proper parser (coming from the installed ws stack) would be used and the domain enriched with the provided information for creating endpoint(s).
At the end of the day, most (if not all) the information is the Bus (for jbossws-cxf) / the UMDM (for jbossws-native).
What do you think about this all? My plan would be to get to an agreement on the main design for JBossWS 4 / AS 7 integration, perhaps by some iteration here on this forum discussion. Then we can isolate/create/update jiras for what needs to be done and start scheduling things.
[1] JBWS-2709, JBWS-3115, JBWS-3105, JBWS-2338
[2] http://community.jboss.org/message/571376#571376 http://community.jboss.org/message/571376#571376
[3] JBossWS 4 will most probably at first support AS 7.x only
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572530#572530]
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
[JBoss AS7 Development] - Re: How to model the (optional) OSGi webconsole in AS7
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"Re: How to model the (optional) OSGi webconsole in AS7"
To view the discussion, visit: http://community.jboss.org/message/572497#572497
--------------------------------------------------------------
Agreed on the IzPack approach.
In discussions last week there were a lot of calls for breaking the config into multiple files. I expect we'll keep hearing that, so it's good to think about it. There are a couple problems I see:
1) The file write problem David pointed out. The domain model would have to start carrying around info about what files various pieces came from, plus generally messier parsing and persisting.
2) The logical thing to separate out into an included file is a subsystem config. But that config isn't entirely self-contained. For example, a subsystem could reference a socket-binding config that's in the socket-binding-groups section and a thread group defined in the threads subsystem. Plus it needs to be recorded as an extension. So to be really useful bringing in that subsystem's config isn't a simple matter of an include; it would be more of a merge.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572497#572497]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months
[JBoss AOP Development] - Binding annotated methods and session bean methods
by Marco Strauch
Marco Strauch [http://community.jboss.org/people/fambad] created the discussion
"Binding annotated methods and session bean methods"
To view the discussion, visit: http://community.jboss.org/message/572401#572401
--------------------------------------------------------------
Hello,
I have 2 little problems using JBoss AOP within JBoss 5.1.
1. I have annotated methods and I want to create bindings using AOP (e.g. *<bind pointcut="execution(* *->@mstrauch.test.aop.common.MyAnnotation(..))">* .... ). But the aspects are never called. When I bind the method directly without using the annotation it works (e.g. *<bind pointcut="execution(* mstrauch.test.aop.common.CommonTest->*(..))">* ...).
2. The second problem is, that I can't bind methods in session beans (e.g. *<bind pointcut="execution(* mstrauch.test.aop.TestSessionBean->*(..))">*...).
I have follow project structure:
aoptest.ear
| -- lib
| -- common.jar
| -- META-INF
| -- application.xml
| -- jboss-app.xml
| -- aspects.aop
| -- ejb.jar
For testing I tried XML Bindings (MyAspect.class) and Annotation Bindings (MyAnnotationAspect.class). I also put my annoation (MyAnnotation.class, MyAnnotation2.class, MyAnnotation3.class) once in the common.jar, aspects.aop and ejb.jar. But nothing works.
I don't know what is wrong. Maybe somebody can help me.
I attached a complete example with all kinds of bindings. The sample works fine in JBoss 4.3 but not in JBoss 5.1. Below I copied the log output of both JBoss servers. It should be the same but it isn't.
To run the sample, just deploy the exploded archive "aoptest.ear" in JBoss and run the test Method via the JMX-Console ( *http://localhost:8080/jmx-console/HtmlAdaptor?action=displayMBeans&filter=mst.test.aop mst.test.aop:service=TestMBean*)
*Log-Output JBoss 5.1 (JBoss AOP 2.1.8.GA - Version JBoss Aspect Library: 1.3)*
08:53:10,383 INFO [TestClass] [testAnnot01] --> Called Test 01
08:53:10,383 INFO [TestClass] [testAnnot02] --> Called Test 02
08:53:10,383 INFO [TestClass] [testAnnot03] --> Called Test 03
08:53:10,440 INFO [MyAspect] <init>
08:53:10,451 INFO [MyAnnoatedAspect] <init>
08:53:10,454 INFO [MyAspect] [injectTest11 --> test11]
08:53:10,454 INFO [MyAnnoatedAspect] [injectTest11 --> test11]
08:53:10,462 INFO [TestClass] [test11] --> Called Test 11
08:53:10,518 INFO [MyAnnoatedAspect] <init>
08:53:10,518 INFO [MyAspect] [injectCommonTest11 --> testCommon]
08:53:10,519 INFO [MyAnnoatedAspect] [injectCommonTest11 --> testCommon]
08:53:10,527 INFO [CommonTest] [testCommon]
08:53:10,569 INFO [MyAnnoatedAspect] <init>
08:53:10,570 INFO [MyAspect] [injectTestSessionBean --> ejbPostContruct]
08:53:10,570 INFO [MyAnnoatedAspect] [injectTestSessionBean --> ejbPostContruct]
08:53:10,578 INFO [TestSessionBean] [ejbPostContruct]
08:53:10,588 INFO [TestSessionBean] [test01]
*Log-Output JBoss 4.3 (JBoss AOP 1.5.6.GA - Version JBoss Aspect Library: 1.5)*
08:38:29,432 INFO [MyAspect] <init>
08:38:29,482 INFO [MyAnnoatedAspect] <init>
08:38:29,483 INFO [MyAspect] [injectTestAnnot01 --> testAnnot01]
08:38:29,483 INFO [TestClass] [testAnnot01] --> Called Test 01
08:38:29,483 INFO [MyAnnoatedAspect] <init>
08:38:29,484 INFO [MyAspect] [injectTestAnnot02 --> testAnnot02]
08:38:29,484 INFO [TestClass] [testAnnot02] --> Called Test 02
08:38:29,484 INFO [MyAnnoatedAspect] <init>
08:38:29,484 INFO [MyAspect] [injectTestAnnot03 --> testAnnot03]
08:38:29,484 INFO [TestClass] [testAnnot03] --> Called Test 03
08:38:29,484 INFO [MyAnnoatedAspect] <init>
08:38:29,485 INFO [MyAnnoatedAspect] [injectTest11 --> test11]
08:38:29,486 INFO [MyAspect] [injectTest11 --> test11]
08:38:29,486 INFO [TestClass] [test11] --> Called Test 11
08:38:29,521 INFO [MyAnnoatedAspect] <init>
08:38:29,522 INFO [MyAnnoatedAspect] [injectCommonTest11 --> testCommon]
08:38:29,523 INFO [MyAspect] [injectCommonTest11 --> testCommon]
08:38:29,524 INFO [CommonTest] [testCommon]
08:38:29,587 INFO [MyAnnoatedAspect] <init>
08:38:29,588 INFO [MyAnnoatedAspect] [injectTestSessionBean --> ejbPostContruct]
08:38:29,589 INFO [MyAspect] [injectTestSessionBean --> ejbPostContruct]
08:38:29,591 INFO [TestSessionBean] [ejbPostContruct]
08:38:29,592 INFO [MyAnnoatedAspect] [injectTestSessionBean --> test01]
08:38:29,592 INFO [MyAspect] [injectTestSessionBean --> test01]
08:38:29,593 INFO [TestSessionBean] [test01]
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572401#572401]
Start a new discussion in JBoss AOP Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 4 months
