Where are allowable methods configured?
by Andrew Lee Rubinger
Booting Embedded I've got a fun exception informing me that methods
"!GET,POST" are not allowed while creating a WebResourcePermission.
These are the identical parameters passed in while running AS in
Standalone. Where are the allowed HTTP methods configured? Does this
ring any bells to anyone?
Thx. :)
17:25:01,895 ERROR [AbstractKernelController] Error installing to Real:
name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/
state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying:
jboss.jacc:service=jacc,id="vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/http-invoker.sar/invoker.war/",parent="http-invoker.sar"
at
org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at ...
Caused by: java.lang.IllegalArgumentException: Could not create resource
permission with pattern "/restricted/*" and methods: !GET,POST
at
org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:229)
at
org.jboss.deployment.security.WarJaccPolicy.createPermissions(WarJaccPolicy.java:55)
at
org.jboss.deployment.security.WarJaccPolicy.createPermissions(WarJaccPolicy.java:38)
at org.jboss.deployment.security.JaccPolicy.create(JaccPolicy.java:94)
...
Caused by: java.lang.IllegalArgumentException: illegal HTTP method
at
javax.security.jacc.HttpMethodSpec.makeMethodSet(HttpMethodSpec.java:100)
at javax.security.jacc.HttpMethodSpec.getMethodSet(HttpMethodSpec.java:74)
at
javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:137)
at
org.jboss.web.WebPermissionMapping.createPermissions(WebPermissionMapping.java:225)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
15 years, 12 months
Moving microcontainer -> kernel
by Kabir Khan
We plan to make some changes to the microcontainer project over the
next few days/week, and wanted to give you all a bit of advance
warning. The reason is that the microcontainer project has grown since
its inception and is an umbrella for numerous sub-projects: jboss-
reflect, jboss-man, jboss-mdr, jboss-mdr-cache, jboss-cl, jboss-
deployers, jboss-vfs as well as the 'microcontainer' project, which is
really the kernel.
Hence, we plan to rebrand the existing 'microcontainer' core as
'kernel', and here is what will change:
*** JIRA ***
We have already moved it in JIRA, so the old JBMICROCONT issues have
been moved to JBKERNEL.
The existing JBMICROCONT project will be kept to deal with global
microcontainer issues.
*** SVN ***
https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
will move to
https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/
But we will leave the existing tags under
https://svn.jboss.org/repos/jbossas/projects/microcontainer/tags/
as well as the branch these releases have been taken from:
https://svn.jboss.org/repos/jbossas/projects/microcontainer/branches/Bran...
The plan is for the
https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
to be come a holder projects for things like tools, docs etc. that
bind together the individual sub-projects.
The upcoming 2.2.x releases will be tagged from
https://svn.jboss.org/repos/jbossas/projects/kernel/branches/
Branch_2_2 (this branch will be created later once we're ready for
2.2.x )
*** MAVEN ***
From 2.2.0 onwards the existing microcontainer artifacts will have a
new groupId
org.jboss.microcontainer -> org.jboss.kernel
The 2.0.x releases will keep on using org.jboss.microcontainer.
Cheers,
Kabir
16 years
split metadata
by Alexey Loubyansky
I have committed the split metadata now. The details are below. I'd like
to get feedback from the projects that use it.
I couldn't execute mvn deploy. It would fail with e.g.
[INFO] Error retrieving previous build number for artifact
'org.jboss.metadata:metadata-common:jar': repository metadata for:
'snapshot org.jboss.meta
data:metadata-common:2.0.0-SNAPSHOT' could not be retrieved from
repository: snapshots.jboss.org due to an error: Authorization failed:
Not authorized
So, if you want to build e.g. EJB metadata you have to check out ejb and
common projects, build and install common and then build ejb.
New metadata structure
----------------------
Metadata project (version 1.0.X) has been split into several: common
project + one project per specific technology. The initial version for
all the new projects is 2.0.0-SNAPSHOT. The current list of the projects is:
- common
- EJB
- WEB
- RAR
- EAR
- client
The common one contains stuff which is used by other projects, plus
common Java EE metadata, common JBoss metadata and WS metadata. These
could further be extracted to their own projects if needed.
All technology-specific projects declare dependency on the common project.
SVN repository
--------------
The main location is
https://svn.jboss.org/repos/jbossas/projects/metadata/. Under which each
project's trunk is located under project_name/trunk, e.g. common/trunk,
ejb/trunk, etc.
Maven
-----
groupId remains the same, i.e. org.jboss.metadata.
artifactId is metadata-project_name, e.g. metadata-common, metadata-ejb,
etc.
Things that were removed
------------------------
Packages org.jboss.ejb3.metamodel and org.jboss.metamodel.descriptor
weren't copied. I am not sure if they are used now.
The same for org.jboss.metadata.test.ejb3 and
org.jboss.metadata.test.generator.
JAWS DTDs weren't copied neither (they shouldn't have been there from
the beginning).
16 years, 1 month
Changes to AS build in trunk
by Paul Gier
I have refactored the AS 6 build so that the thirdparty pom is no longer needed.
The thirdparty pom has now been replaced by two poms. The first one is in
the build directory and contains module dependencies and anything else included
in the AS distribution. The second pom is a new pom in the testsuite directory
and it contains dependencies that are only used in the testsuite.
The thirdparty pom should now be considered deprecated, and I will remove the
thirdparty directory in trunk after a little more testing. If you want to
add/update dependencies in the AS, here is how to do it.
Add a new dependency just to the distribution
---------------------------------------------
1. add/update the dependency in component-matrix/pom.xml
2. add/update the dependency in build/pom.xml
3. the Ant build can then reference the dependency with the format:
${groupId:artifactId:[classifier:]type}
Add/update a dependency used only in the testsuite
--------------------------------------------------
1. add/update the dependency in component-matrix/pom.xml
2. add/update the dependency in testsuite/pom.xml
3. the Ant testsuite build can then reference the dependency with the format:
${groupId:artifactId:[classifier:]type}
Add/update a module dependency
------------------------------
1. add/update the dependency in component-matrix
2. add/update the dependency in the module pom
I will also add this information to the wiki [1] when clearspace starts working
for me again.
[1]http://www.jboss.org/community/wiki/jbossasbuild
16 years, 1 month
Problem when trying to start JBoss as a Service on Fedora 8
by James Dekker
I am having trouble running JBoss as a service / daemon on Fedora 8...
Have installed JBoss 5.1.0 GA under the root user and didn't create a
jboss user.
Here's what I did so far:
(1) Created the following jboss script in /etc/init.d/:
#!/bin/sh
# chkconfig: 3 87 20
#make sure java is in your path
JAVAPTH=${JAVAPTH:-"/usr/java/jdk/bin/java"}
echo JAVAPTH $JAVAPTH
# Set JAVA_HOME
JAVA_HOME=${JAVA_HOME:-"/usr/java/jdk"}
echo JAVA_HOME $JAVA_HOME
echo JAVA $JAVA
# Set classpath
CLASSPATH=$CLASSPATH:$JBOSS_HOME/bin/run.jar:$JAVA_HOME/lib/tools.jar;
echo CLASSPATH $CLASSPATH
#define where jboss is - this is the directory containing directories
log, bin, conf etc
JBOSS_HOME=${JBOSS_HOME:-"/usr/jboss-5.1.0.GA"}
#define the user under which jboss will run, or use 'RUNASIS' to run
as the current user
JBOSS_USER=${JBOSS_USER:-"RUNASIS"}
#configuration to use, usually one of 'minimal', 'default', 'all'
JBOSS_CONF=${JBOSS_CONF:-"default"}
#the host where jboss should answer. o.o.o.o means answer all calls.
set this to yourhost.com
JBOSS_HOST=${JBOSS_HOST:-"0.0.0.0"}
start(){
echo "Starting jboss.."
# If using an SELinux system such as RHEL 4, use the command below
# instead of the "su":
# eval "runuser - jboss -c '/opt/jboss/current/bin/run.sh > /dev/null
2> /dev/null &'
# if the 'su -l ...' command fails (the -l flag is not recognized by
my su cmd) try:
# sudo -u jboss /opt/jboss/bin/run.sh > /dev/null 2> /dev/null &
#su -l jboss -c '/current/bin/run.sh > /dev/null 2> /dev/null &'
# eval "runuser - jboss -c '${JBOSS_HOME}/bin/run.sh > /dev/null 2> /
dev/null &'"
sh ${JBOSS_HOME}/bin/run.sh
}
stop(){
echo "Stopping jboss.."
# If using an SELinux system such as RHEL 4, use the command below
# instead of the "su":
# eval "runuser - jboss -c '/opt/jboss/current/bin/shutdown.sh -S &'
# if the 'su -l ...' command fails try:
# sudo -u jboss /opt/jboss/bin/shutdown.sh -S &
# su -l jboss -c '/opt/jboss/current/bin/shutdown.sh -S &'
sh ${JBOSS_HOME}/bin/shutdown.sh
}
case "$1" in
start)
start
;;
stop)
stop
;;
*)
echo "Usage: jboss {start|stop}"
exit 1
esac
exit 0
(2) Set up permissions and symbolic links (for run levels):
sudo chown root:root /etc/init.d/jboss
sudo chmod ug+x /etc/init.d/jboss
ln -s /etc/rc.d/init.d/jboss /etc/rc3.d/S84jboss
ln -s /etc/rc.d/init.d/jboss /etc/rc4.d/S84jboss
ln -s /etc/rc.d/init.d/jboss /etc/rc5.d/S84jboss
ln -s /etc/rc.d/init.d/jboss/etc/rc6.d/K15jboss
ln -s /etc/rc.d/init.d/jboss/etc/rc0.d/K15jboss
ln -s /etc/rc.d/init.d/jboss/etc/rc1.d/K15jboss
ln -s /etc/rc.d/init.d/jboss/etc/rc2.d/K15jboss
(3) When I run it like this:
/etc/init.d/./jboss
It runs perfectly (please take note the echo statements that show up
first):
JAVAPTH /usr/java/jdk/bin/java
JAVA_HOME /usr/java/jdk
JAVA
CLASSPATH .:/usr/jboss-5.1.0.GA/bin/run.jar:/usr/java/jdk/lib/tools.jar:
/usr/jboss-5.1.0.GA/bin/run.jar:/usr/java/jdk/lib/tools.jar
Starting jboss..
=
========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /usr/jboss-5.1.0.GA
JAVA: /usr/java/jdk/bin/java
JAVA_OPTS: -Dprogram.name=run.sh -server -Xms128m -Xmx512m -
XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -
Dsun.rmi.dgc.client.gcInterval=3600000 -
Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -
Xdebug-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -
Djava.net.preferIPv4Stack=true
CLASSPATH: /usr/jboss-5.1.0.GA/bin/run.jar:/usr/java/jdk/lib/
tools.jar
=
========================================================================
22:50:15,825 INFO [ServerImpl] Starting JBoss (Microcontainer)...
...
22:53:29,933 INFO [ClasspathResourceConfig] Provider classes found:
22:53:33,927 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on
http-0.0.0.0-8080
22:53:33,950 INFO [AjpProtocol] Starting Coyote AJP/1.3 on
ajp-0.0.0.0-8009
22:53:34,021 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA
(build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 3m:18s:
169ms
Notice the JAVA and CLASSPATH are set...
But when I try to do this:
service jboss start
It breaks (and the JAVA and the CLASSPATH are not set with JAVA):
JAVAPTH /usr/java/jdk/bin/java
JAVA_HOME /usr/java/jdk
JAVA
CLASSPATH :/bin/run.jar:/usr/java/jdk/lib/tools.jar
Starting jboss..
=
========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /usr/jboss-5.1.0.GA
JAVA: java
JAVA_OPTS: -Dprogram.name=run.sh -Xms128m -Xmx512m -
XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -
Dsun.rmi.dgc.client.gcInterval=3600000 -
Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.bind.address=0.0.0.0 -
Xdebug-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -
Djava.net.preferIPv4Stack=true
CLASSPATH: /usr/jboss-5.1.0.GA/bin/run.jar
=
========================================================================
/usr/jboss-5.1.0.GA/bin/run.sh: line 261: java: command not found
(4) This code block here (line 261 in $JBOSS_HOME/bin/run.sh):
Code:
while true; do
if [ "x$LAUNCH_JBOSS_IN_BACKGROUND" = "x" ]; then
# Execute the JVM in the foreground
"$JAVA" $JAVA_OPTS \
-Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
-classpath "$JBOSS_CLASSPATH" \
org.jboss.Main "$@"
JBOSS_STATUS=$?
(5) Fortunately, I was able to issue these with chkconfig:
chkconfig --add jboss
chkconfig jboss on
(6) Created .bash_profile under root:
Code:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
if [ -f /root/firstlogin ] ; then
echo " --[ see /etc/ec2/release-notes ]--" && echo
rm -f /root/firstlogin
fi
# User specific environment and startup programs
export JAVA_HOME="/usr/java/jdk";
export JBOSS_HOME="/usr/jboss-5.1.0.GA";
export CLASSPATH=.:$JBOSS_HOME/bin/run.jar:$JAVA_HOME/lib/tools.jar;
PATH=$PATH:$JAVA_HOME/bin:$HOME/bin
export PATH
unset USERNAME
It seems that the environment is completely different (because java
unsets) when I run service jboss start opposed to doing it manually: /
etc/init.d/./jboss.
Does anyone know what I am possibly missing or doing wrong?
Would be very appreciative if someone could help...
16 years, 2 months
Verifier.jar in server module of AS
by Paul Gier
The server module of the app server currently generates a jar called
"verifier.jar" in trunk and in Branch_5_x. I can't find anywhere that this jar
is used. Anyone know if it is safe to remove this from the build?
Thanks!
16 years, 2 months
Infinispan configuration - all in one solution
by Vladimir Blagojevic
Recently, I was assigned to complete
https://jira.jboss.org/jira/browse/ISPN-97
The driving force behind this JIRA was to achieve a minimal maintenance
of Infinispan XML configuration. We have scarce resources but we needed
to: maintain professional looking HTML configuration reference, keep a
well documented XML schema for configuration files, and finally we
wanted to achieve seamless marshaling from XML configuration files into
configuration object model. Since configuration reference and schema
need to be generated for every release we wanted to completely automate
this process.
The obvious candidate library to achieve seamless unmarshalling of XML
configuration files into object model was either JAXB or JBossXB. We
wanted to keep our current configuration class hierarchy loosely coupled
with XML schema - i.e not every type in XML schema mapped into an
appropriate class in configuration hierarchy. In another words we wanted
to group configuration attributes into many XML elements but did not
want to have as many classes in our configuration class hierarchy. Any
solution to this problem, including JBossXB, requires maintenance of
mapping between XML schema types and our configuration class hierarchy.
Not a big problem, but this was a first hurdle in a serious of hurdles.
As any other HTML configuration reference Infinispan's should display
default values and their types, constraints for those values, human
readable descriptions and so on. If we were to generate configuration
reference automatically we needed to keep this information somewhere,
extract it, and spit it out. In JAXB/JBossXB based solution, the obvious
place to keep this information was in a "hand maintained" schema. But
schema, although it carries most of this information, is a blueprint, it
does not contain all instances of all possible configuration elements.
For example, our schema constrains that <loader> element has such and
such form but it does not document all the configuration options for all
possible loaders. The source code of those loader classes does! Another
problem with keeping documentation in hand maintained schema was that
all the information in schema was replicating what already existed in
the source code. We already had comments, attribute types and their
default values, they were already in the source. Why do we need to keep
a mirror of this data and then on top of it hand maintain it along with
a mapping from schema types to our configuration class hierarchy?
A proper solution for all of these minor issues, but issues that create
a lot of maintenance headache, lies in switching to the source code as
the main source of all information we need. What we had to do was to add
a bit of metadata in a form of annotations to complete everything. The
algorithm to unmarshall XML configuration file into object model is
about 300 lines of code [1], documentation [2] and schema generator [3]
around 200 each.
In conclusion, out of source code itself you automatically get a kick
ass configuration documentation reference, a well documented XML schema
and XML configuration unmarshalling into object model. All of this with
almost zero maintenance cost.
Yes, indeed, we are almost reinventing the wheel here but this is the
solution we need and we would gladly contribute to a project that does
exactly what we need. At the moment, I doubt that we can do this with
JBossXB, Alexey please correct me if I am wrong. Since we are already
having documentation reference maintenance problems in other projects
maybe we should somehow extend JBossXB with annotation based framework
and apply it in other projects as well?
Automatically generated configuration reference is included as
attachment. To view, download both stylesheet and config.html into a
local directory and open config.html in your favorite browser.
Regards,
Vladimir
[1]
http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/in...
[2]
http://anonsvn.jboss.org/repos/infinispan/trunk/tools/src/main/java/org/i...
[3]
http://anonsvn.jboss.org/repos/infinispan/trunk/tools/src/main/java/org/i...
16 years, 2 months
Rebuilding thirdparty jars with maven
by Paul Gier
There was some discussion recently on the Maven mailing list about synchronizing
artifacts between the jboss maven repository and the central maven repository
[1]. One of the main issues is how can we synchronize with the central
repository when we have rebuilt thirdparty artifacts that use the same groupId
and artifactId.
Currently, we publish rebuilt artifacts with a modified version number like
"1.1-brew", and then just update the POMs to point to that version. This
(usually) works nicely because Maven automatically excludes transitive
dependencies on other versions of this jar. But we can't push this back to the
central maven repository with the same groupId because it didn't come from the
upstream project. So the recommendation of some Maven developers is to change
the groupId (possibly prefix it with org.jboss for rebuilt thirdparty jars).
This would be a good practice for us except for the fact that Maven's dependency
management does not currently have a way to link together two groupId/artifactId
combinations to say that these are two versions of the same artifact. And that
would mean more even effort to exclude dependencies. But it might be our only
choice if we want to automatically sync with the central repository in the future.
[1] http://www.nabble.com/Depending-on-Artifacts-not-in-central-td24394458.html
16 years, 2 months
RFP-123: JAAS Integration
by Thomas Diesler
Hi Scott/Anil,
attached is document that is currently discussed by the OSGi EEG.
Perhaps you like to review and provide feedback that I can take with me
to the next F2F in Dublin (27-29,Jul-2009).
Especially Section 5 (Requirements) is where we ma be able to add JBoss
specific requirements.
cheers
-thomas
16 years, 2 months
