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
16 years
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, 1 month
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, 2 months
Endpoint.publish() dependency question
by Richard Opalka
Hi Everybody,
who's using webservices Endpoint.pubish() in its JBoss subproject?
Thanks,
Richard
--
Richard Opalka
JBoss Software Engineer
Mail: ropalka(a)redhat.com
Mobile: +420 731 186 942
16 years, 4 months
jbossas -beans.xml opt
by Ales Justin
I'm looking for volunteers or the people responsible for the existing
-jboss-beans.xml files in jbossas. :-)
The reason is a new way to optimize boot time a bit.
We have two new annotations we can add to our beans.
(1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
This one takes two attributes:
(a) Class<? extends Annotation>[] value() default {};
(b) boolean ignore() default false
With (a) you can provide a set of annotation classes that might be used
on your bean/class to use MC's IoC.
e.g. @org.jboss.beans.metadata.api.annotations.Inject
Only matching plugins will be then used, instead of all.
With (b) you can simply say ignore any @annotation MC IoC lookup.
This is probably mostly true for all beans.
(2) @org.jboss.aop.microcontainer.annotations.DisableAOP
This one instructs MC to ignore transparent AOP usage when handling your
bean.
It will not look for aspect dependencies or try to create an AOP proxy.
It will simply fall back to plain POJO handling.
If you use @JMX or anything similar, this should then *not* be used.
But for anything else it should be good to use it.
How to use this?
(a) either annotate your service/bean classes
(b) simply use xml way of annotating your beans
e.g.
<annotation>@org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
<annotation>@org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
(c) if you know that none of your beans in <deployment> (-beans.xml
file) uses any of the needed features,
you can simply add xml way to the <deployment> element.
This way all beans inherit the annotation from deployment.
So, let's get busy "annotating" those jbossas beans. ;-)
ps: how should we proceed with this? :-)
16 years, 4 months
Watching the AS TestSuite
by Andrew Lee Rubinger
The AS TestSuite in trunk has again gotten out of line. I've got a
4100+ line patch coming in, and need to be able to spot potential
regressions reliably.
We need to stress the importance of checking up on your commits to
ensure they don't bring the house down. Would like to see:
1) More self-imposed responsibility, looking after the builds in Hudson
if you've made commits to trunk recently
2) More rollbacks / notices in case of regression. "Hey Jim you broke
it fix it. Love, Me".
3) Maybe an appointed "watchdog" each week to act as TestSuite
gatekeeper in case 1 and 2 /fail.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
16 years, 4 months
X2JB - The Excellent Java Tool
by Richard Opalka
Hi Everybody,
are you missing extremely simple but powerful configuration tool for
your (sub)project?
Are your configurations stored in XML files and you just need to read them
and create the meta data model from it?
Then you should have a look to X2JB 2.0 ( http://x2jb.sourceforge.net/ )
Once you'll try it, you'll never want to return back to your old
configuration approach ;)
Cheers,
Richard
--
Richard Opalka
JBoss Software Engineer
Mail: ropalka(a)redhat.com
Mobile: +420 731 186 942
16 years, 4 months
Startup time for LongRunningTasksThreadPool in trunk
by Brian Stansberry
Copying jboss-dev.
This is a simple dependency issue. Within the timings Scott is seeing
for the LongRunningTasksThreadPool are the create and start phases of
not-yet-installed deployments that depend on it. The JChannelFactory
bean in the jgroups-channelfactory.sar is one such. The HAPartition bean
depends on that. And it connects a JGroups channel, which uses multicast
to discover other available servers. On the first couple servers in a
group that discovery takes 2 seconds. Plus there's a bunch of other
services that depend on HAPartition and start when it does.
For AS 6 I want to make the HAPartition an on-demand service, which will
push this cost off onto whoever actually uses it. Parallel deployment
will also help, since most of the time HAPartition is starting it's just
blocking waiting for a response to its discovery packet.
The overall ~3.5 secs Scott's report shows for all this also seems high.
There's a fairly expensive JBoss Cache initialization in there that
seems to be happening twice; I need to understand why.
For understanding DefaultDS, suggest you look at what depends on it in
the all config that doesn't in the default config. Most likely the
difference in deployment time is simply the time it takes to deploy
other stuff. Perhaps JBM??? It would take a lot longer in "all" as in
clustered mode it connects 2 JGroups channels with a 2 sec discovery
phase for each -- until the AS moves to JBM 2 at which time JBM won't
use JGroups.
The jgroups-channelfactory.sar itself has no relationship to DefaultDS.
-Brian
Jaikiran Pai wrote:
> Scott Marlow wrote:
>>
>>
>> It looks like the 3.5 seconds to boot the LongRunningTasksThreadPool
>> is attributed to jgroups-channelfactory.sar (brought in for JBoss
>> Cache + DistributedState).
> That's strange, because these two seem to be independent deployments (no
> dependency either). So while installing LongRunningTasksThreadPool we
> ideally shouldn't have seen any other deployments affecting its timings.
> But this does seem to be the likely cause and it explains why the
> LongRunningTasksThreadPool boots faster (as reported by the deployer
> timings) in the "default" profile where the jgroups-channelfactory.sar
> is not present.
>
> There are other deployments (like the DefaultDS in hsqldb-ds.xml) which
> take significantly large time compared to the time in the "default"
> profile. Probably those too are affected by the jgroups-channelfactory.sar?
>
> -Jaikiran
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
16 years, 4 months
