RE: jboss-head-jdk-matrix Build Failed
by Darran Lofthouse
Looks like the class org.jboss.ejb3.timerservice.TimerServiceImpl needs
to be added to the repository, or TimerServiceFactory needs updating to
use the one under quartz.
Regards,
Darran Lofthouse.
________________________________
From: qa(a)jboss.com [mailto:qa@jboss.com]
Sent: 23 August 2006 16:41
To: alex.loubyansky(a)jboss.com; Darran Lofthouse;
jboss-development(a)lists.jboss.org; QA; wolfc(a)jboss.com
Subject: jboss-head-jdk-matrix Build Failed
Importance: High
View results here ->
http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log
=log20060823101013
BUILD FAILED
Ant Error Message:
/services/cruisecontrol/work/scripts/build-jboss-common.xml:297: The
following error occurred while executing this line:
/services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit
code: 1 See compile_jdk15.log in Build Artifacts for details.
Date of build: 08/23/2006 10:10:13
Time to build: 30 minutes 10 seconds
Last changed: 08/23/2006 09:58:49
Last log entry: Update project name to match folder name.
Unit Tests: (0) Total Errors and Failures: (0)
Modifications since last build: (first 50 of 46)
56178
modified
darran.lofthouse(a)jboss.com
//trunk/admin-console/.project
Update project name to match folder name.
56176
modified
wolfc
//trunk/ejb3/src/resources/test-configs/ejb3-jacc/deploy/jbossweb-tomcat
6.sar/META-INF/jboss-service.xml
AuthorizationManager from JNDI (see JBAS-3535)
56171
modified
alex.loubyansky(a)jboss.com
//trunk/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/EJBQLToSQL92Compi
ler.java
JBAS-3541
56171
modified
alex.loubyansky(a)jboss.com
//trunk/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/QueryParameter.ja
va
JBAS-3541
56171
modified
alex.loubyansky(a)jboss.com
//trunk/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCEJBQLCompiler
.java
JBAS-3541
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/main/org/jboss/test/cmp2/jbas3541/ABean.java
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/main/org/jboss/test/cmp2/jbas3541/IntJDBCAdaptor.j
ava
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/main/org/jboss/test/cmp2/jbas3541/JBAS3541UnitTest
Case.java
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/resources/cmp2/jbas3541/META-INF/ejb-jar.xml
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/main/org/jboss/test/cmp2/jbas3541/ALocal.java
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/resources/cmp2/jbas3541/META-INF/jboss.xml
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/resources/cmp2/jbas3541/META-INF/jbosscmp-jdbc.xml
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/main/org/jboss/test/cmp2/jbas3541
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/resources/cmp2/jbas3541
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/resources/cmp2/jbas3541/META-INF
JBAS-3541 testcase
56170
modified
alex.loubyansky(a)jboss.com
//trunk/testsuite/imports/sections/cmp.xml
JBAS-3541 testcase
56170
added
alex.loubyansky(a)jboss.com
//trunk/testsuite/src/main/org/jboss/test/cmp2/jbas3541/ALocalHome.java
JBAS-3541 testcase
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/QuartzTimerServ
iceFactory.java
EJBTHREE-619: timer service factory configurable
56169
unknown
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/TimedObjectInvoker.jav
a
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/PersistentTimer
.java
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/TimerImpl.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/jmx/EJB3TimerSe
rvice.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/jmx/EJB3TimerSe
rviceMBean.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/resources/standalone/embedded-jboss-beans.xml
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/jboss
EJBTHREE-619: timer service factory configurable
56169
deleted
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/PersistentTimer.java
EJBTHREE-619: timer service factory configurable
56169
deleted
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/TimerImpl.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/service/ServiceContainer.java
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/package.html
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/jmx
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/jboss/TimerServiceFaca
de.java
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/QuartzTimerJob.
java
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/quartz/TimerServiceImp
l.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/resources/ejb3-timer-service.xml
EJBTHREE-619: timer service factory configurable
56169
added
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/jboss/JBossTimerServic
eFactory.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/.classpath
EJBTHREE-619: timer service factory configurable
56169
deleted
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/jmx
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/stateless/StatelessContainer.java
EJBTHREE-619: timer service factory configurable
56169
modified
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/mdb/MessagingContainer.java
EJBTHREE-619: timer service factory configurable
56169
deleted
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/QuartzTimerJob.java
EJBTHREE-619: timer service factory configurable
56169
deleted
wolfc
//trunk/ejb3/src/main/org/jboss/ejb3/timerservice/TimerServiceImpl.java
EJBTHREE-619: timer service factory configurable
56168
added
wolfc
//trunk/ejb3/src/test/org/jboss/ejb3/test/timer/TransactionalTimerTester
Bean.java
EJBTHREE-400: testing
56168
modified
wolfc
//trunk/ejb3/src/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.
java
EJBTHREE-400: testing
56168
modified
wolfc
//trunk/ejb3/src/test/org/jboss/ejb3/test/timer/TimerTester.java
EJBTHREE-400: testing
56168
modified
wolfc
//trunk/ejb3/src/test/org/jboss/ejb3/test/timer/BaseTimerTesterBean.java
EJBTHREE-400: testing
20 years
Build broken?
by Adrian Brock
Jean Fredric just showed me where the latest build
is trying to download repository jars into the wrong place.
e.g. He has libs getting downloaded into
~/thirdparty
when it should be
~/jbossas/thirdparty
I haven't tried it myself, but I think is probably due to Ruel's change
last Friday WRT to the / and - handling in path names.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
20 years
RE: [JBoss-dev] Open type not working in jboss-head eclipse project?
by Darran Lofthouse
I had a similar problem.
For me it was because I killed Eclipse for taking too long when I
initially imported the projects, removing all of the projects and adding
them again (but this time letting eclipse refresh and build everything)
fixed this for me.
Regards,
Darran Lofthouse.
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: 22 August 2006 02:50
To: JBoss.org development list
Subject: [JBoss-dev] Open type not working in jboss-head eclipse
project?
For some reason when I do a type search (Ctrl-Shift-T) in the jboss-head
trunk project, its not finding many types(ServiceController for
example). Any idea why this would not be working?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
20 years
jboss as full distro in repo
by Tom Baeyens
i can only find one at http://repository.jboss.com/jbossas/4.0.4.GA/lib/
called jbossas-repo.zip
the strange thing about this distro is that it doesn't have the usual
default/all/minimal configuration directories in the server directory.
instead, the conf and deploy dirs are straight under the server
directory. afaict, it is an all configuration that is under the server
dir.
can i upload normal jboss as distros for versions 4.0.3.SP1 and 4.0.4.GA
to the repository ?
regards, tom.
20 years
RE: [JBoss-dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossAS 5.0.0 Beta
by Jason T. Greene
Actually looking at it in more depth, it can't be done without some kind
of post cleanup which would be overkill. So nevermind :)
-Jason
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-
> bounces(a)lists.jboss.org] On Behalf Of Jason T. Greene
> Sent: Thursday, August 17, 2006 7:22 PM
> To: JBoss.org development list
> Subject: RE: [JBoss-
>
dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossA
S
> 5.0.0 Beta
>
> > 2) Jason, are you proposing that if Controller unregisters an MBean
it
> > didn't register, it should complain a bit (i.e. log a WARN or
> > something)?
>
> Yes, because in theory we would be able to drop the unregister code
from
> controller once people are given enough time to fix their code.
>
> > -----Original Message-----
> > From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-
> > bounces(a)lists.jboss.org] On Behalf Of Brian Stansberry
> > Sent: Thursday, August 17, 2006 2:42 PM
> > To: JBoss.org development list
> > Subject: RE: [JBoss-
> >
>
dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBoss
> AS
> > 5.0.0 Beta
> >
> > I think my 'Mom' analogy was a bad idea, as I'm losing track of the
> real
> > meaning of the conversation :) My post was that way too.
> >
> > 1) Having the new implementation clean up after people is good. I
> > didn't mean to imply it wasn't.
> > 2) Jason, are you proposing that if Controller unregisters an MBean
it
> > didn't register, it should complain a bit (i.e. log a WARN or
> > something)?
> > 3) IMHO having EjbModule call registerMBean and then not clean up
> after
> > itself is bad. Does anyone who is more familiar with EJB 2
> deployments
> > see any reason not to call unregisterMBean() in
> > EjbModule.destroyService()? (Harder alternative is figure out how to
> get
> > rid of the registerMBean call in createService()).
> >
> > I'll shut up now; probably this is something that will be sorted as
> part
> > of updating the deployers. My concern was getting the HA-JNDI unit
> test
> > working, which Adrian kindly did :)
> >
> > jboss-development-bounces(a)lists.jboss.org wrote:
> > > Right, so why don't we complain if they don't clean up after
> > > themselves, and then clean up for them? Just like Mom does.
> > >
> > >> -----Original Message-----
> > >> From: jboss-development-bounces(a)lists.jboss.org
> > >> [mailto:jboss-development- bounces(a)lists.jboss.org] On Behalf Of
> > >> Brian Stansberry
> > >> Sent: Wednesday, August 16, 2006 11:20 AM
> > >> To: JBoss.org development list
> > >> Subject: RE: [JBoss-
> > >> dev]InstanceAlreadyExistsExceptionafterundeployandrepeated
deployin
> > >> JBoss AS 5.0.0 Beta
> > >>
> > >> jboss-development-bounces(a)lists.jboss.org wrote:
> > >>> On Wed, 2006-08-16 at 15:49 +0200, Adrian Brock wrote:
> > >>>> Also, this change causes "problems" for web deployments (looks
> like
> > >>>> they being unregistered from the MBeanServer rather than being
> > >>>> removed from the ServiceController?):
> > >>>>
> > >>>
> > >>> Yep. And I've fixed this as well.
> > >>
> > >> So, before ServiceController.remove() was cleaning up after
people,
> > >> and now the new implementation is again. And you just fixed an
> > >> issue where it would complain if people had already cleaned up
> after
> > >> themselves :)
> > >>
> > >> If need be my mom used to clean up after me, but she also trained
> me
> > >> to clean up after myself (well, kinda). So, seems like if
> > >> EjbModule.createService() is going to call registerMBean(),
> > >> EjbModule.destroyService() should call unregisterMBean().
> > >>
> > >> Brian Stansberry
> > >> Lead, AS Clustering
> > >> JBoss, a division of Red Hat
> > >> Ph: 510-396-3864
> > >> skype: bstansberry
> > >>
> > >> _______________________________________________
> > >> jboss-development mailing list
> > >> jboss-development(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/jboss-development
> > >
> > > _______________________________________________
> > > jboss-development mailing list
> > > jboss-development(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> >
> >
> > Brian Stansberry
> > Lead, AS Clustering
> > JBoss, a division of Red Hat
> > Ph: 510-396-3864
> > skype: bstansberry
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
20 years
AbstractKernelController behavior inconsistent
by Anil Saldhana
Hi,
There seems to be an inconsistent behavior in the
AbstractKernelController.
My test case code:
========================================================================
=
prepareTestDynamicLoginConfig(server,
new ObjectName("jboss:service=TestDynamicLoginConfig"),
null);
try
{
server.invoke(serviceOName,"create", new Object[0], new
String[0]);
server.invoke(serviceOName,"start", new Object[0], new
String[0]);
fail("Service should not have started");
}
catch(Throwable t)
{
log.debug("Service has rightly disagreed to start",t);
}
========================================================================
Is failing now because the MC instead of throwing an exception(unable to
start a service), is only logging the error as follows:
------------------------------------------------------------------
14:50:19,015 ERROR [AbstractKernelController] Error installing to Start:
name=jb
oss:service=TestDynamicLoginConfig state=Create mode=Manual
requiredState=Installed
java.lang.IllegalStateException: AuthConfig is defaulting to
conf/login-config.xml. Please check your archive.
at
org.jboss.security.auth.login.DynamicLoginConfig.validateAuthConfigUR
L(DynamicLoginConfig.java:271)
at
org.jboss.security.auth.login.DynamicLoginConfig.startService(Dynamic
LoginConfig.java:219)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:289)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
...
...org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at
org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java
:167)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installActio
n(StartStopLifecycleAction.java:42)
at
org.jboss.system.microcontainer.ServiceControllerContextAction.instal
l(ServiceControllerContextAction.java:46)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install
(AbstractControllerContextActions.java:51)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(Abstra
ctControllerContext.java:226)
-----------------------------------------------------------------
Please advice on this inconsistent behavior.
Regards,
Anil
20 years
