7.1.0. Beta Bug on CLI Authentication ?
by Francesco Marchioni
Hi all !
In the release notes it's mentioned that management interfaces will be
secured by default, however in the very first test I did, no authentication
was asked. (Although in the configuration there is a ManagementRealm
associated with the management interfaces).
Have I hit a bug ?
Regards
Francesco
13 years, 10 months
How to add a jar to classpath for all modules?
by Ondřej Žižka
Hi,
Hi, I'd like to add some jar to classpath in all AS modules; how can I
do that? (Except adding it to all mnodules.)
It's coverage report tool - Emma.
It would only be added for a custom run - hudson job.
Thanks,
Ondra
13 years, 10 months
Planed testsuite restructure
by Thomas Diesler
Done. However I don't think we can use your testsuite structure as it is
now. You keep the test sources in testsuite/integration/src but
introduce a number of new maven modules that refer to those sources.
This breaks maven convention and the IDE gets confused. The maven source
artefacts would also not contain the expected sources. If possible
please move the test sources to their respective modules.
If test sources really need to get shared between maven modules, you
could have a look at the demos. I believe those sources are reused by
the testsuite (at least in the past). Hence you could have a module
'testsuite/shared' or something similar.
cheers
-thomas
On 11/18/2011 09:46 AM, Thomas Diesler wrote:
> yes, I can do this today.
>
> On 11/18/2011 09:47 AM, Ondřej Žižka wrote:
>> Hi Thomas,
>>
>> could you please update the OSGi tests to use the jboss.ts.integ.dir
>> property instead of assuming it runs in testsuite/integration?
>> The working dir will change.
>> I'd change it myself but it's outside of AS project.
>>
>> Also, I need it get fixed to get the updated testsuite merged ASAP,
>> so I'd be very happy if you had a minute for this before monday.
>>
>> Thanks,
>> Ondra
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
13 years, 10 months
AS 7.1.0 : JDR Subsystem
by Vimal Kansal
I was just going through the the zip file generated by JDR subsystem and
just realised that it also packages the mgmt-users.properties file - I
wonder should that be the case, I mean why would a customer like to send
a list of configured users to Redhat support?
13 years, 10 months
Testsuite modularization? // Re: Testsuite refactor
by Ondřej Žižka
Hi,
1) Relevant resources:
Tracking jira: https://issues.jboss.org/browse/AS7-2007
Requirements: http://community.jboss.org/wiki/ASTestsuiteRequirements
Docs: https://docs.jboss.org/author/display/AS71/Testsuite
2) Modularization & moving the test sources
> This is one thing I am wondering. If we all agree that many smaller
modules is the way to go, since its the standard maven approach
(supported by all existing maven tools), and it solves that various
issues introduced by doing the grouping approach then maybe we should
just do one refactor instead of doing this one and refactoring it yet
again?
I'd like to see the problems with the solution in PR 710. Please send me
instructions how to check that the IDE has problems coping with test
sources on ../src/test/java.
(I don't know about Eclipse or IDEA, but NetBeans uses quite rational
approach, which is simply running Maven for the active module. Which
works.
It works for smoke, for -DallTests if you add that param, and also
when running a single test. I haven't tried debugging yet but in worst
case, I'd run with -Ddebug and attach the debugger.)
> I know you put a lot of effort into this, but there is a good chance
this may net less work in the end since we wont be constantly tweaking
this version.
It's not like switching from version A to B1 or B2, it's like staying
at B (pull request 710) or going further to C (which would be moving
sources to modules).
This harness is quite ready for both alternatives.
The reason I am proposing this as an intermediate state is, as I
previously stated, merely technical: Moving thousands of files is a big
operation from SCM PoV, so I want to get this tests relocation get
merged as quickly as possible - i.e. move, test, make pull request, get
it reviewed and merged, at best in a single day, otherwise I'll drown
with new tests coming.
> Or is there some set of requirements we have to meet ASAP that our
existing testsuite infrastructure doesnt cover?
There are many problems - I've mentioned them before - like:
* Smoke profile can either be default and need to be disabled
explicitely for any other group; but in that case many people will
forget to disable it which causes inference with other profiles.
Or it would have to be defined explicitely - i.e. "no smoke tests run
by default"
* Huge unmaintainable pom.xml
* Impossible to define multiple groups
* Hard to separate web/full or even make all tests run with full
Etc etc. See the resources above, and the issues discussed on as7 list
recently.
> Although the problem stuart brought up is that we can't have different
classpaths in a single testsrun.
> As an example compatibility tests would likley not be able to be ran
in this way.
Compat tests are in different module anyway. This change is refactoring
the integration module. The testsuite/pom.xml is affected too but only
slightly - properties etc.
Do/will the integration submodules need different classpath? BTW slight
differences could be handled by tweaking deps in profiles.
Regarding moving the test sources - is there anyone seeing any advantage
in having them all in testsuite/integration/src/test/java ? It looked
quite ellegant solution but if there's really no one liking it, let's
move it :)
3) Motivation driving the modularization
In general, I'd like to:
* Keep the number of modules at rational number - not fine-grained
(difficult pom.xml maintainance), but not keeping it all-in-one at all
costs (as it is now).
* Keep the pom.xml's easy to read and maintain - profiles interwoven
like a fancy bread isn't exactly something I'd like to add features to.
* Keep the pure maven api concise and locical. Please keep in mind that
some configs will need to be distributed across whole testsuite, and
_every_ config "axis" (databases, IPv6, security,...) will need to be
reflected in _every_ module. What's now few-lines pom.xml for each
module may become a big ball of mud, pulling in things from parent
pom.xml's.
I think we can agree on these right?
Regads,
Ondra
13 years, 10 months
7.1.0.Beta1 "Tesla" is live! [Startup issues]
by Reji Nair
Hi,
I get the following error when starting up the beta release in the
domain mode [nohup /opt/jboss-beta/bin/domain.sh
--domain-config=domain.conf -b `hostname` &]. The error occurs in the
host-controller boot.log:
07:41:19,615 ERROR [org.jboss.as.controller] (Controller Boot Thread)
JBAS014601: Error booting the container: java.lang.RuntimeException:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
JBAS014676: Failed to parse configuration
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControll
erService.java:189) [jboss-as-controller-7.1.0.Beta1.jar:]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
Caused by:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
JBAS014676: Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlCo
nfigurationPersister.java:125) [jboss-as-controller-7.1.0.Beta1.jar:]
at
org.jboss.as.host.controller.DomainModelControllerService.boot(DomainMod
elControllerService.java:305)
[jboss-as-host-controller-7.1.0.Beta1.jar:]
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControll
erService.java:183) [jboss-as-controller-7.1.0.Beta1.jar:]
... 1 more
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected
character '#' (code 35) in prolog; expected '<'
at [row,col {unknown-source}]: [1,1]
at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639
)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:
2017)
at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1102)
at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1125)
at
org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:57)
[staxmapper-1.0.0.Final.jar:]
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlCo
nfigurationPersister.java:117) [jboss-as-controller-7.1.0.Beta1.jar:]
... 3 more
Reji Nair
13 years, 10 months
cli: ls result changes
by Alexey Loubyansky
First of all, the results now include attributes in addition to node
names. E.g.
[domain@localhost:9999 /] ls
deployment extension
host interface
path profile
server-group socket-binding-group
system-property launch-type=DOMAIN
process-type=Domain Controller release-codename=Ahoy!
release-version=7.1.0.Alpha2-SNAPSHOT
Items w/o '=' are node names, those that include '=' are attribute
name/value pairs.
The effects of -l are now different as well. In addition to names and
values, properties from the model description are included as well. ATM,
all of the available properties are printed (except for the description,
because it gets too messy). Actually, it's messy w/o it, since there are
already too many properties and the terminal has to be wide enough to
not break the resulting table. E.g.
[domain@localhost:9999 /] ls -l
CHILD MIN-OCCURS MAX-OCCURS MODEL-DESCRIPTION
path 0 2147483647 {}
deployment 0 2147483647 {}
extension 0 2147483647 {}
host 0 2147483647 {}
interface 0 2147483647 {}
profile 1 2147483647 {}
server-group 0 2147483647 {}
socket-binding-group 0 2147483647 {}
system-property 0 2147483647 {}
ATTRIBUTE VALUE TYPE REQUIRED NILLABLE
MIN-LENGTH ALLOWED ACCESS-TYPE STORAGE
launch-type DOMAIN n/a n/a n/a n/a
n/a n/a n/a
process-type Domain Controller STRING true false 1
["Domain Controller","Host Controller"] read-only runtime
release-codename Ahoy! STRING true false 1
n/a read-only configuration
release-version 7.1.0.Alpha2-SNAPSHOT STRING true false 1
n/a read-only configuration
If due to email formatting the above doesn't look like a table, you can
try the command yourself. The changes were merged last night.
The headers are not hard-coded. They are taken from the model
description and capitalized. So, for another node the number of the
headers may be different and their order as well.
This is, obviously, too much info by default. Although, every bit has
its value. I think we should agree on which columns we want to see by
default and, perhaps, add switches to include others.
Another way would be to have a separate command to describe specific
attribute including all the properties from its model description.
We just discussed this with Emanuel and we think about limiting the
default info to the name, value and type. And have another command to
fully describe a specific attribute.
If anybody has suggestions regarding what info should be displayed by
default, in which format, etc, let's hear.
Thanks,
Alexey
13 years, 10 months
