Is @org.jboss.beans.metadata.api.annotations.Dependency being used?
by Kabir Khan
The intended use is :
@SecurityDomain(domain = "somedomain")
public class MyOwnDependency
{
}
where
@Dependency(name="domain", factory= SecurityDomainDependencyFactory.class)
public @interface SecurityDomain
{
String domain();
String securityManagerName() default "SecurityManager";
}
Meaning that the bean for MyOwnDependency gets a dependency on something called "somedomain", which is created by the SecurityDomainDependencyFactory. AOPDependencyBuilder currently does quite a bit of work looking for these (about 3.5% of default startup time), but I see Ales has done some work on a SecurityDomain annotation plugin which is plugged in as an annotation adapter, but that is only active in some tests.
AOPDependencyBuilder checks the class, and all methods for annotations with this, and I think this can probably be removed and replaced with a meta annotation plugin instead. The only issue with that is that the meta annotation plugins currently only work on class level. So before I try to change that, I want to make sure nobody is using it.
16 years, 1 month
Snapshots on trunk?
by Clebert Suconic
How this snapshot thing happens?
I have created a branch for my work on HornetQ's integration. I haven't
changed anything, however time to time things will stop working and I
have to change the classpath on the testsuite:
compile-annotated-classes-50:
[javac] Compiling 255 source files to
/work/as6/jboss-as-parent/testsuite/output/classes
BUILD FAILED
/work/as6/jboss-as-parent/testsuite/build.xml:723: Reference
javax.faces:jsf-api:jar not found.
that means... once I make a branch, I can't guarantee it will build
tomorrow because of the snapshot changes and dependencies?
I thought this issue was solved
16 years, 2 months
[JBoss-dev] Please HELP - Perpetual 404 errrors
by savoym
I am hoping that someone on this list can help me resolve my JBoss issue. I
am in a predicament whereby our lead who had setup our JBoss configuration
within Eclipse left the company and unfortunately it was not communicated or
documented how JBoss within Eclipse was configured or at least that we can
find. Now we have an issue where JBoss still comes up successfully within
Eclipse but when we try to execute our URL within IE we are getting
perpetual HTTP 404 errors. We are using JBoss 4.0.5GA and Eclipse 3.5 SR1
(latest version). In talking to others on coderanch and other lists I was
told to check and make sure that my EAR file is in the DEPLOY folder of my
server and that within the EAR that the WAR file exists. I did check both
items and they did exist. I did want to say that within our dynamic web
project that the context root is defined as SCM and therefore the URL that
I'm using is: http://localhost:8080/SCM/ If I just enter
http://localhost:8080/ then I just get to the JBoss default screen that has
2 sections: JBoss Online Resources and JBoss Management. I have checked
per others that my EAR file is listed in the jboss.j2ee section of the JMX
console which it is:
jboss.j2ee
service=ClientDeployer
service=EARDeployer
service=EARDeployment,url='SCMWebEAR.ear'
I have no idea where to go from here. This is only happening on my local
box. Here is the log from the console in Eclipse and any help or time that
anyone on this list can spare to look at this issue would be greatly
appreciated, regards:
[code]
10:22:23,397 INFO [Server] Starting JBoss (MX MicroKernel)...
10:22:23,397 INFO [Server] Release ID: JBoss [Zion] 4.0.5.GA (build:
CVSTag=Branch_4_0 date=200610162339)
10:22:23,397 INFO [Server] Home Dir: C:\server\jboss-4.0.5
10:22:23,397 INFO [Server] Home URL: file:/C:/server/jboss-4.0.5/
10:22:23,397 INFO [Server] Patch URL: null
10:22:23,397 INFO [Server] Server Name: default
10:22:23,397 INFO [Server] Server Home Dir:
C:\server\jboss-4.0.5\server\default
10:22:23,397 INFO [Server] Server Home URL:
file:/C:/server/jboss-4.0.5/server/default/
10:22:23,397 INFO [Server] Server Log Dir:
C:\server\jboss-4.0.5\server\default\log
10:22:23,397 INFO [Server] Server Temp Dir:
C:\server\jboss-4.0.5\server\default\tmp
10:22:23,397 INFO [Server] Root Deployment Filename: jboss-service.xml
10:22:23,756 INFO [ServerInfo] Java version: 1.6.0_13,Sun Microsystems Inc.
10:22:23,756 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM
11.3-b02,Sun Microsystems Inc.
10:22:23,756 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
10:22:24,881 INFO [Server] Core system initialized
10:22:26,568 INFO [WebService] Using RMI server codebase:
http://THRCNU9151CJ6:8083/
10:22:26,584 INFO [Log4jService$URLWatchTimerTask] Configuring from URL:
resource:log4j.xml
10:22:31,459 INFO [ServiceEndpointManager] WebServices: jbossws-1.0.3.SP1
(date=200609291417)
10:22:32,849 INFO [Embedded] Catalina naming disabled
10:22:32,881 INFO [ClusterRuleSetFactory] Unable to find a cluster rule set
in the classpath. Will load the default rule set.
10:22:32,881 INFO [ClusterRuleSetFactory] Unable to find a cluster rule set
in the classpath. Will load the default rule set.
10:22:33,146 INFO [Http11BaseProtocol] Initializing Coyote HTTP/1.1 on
http-0.0.0.0-8080
10:22:33,146 INFO [Catalina] Initialization processed in 265 ms
10:22:33,146 INFO [StandardService] Starting service jboss.web
10:22:33,146 INFO [StandardEngine] Starting Servlet Engine: Apache
Tomcat/5.5.20
10:22:33,177 INFO [StandardHost] XML validation disabled
10:22:33,177 INFO [Catalina] Server startup in 31 ms
10:22:33,349 INFO [TomcatDeployer] deploy, ctxPath=/invoker,
warUrl=.../deploy/http-invoker.sar/invoker.war/
10:22:33,584 INFO [WebappLoader] Dual registration of jndi stream handler:
factory already defined
10:22:33,834 INFO [TomcatDeployer] deploy, ctxPath=/,
warUrl=.../deploy/jbossweb-tomcat55.sar/ROOT.war/
10:22:34,162 INFO [TomcatDeployer] deploy, ctxPath=/jbossws,
warUrl=.../tmp/deploy/tmp827016215842094482jbossws-context-exp.war/
10:22:34,271 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil,
warUrl=.../deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
10:22:34,974 INFO [TomcatDeployer] deploy, ctxPath=/web-console,
warUrl=.../deploy/management/console-mgr.sar/web-console.war/
10:22:35,490 INFO [MailService] Mail Service bound to java:/Mail
10:22:35,787 INFO [RARDeployment] Required license terms exist, view
META-INF/ra.xml in .../deploy/jboss-ha-local-jdbc.rar
10:22:35,834 INFO [RARDeployment] Required license terms exist, view
META-INF/ra.xml in .../deploy/jboss-ha-xa-jdbc.rar
10:22:35,896 INFO [RARDeployment] Required license terms exist, view
META-INF/ra.xml in .../deploy/jboss-local-jdbc.rar
10:22:35,959 INFO [RARDeployment] Required license terms exist, view
META-INF/ra.xml in .../deploy/jboss-xa-jdbc.rar
10:22:36,146 INFO [RARDeployment] Required license terms exist, view
META-INF/ra.xml in .../deploy/jms/jms-ra.rar
10:22:36,177 INFO [RARDeployment] Required license terms exist, view
META-INF/ra.xml in .../deploy/mail-ra.rar
10:22:37,302 INFO [WrapperDataSourceService] Bound ConnectionManager
'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name
'java:DefaultDS'
10:22:37,521 INFO [A] Bound to JNDI name: queue/A
10:22:37,521 INFO [B] Bound to JNDI name: queue/B
10:22:37,521 INFO [C] Bound to JNDI name: queue/C
10:22:37,521 INFO [D] Bound to JNDI name: queue/D
10:22:37,521 INFO [ex] Bound to JNDI name: queue/ex
10:22:37,537 INFO [testTopic] Bound to JNDI name: topic/testTopic
10:22:37,537 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
10:22:37,537 INFO [testDurableTopic] Bound to JNDI name:
topic/testDurableTopic
10:22:37,537 INFO [testQueue] Bound to JNDI name: queue/testQueue
10:22:37,584 INFO [UILServerILService] JBossMQ UIL service available at :
/0.0.0.0:8093
10:22:37,615 INFO [DLQ] Bound to JNDI name: queue/DLQ
10:22:37,787 INFO [ConnectionFactoryBindingService] Bound ConnectionManager
'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name
'java:JmsXA'
10:22:37,880 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console,
warUrl=.../deploy/jmx-console.war/
10:22:38,021 INFO [EARDeployer] Init J2EE application:
file:/C:/server/jboss-4.0.5/server/default/deploy/SCMWebEAR.ear
10:22:42,646 WARN [TomcatDeployer] Failed to map vhost: scmis
10:22:42,646 INFO [TomcatDeployer] deploy, ctxPath=/,
warUrl=.../tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/
10:22:42,662 INFO [StandardHost] XML validation disabled
10:22:43,193 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to Configuration
10:22:43,208 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to ActionResolver
10:22:43,224 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scm/stripes/]
matching criteria: is assignable to ActionBean
10:22:43,286 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/]
matching criteria: is assignable to ActionBean
10:22:43,365 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to ActionBeanPropertyBinder
10:22:43,365 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to ActionBeanContextFactory
10:22:43,380 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to ActionBeanContext
10:22:43,380 INFO [BootstrapPropertyResolver] Class implementing/extending
ActionBeanContext found via auto-discovery:
org.texashealth.scmis.stripes.ext.SCMISActionBeanContext
10:22:43,380 INFO [DefaultActionBeanContextFactory]
DefaultActionBeanContextFactory will use ActionBeanContext subclass
org.texashealth.scmis.stripes.ext.SCMISActionBeanContext
10:22:43,380 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to TypeConverterFactory
10:22:43,396 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to LocalizationBundleFactory
10:22:43,396 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to LocalePicker
10:22:43,396 INFO [DefaultLocalePicker] No locale list specified,
defaulting to single locale: en_US
10:22:43,396 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to FormatterFactory
10:22:43,411 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to TagErrorRendererFactory
10:22:43,427 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to TagErrorRenderer
10:22:43,427 INFO [BootstrapPropertyResolver] Class implementing/extending
PopulationStrategy found in web.xml:
net.sourceforge.stripes.tag.BeanFirstPopulationStrategy
10:22:43,427 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to ExceptionHandler
10:22:43,427 INFO [BootstrapPropertyResolver] Class implementing/extending
ExceptionHandler found via auto-discovery:
org.texashealth.scmis.stripes.ext.SCMISExceptionHandler
10:22:43,521 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to MultipartWrapperFactory
10:22:43,521 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to MultipartWrapper
10:22:43,536 INFO [DefaultMultipartWrapperFactory] Using
net.sourceforge.stripes.controller.multipart.CosMultipartWrapper as
MultipartWrapper implementation.
10:22:43,536 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to ValidationMetadataProvider
10:22:43,552 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to Interceptor
10:22:43,552 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to Formatter
10:22:43,552 INFO [ResolverUtil] Scanning for classes in
[/C:/server/jboss-4.0.5/server/default/./tmp/deploy/tmp5248025188667996173SCMWebEAR.ear-contents/SCM-exp.war/WEB-INF/classes/org/texashealth/scmis/stripes/ext/]
matching criteria: is assignable to TypeConverter
10:22:43,552 INFO [StripesFilter] Stripes Initialization Complete. Version:
1.5, Build: 955
10:22:43,568 INFO [EARDeployer] Started J2EE application:
file:/C:/server/jboss-4.0.5/server/default/deploy/SCMWebEAR.ear
10:22:43,630 INFO [Http11BaseProtocol] Starting Coyote HTTP/1.1 on
http-0.0.0.0-8080
10:22:43,693 INFO [ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
10:22:43,708 INFO [JkMain] Jk running ID=0 time=0/31 config=null
10:22:43,708 INFO [Server] JBoss (MX MicroKernel) [4.0.5.GA (build:
CVSTag=Branch_4_0 date=200610162339)] Started in 20s:311ms
[/code]
--
View this message in context: http://old.nabble.com/Please-HELP---Perpetual-404-errrors-tp27550790p2755...
Sent from the JBoss - Dev mailing list archive at Nabble.com.
16 years, 2 months
AS trunk boot time back to poor?
by Jaikiran Pai
After today's "svn up" of my workspace, i see that the "default"
instance boot in around 48 to 50 seconds:
19:10:18,431 INFO [org.jboss.bootstrap.impl.base.server.AbstractServer]
JBossAS [6.0.0.SNAPSHOT (build: SVNTag=JBoss_6.0.0-SNAPSHOT
date=r99718)] Started in 48s:36ms
The only noticeable change that i have seen is related to admin-console
being included in AS trunk. So i removed the admin-console.war from the
deploy folder and the server boots in 23 to 25 seconds. Adding it back
to deploy folder takes the boot time to 48 to 50 seconds consistently. I
haven't yet looked at where the time is being spent for deploying this
single app. But clearly it increases the boot time by almost 25 seconds.
Anyone else seeing this drastic change in boot time?
regards,
-Jaikiran
16 years, 2 months
[Fwd: Small boottime improvement]
by Dimitris Andreadis
> One strange thing is that the first time I started each server they took loads longer
than > the other times, does somebody know the reason for that?
Filesystem caching?
16 years, 2 months
AS testsuite - Adding an "excludes" patternset to run-junit target
by Juraci Paixao Krohling
Guys,
As this may affect you, I'm wondering if you see any problems in adding
an "excludes" patternset to the run-junit macro, in
testsuite/imports/server-config.xml (around line 1535, based on branch
EWP_5_0 code, which will be probably backported to JBPAPP_5_0 branch and
trunk).
It should have minimum effect to the existing tests, as most of the
callers of the macro "run-junit" aren't using tests currently listed in
badtest.excludes.
My motivation behind this change is that some components were removed
from EWP, causing other a lot of tests to fail. So, the testsuite will
be adjusted to add tests to "badtest.excludes" if it detects it's
running against EWP.
It shouldn't wrongly affect any test, as my understanding is that those
"final" patternsets should incorporate the badtest.excludes, but a lot
of the ones which calls the macro "run-junit" doesn't includes that.
If you see any problem with that, please let me know.
- Juca.
diff:
Index: imports/server-config.xml
===================================================================
--- imports/server-config.xml (revision 99596)
+++ imports/server-config.xml (working copy)
@@ -1533,6 +1533,7 @@
<fileset dir="${build.classes}">
<patternset refid="@{junit.patternset}"/>
+ <patternset refid="badtest.excludes"/>
</fileset>
</batchtest>
</junit>
16 years, 2 months
M2 Cutoff Tomorrow
by Brian Stansberry
Just a reminder that the code cutoff for AS 6.0.0.M2 is 1 PM EST
tomorrow. Please get any issues resolved by then. The latest AS
testsuite run[1] only showed one failure, which is being addressed, so
please keep things stable.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
16 years, 2 months
Re: [jboss-dev] compareAndSet variation
by Andrew Dinn
On 02/10/2010 03:40 PM, David M. Lloyd wrote:
> This doesn't really make any sense - you're saying if the value is
> different, return the delta and leave the value unchanged, but if the
delta
> was zero between the expect and update, then the value wouldn't need
> changing anyway! You can do that with just a read.
I agree the request is not clear but I think I understand what is being
asked for. Assuming this is a methof of AtomicLong which has a long
field called 'value' what would make sense would be:
int compareAndSet(long expected, long new)
atomic {
if value == expected {
value = new;
return 0;
else
return value - expected;
endif
}
or, equivalently, in a form which clarifies the motive for the request:
int compareAndSet(long expected, long new)
atomic {
int result = value - expected;
if (result == 0) {
value = new
endif
return result;
}
In other words can the update be conditional on the outcome of a
subtract returning zero while the operation returns the value of the
subtract operation whether or not the update occurs? This makes clear
the difference form a normal CAS
boolean compareAndSet(long expected, long new)
atomic {
boolean result = (value != expected);
if (!result) {
value = new
endif
return result;
}
Well, you could always implement this using conventional locking (which
you can already do anyway) but you could not implement it using either a
conventional hardware CAS instruction or LOAD_LINK STORE_CONDITIONAL
pair. These only output a true or false result. So, when they succeed
you know what the result of the subtract would be (zero) but when they
fail you don't have enough information to identify the result as it was
at the point where the check failed. n.b. reading value before or after
trying an update with the CAS/LOAD_L-STORE_C is no good as the value is
volatile. For example, reading after the CAS failed risks returning zero
if some other thread updates the value to expected between the CAS and
the read without actually updating value to new.
Building hardware which returned a difference rather than a boolean
would be quite simple to do but no one has -- and almost certainly for
good reasons. Since the updated value is by definition volatile the
result of the subtraction is probably of no more use to you than the
boolean result. If it is zero it tells you the value was as you expected
and your update succeeded. If it is non-zero then you would need some
very clever scheme to be usefully employ the result.
For example, imagine every thread which used this operation employed a
unique positive integer as a lock value with 0 used to mean that the
location was not locked. Supplying 0 as the expected value when
attempting a lock operation would allow a non-zero return value to
identify the lock owner _at the time of the lock attempt_. That might be
useful as a way of chasing round locking threads but its utility is
mitigated by the fact that the lock owner could transfer ownership
immediately after the lock attempt. One possibility might be, say, to
use the return value to order the failed thread in some sort of wait
queue associated with the locked location, but it's not clear to me how
you could make that work effectively.
n.b. Apologies for mixing Tim Harris's Java atomic syntax with C addressing.
regards,
Andrew Dinn
-----------
16 years, 2 months
compareAndSet variation
by Vladimir Blagojevic
Hi,
Not sure if there are any concurrency enthusiasts here but I'll give it a shot :)
Would it be possible to make a lock-free, thread safe structure that would essentially retain "boolean compareAndSet(long expect,long update)" semantics but instead of returning boolean would return delta between actual underlying value and update value? Delta of zero would therefore mean that value has been set.
Vladimir
16 years, 2 months
