[JBoss AS 7 Development] - Hacking on AS7
by Wolf-Dieter Fink
Wolf-Dieter Fink [http://community.jboss.org/people/wdfink] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4.
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. As a precaution, disable merge commits to your master
git config branch.master.mergeoptions --ff-only
h4. 6. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 7. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
(--rebase will automatically move your local commits, if you have any, on top of the latest branch you pull from, you can leave it off if you do not).
Please note that --rebase is very important if you do have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words a merge commit makes the history a graph, and we prefer a cleaner, easier to follow linear history (hence the rebasing). Further once you do a merge commit it will be difficult to rebase the history before that commit (say you want to combine two commits to one later) as described in point 12+. Luckily the option set in step 5 will prevent this from happening.+
One way to not forget --rebase the rebase option is you may want to create an alias
$ git config --global alias.up "pull --rebase"
and then just use the new alias instead of pull
$ git up upstream master
One last option, which some prefer, is to avoid using pull altogether, and just use fetch + rebase (this is of course more typing)
h4. 8. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
You might need to say -f to force the changes. Read the note on 12 though before you do it.
h4. 9. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 10. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 11. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h4. 12. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push origin my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 13. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f origin my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 14. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
5. To update the master branch of your github repository (otherwise you will see a message like 'Your branch is ahead of 'origin/master' by XXX commits.'
if you are use 'git status' on your local master branch.1. git push origin master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
8. *Important:* Do *not* introduce a dependecy on the "*system*" module. If you need access to JDK classes which are not covered by any other dependency, use the "javax.api" module as a dependency.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add the new submodule to the modules section element of the top-level pom.xml
5. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
6. Edit build/pom.xml and add the new submodule with only group/artifact.
7. Create a directory in build/src/main/resources/modules corresponding to the submodule, with a version of "main", like this: "build/src/main/resources/modules/org/jboss/as/new-subsystem/main".
8. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
9. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Appendix D. Importing into Eclipse
The directory "ide-configs/eclipse" contains both formatter and code templates. Use these to pass the CheckStyle enforcer during the build if coding from Eclipse.
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
h4. Partial Builds
It's common when working on a particular module to need to build that module and the overall AS distribution numerous times. Doing a full AS build can be overly time consuming in this situation. The maven rf and pl options can be helpful in limiting the build to a subset of all the AS modules. See http://java.dzone.com/articles/5-maven-tips this quick introduction to both of these maven switches.
A fairly common thing is to work on a single subsystem, so you need that subsystem built, and to also have the full AS dist rebuilt so the new version of the subsystem's jar ends up in build/target. To do this, for example with the ejb3 subsystem, you would:
mvn install -pl ejb3,build
h4. IDE Integration
h5. Eclipse
Follow the steps mentioned here http://community.jboss.org/docs/DOC-16718 http://community.jboss.org/wiki/HackingAS7usingEclipse
h3.
h3. Checkstyle Errors
If you need to first verify that your changes pass the checkstyle audit, do this first.
mvn checkstyle:checkstyle
Then you can proceed with the build.
h3.
h3. Adding Subsystem Scripts
If you have a need to add a script to AS7, then definitely it should finally land inside bin/util directory. One important thing that you will need to have as part of your subsystem pom is the following plugin.
<!-- JAR -->
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>org.jboss.as.security.vault.VaultTool</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Substitute your main class.
h3.
h3. How do I ensure that my code does not blow up the testsuite?
First try to run the tests as part of the build before sending a pull request.
$> ./build.sh clean install -DallTests
Sometime there are test failures that are not related to your code changes. Try to discuss this on the mailing list or IRC.
You can get a full run using
$> ./build.sh clean install -DallTests -fae
1. This additional option will allow the build to continue even when there are test failures. Doing this, you can get a stock of all the test failures and figure out how many are related to your code changes.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS 7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
[JBoss Web Services Development] - Re: Can I modify the HandlerChain at deploy time?
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/asoldano] created the discussion
"Re: Can I modify the HandlerChain at deploy time?"
To view the discussion, visit: http://community.jboss.org/message/641226#641226
--------------------------------------------------------------
Hi Paul,
first of all, I moved this discussion to the development section of the forum.
Now, I see some alternatives for you to achieve what you need:
1) The user is supposed to specify handlers either using JAXWS annotation (@HandlerChain) or through the jbossws endpoint configurations (@EndpointConfig and then provide a configuration file with handlers specification in the deployment or reference a configuration in the AS7 domain). So the first option is asking users to properly annotate endpoint classes, not sure this is acceptable for your use case.
2) You could make sure a webservices.xml descriptor (JSR-109) is added to the deployment and specify the handlers in there. The descriptor is parsed during the Phase.PARSE in AS7.
3) You could also hook in a little bit later then what you'd do for 2) and modify the jbossws spi metadata that are created after parsing the webservices.xml descriptor. To be honest, you'd need actually create them most of the time, given it's not that common to have webservices.xml for JAXWS deployments. Btw, there's a little bug I just discovered here, I'm going to fix it later today or tomorrow.
4) Another alternative is using the Apache CXF API, but that would bind you to implementation details of cxf and still require some changes in jbossws for you to hook into the proper point in the endpoint publish process.. so not really a good option.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/641226#641226]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss AS 7 Development] - AS7 : Security Domain Model - need help!
by chris81t
chris81t [http://community.jboss.org/people/chris81t] created the discussion
"AS7 : Security Domain Model - need help!"
To view the discussion, visit: http://community.jboss.org/message/641555#641555
--------------------------------------------------------------
Hello,
I'm writing a web application ( using JBoss AS7.0.2 ) which requires a login. A few month's ago I have written a custom loginModule / Realm for the glassfish server ( custom while using db-tables that knows the login-informations. I know that DatabaseModules exist, but the given/required table structure of that existing db-module doesn't match with my db-model )
I have found following article: http://community.jboss.org/docs/DOC-16811 http://community.jboss.org/wiki/JBossAS7SecurityDomainModel
There I found the hint to the article: http://community.jboss.org/docs/DOC-17357 http://community.jboss.org/wiki/JBossAS7SecurityCustomLoginModules
*First question:* Is a custom login module only possible with the coming AS 7.1 release? Or can I use it with my AS 7.0.2 app-server?
So my first step is to write a simple prototype- example web application, which uses the *UsersRoles* Security Domain.
First I have added to the standalone.xml following part (blue text):
<security-domains>
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="Disabled" flag="required"/>
</authentication>
</security-domain>
<security-domain name="form-auth" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="users.properties"/>
<module-option name="rolesProperties" value="roles.properties"/>
</login-module>
</authentication>
</security-domain>
</security-domains>
Now my web- example project (JSF2.0 using CDI) (is attached as an eclipse project to this post):
- the project contains the properties files
I have got as the welcome page a start.xhtml. While defined the security-constraint in the web.xml the login.xhtml page (two input fields for user/password and one commandButton for the login) should be called, if an access to the start.xhtml will occur.
Here some code-snippets:
The managed bean, which executes the login while pressing the commandButton:
@Named
@RequestScoped
public class LoginBean implements Serializable {
private static final long serialVersionUID = -6308095244497641582L;
private String user;
private String password;
public String getUser() {
return user;
}
public void setUser(String user) {
this.user = user;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
public String login() {
FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
HttpServletRequest hsr = (HttpServletRequest) ec.getRequest();
try {
hsr.login(user, password);
}
catch (ServletException se) {
// create a message to inform the user
FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_WARN,
"Ein falscher Profilname und " +
"oder ein falsches Passwort " +
"wurde eingegeben!",
null);
fc.addMessage(null, msg);
return null;
}
// for the first test simply navigate to the one existing page
return "/start";
}
}
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID"
version="3.0">
<display-name>LoginExample</display-name>
<!-- Change to "Production" when you are ready to deploy -->
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<!-- Welcome page -->
<welcome-file-list>
<welcome-file>/start.xhtml</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
<!-- Define a Security Constraint on this Application -->
<security-constraint>
<web-resource-collection>
<web-resource-name>SALES Application</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<!-- Define the Login Configuration for this Application -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Login Example Application</realm-name>
<form-login-config>
<form-login-page>/login.xhtml</form-login-page>
<form-error-page>/failure.xhtml</form-error-page>
</form-login-config>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<description>
The role that is required to log in to the Example Application
</description>
<role-name>user</role-name>
</security-role>
</web-app>
jboss-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>form-auth</security-domain>
<disable-audit>true</disable-audit>
<context-root>/login</context-root>
</jboss-web>
*during the deployment the jboss fails with following error:*
> 15:56:16,109 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC00001: Failed to start service jboss.deployment.unit."SecurityDomainLoginExample.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."SecurityDomainLoginExample.war".PARSE: Failed to process phase PARSE of deployment "SecurityDomainLoginExample.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.7.0_b147-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.7.0_b147-icedtea]
> at java.lang.Thread.run(Thread.java:722) [:1.7.0_b147-icedtea]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/SecurityDomainLoginExample.war/WEB-INF/jboss-web.xml" at [4,2]
> at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:68)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
> ... 5 more
>
>
> 15:56:16,111 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) Service status report
> Services which failed to start:
> service jboss.deployment.unit."SecurityDomainLoginExample.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."SecurityDomainLoginExample.war".PARSE: Failed to process phase PARSE of deployment "SecurityDomainLoginExample.war"
>
Can anybody help me? Thank's!
Regards,
Christian
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/641555#641555]
Start a new discussion in JBoss AS 7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss AS 7 Development] - JBossWS/CXF configuration / extensions
by Robert Stupp
Robert Stupp [http://community.jboss.org/people/snazy0] created the discussion
"JBossWS/CXF configuration / extensions"
To view the discussion, visit: http://community.jboss.org/message/640779#640779
--------------------------------------------------------------
Hi,
I am currently working on a project, where we need to add custom CXF interceptors to the CXF bus for the current deployment.
The only practically working way to customize the deployment is to add a WEB-INF/jbossws-cxf.xml file to our deployment.
Generally it works, but there are some bad things using the combination AS7/JBossWS/CXF.
We have a lot of web services which are bundled in one or more WAR files.
All of them have "standard" JAX-WS annotations (e.g. @WebService) and work fine (everything bundled in a WAR in an EAR ; deploy to AS7 ; fine).
But as I mentioned, we need custom interceptors.
So I added the interceptors to a jbossws-cxf.xml file:
<jaxws:endpoint
address=' http://@jboss.bind.address@/demo/service/SuperService http://@jboss.bind.address@/demo/service/SuperService'
implementor='com.mycompany.demo.java.MySuperWebservice'>
<jaxws:inInterceptors>
<ref bean="myGreatInterceptor"/>
<jaxws:inInterceptors>
</jaxws:endpoint>
This works - but what I really want is a default bus configuration for all webservices in the WAR file (deployment) - I do not want to configure all web services. So I tried the following approach in jbossws-cxf.xml:
<bean class="com.mycompany.jboss7.cxf.BusInterceptorsInjector" init-method="injectInterceptors">
<property name="bus" ref="cxf"/>
<property name="inInterceptors">
<list>
<ref bean="FrameworkCxfPreInvokeInterceptor"/>
<ref bean="FrameworkCxfPostInvokeInterceptor"/>
</list>
</property>
</bean>
This works - but only if *every* webservice is mentioned like
<jaxws:endpoint
address=' http://@jboss.bind.address@/demo/service/SuperService http://@jboss.bind.address@/demo/service/SuperService'
implementor='com.mycompany.demo.java.MySuperWebservice'/>
This is silly, because the jaxws:endpoint configuration specifies nothing meaningful.
Every invocation of a web service which is not mentioned in a jbossws-cxf.xml file, fails with a NullPointerException in org.jboss.wsf.stack.cxf.CXFInstanceProvider at line 57 - the CXFInstanceProvider is configured with a "null" ServerFactoryBean.
What I would like to have in AS7/JBossWS/CXF is
* a mechanism, where I can configure the CXF bus for each deployment (specifying another bus definition in jbossws-cxf.xml does not work, because the "default" bus is created "inside the server code") and
* no need to specify every web service in jbossws-cxf.xml and
* no need to specify the fully qualified address attribute in jaxws:endpoint - developers do not know the exact address, port and context path ot a deployment. AS7/JBossWS should accept at least paths relative to the context root of the current deployment (specifying addresses like /service/SuperService does not work - it cannot find the destination of a web service call)
* no need to specify the implementor in jaxws:endpoint, because it is already configured elsewhere (web.xml) - a functionaltity like a "servlet-link" would be great
Robert.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/640779#640779]
Start a new discussion in JBoss AS 7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years