Minutes: Consolidate Arquillian test infrastructure
by Thomas Diesler
Folks,
here a summary of what we talked about in our weekly call:
What happened since the last call
---------------------------------
- Aslak released ARQ Core Beta1
- Thomas replaced the ARQ subsystem by an on-demand deployment (AS7-773
<https://issues.jboss.org/browse/AS7-773>)
- Andrew worked on porting some of the ARQ tests to Beta1
What is next
------------
- Andrew + Thomas work on branch as773
<https://github.com/tdiesler/jboss-as/tree/as773> to port the ARQ
on-demand deployment to Beta1
- We focus on the managed container. The embedded and remote containers
can be revisited later
- All smoke and integration tests in branch as773 run agains the manged
container already
- Tests that cannot be migrated easily can be @Ignored and captured as
subtasks to AS7-734 <https://issues.jboss.org/browse/AS7-734>
Goal is to have an on-demand ARQ deployment based on Beta1 that provides
the server side test infrastructure. We are done when we have a large
portion of existing test run against the consolidated infrastructure.
The ARQ subsystem would be gone as well as the dependency on the
Alpha4.SP fork.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 10 months
Don't pull from master!
by Kabir Khan
Master is in an inconsistent state due to me accidentally having pulled in a merge commit, and I'm looking at how to restore it. If you rebase onto master now we will end up in a mess again.
14 years, 10 months
So how do I update the build version?
by Scott Stark
I thought I might just have to change the jboss-as/pom.xml version to
affect the overall build version, but it seems I need to update all 108
pom.xml/*<version>7.0.0.Beta4-SNAPSHOT</version> references in order for
the build to work. Is that correct?
14 years, 10 months
Console Beta9
by Heiko Braun
We just updated to 1.0.0.Beta9:
- suport for standalone
- i18n
- deployments
- authentication
- datasources
- jms configurations
- messaging
- web subsystem
- server groups
- server configurations
- system properties
- jvm options
- socket bindings
The given functionality has small glitches here and there but most of it has been reported
and is being worked on. In terms real tasks, this is still outstanding:
- transaction subsystem
- security
- webservices
- threads
- logging
But we expect this to be ready for 7.0.CR1.
Give it try & let us know what you think.
Tell us for works and what doesn't.
Ike
14 years, 10 months
deployments directory usage with openshift
by Scott Stark
So right now how a user deploys an application to openshift express is
that when they create an application, a side-effect of this is that they
get a git repository on their local machine that maps to the server's
deployments directory. However, it is only updated by the client
actions. The repository is not updated to show status changes in the
deployments status files.
Here is a client side deployment dir repo that shows two deployed
applications:
[335](ironmaiden:deployments) > git status
# On branch master
nothing to commit (working directory clean)
[336](ironmaiden:deployments) > git pull
Already up-to-date.
[337](ironmaiden:deployments) > ls
README.txt weld-permalink.war
ROOT.war weld-permalink.war.dodeploy
ROOT.war.dodeploy
While the server deployments directory has updated deployment status
file markers:
[root@ip-10-72-59-227 deployments]# ls
README.txt ROOT.war.deployed weld-permalink.war.deployed
ROOT.war weld-permalink.war
The directory on the server is not actually a live repository:
[root@ip-10-72-59-227 deployments]# git status
fatal: Not a git repository (or any of the parent directories): .git
it is just a copy that is updated by a git post-receive hook.
Currently, to undeploy an application one git rms it and then pushes the
content:
[338](ironmaiden:deployments) > git rm weld-permalink.war*
rm 'deployments/weld-permalink.war'
rm 'deployments/weld-permalink.war.dodeploy'
[339](ironmaiden:deployments) > git push
Everything up-to-date
[340](ironmaiden:deployments) > git commit -a -m "undeploy weld-permalink"
[master 6bfa575] undeploy weld-permalink
1 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 deployments/weld-permalink.war
delete mode 100644 deployments/weld-permalink.war.dodeploy
[341](ironmaiden:deployments) > git push
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 279 bytes, done.
Total 3 (delta 1), reused 1 (delta 0)
To
ssh://efb401bdb2e641528a1f9278ca091719@as7b4test-sstark.dev.rhcloud.com/~/git/as7b4test.git/
067829a..6bfa575 master -> master
On server:
[root@ip-10-72-59-227 standalone]# ls deployments/
README.txt ROOT.war ROOT.war.deployed weld-permalink.war.undeployed
This works fine, it is just not as transparent an experience as working
with a local directory. I'm not sure how much effort I want to put into
trying to map the status deployment markers to the client side repo as
I'm going to look at getting the http management interface multi-plexing
on the 8080 port and exposed via a rest url associated with the
application dns name, in this case it would be
http://as7b4test-sstark.dev.rhcloud.com/management.
So, the point of this post is to ask if it is worth adding a
x.doundeploy marker to avoid having to remove the application content.
I'm thinking no, but maybe there are other usecases that would wan this.
14 years, 10 months
jca-short-running vs jca-long-running
by Francesco Marchioni
Dear all,
the previous discussion about the server's Thread Pool configuration raised
one doubt:
which kind of subsystem will use the jca-short-running and which one the
jca-long-running in the AS final release ?
(f.e. According to the docs HornetQ uses a general purpose thread pool is
used for most asynchronous actions so I guess it will use
one of the built-in jca pools).
I'd be grateful if somebody could shed some light on it.
Thanks a lot
Francesco
14 years, 10 months
JBoss AS 7 in Fedora
by Marek Goldmann
Guys,
Just a heads-up: I'm starting the effort to make JBoss AS 7 available in Fedora. Most probably I'll have questions and maybe also some help/code requests for you - don't be surprised! :)
Thanks, TTYL!
P.S. If anyone is interested in helping me - make sure you let me know. Any hand will be appreciated!
--Marek
14 years, 10 months
Re: [jboss-as7-dev] JBoss AS 7 in Fedora
by fernando＠lozano.eti.br
Hi,
It'll be very nice to finally have jboss-as packaged on Fedora.
There were rpm packaging for previous versions of jboss-as for RHEL (that is, jboss-eap), but they looked like "zip as rpms" and were not compliant to JPackage guidelines, duplicating many files from other packages already in RHEL / Fedora. But maybe you can get those and use as a starting point.
[]s, Fernando Lozano
>---- Original Message ----
>From: "David M. Lloyd" <david.lloyd(a)redhat.com>
>To: jboss-as7-dev(a)lists.jboss.org
>Sent: Ter, Mai 24, 2011, 18:05 PM
>Subject: Re: [jboss-as7-dev] JBoss AS 7 in Fedora
>
>On 05/23/2011 01:51 AM, Marek Goldmann wrote:
>> Guys,
>>
>> Just a heads-up: I'm starting the effort to make JBoss AS 7 available in Fedora. Most probably I'll have questions and maybe also some help/code requests for you - don't be surprised! :)
>>
>> Thanks, TTYL!
>>
>> P.S. If anyone is interested in helping me - make sure you let me know. Any hand will be appreciated!
>
>Count me in for sure!
>--
>- DML
>_______________________________________________
>jboss-as7-dev mailing list
>jboss-as7-dev(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
14 years, 10 months
Need stack trace or more context in model failures
by Scott Stark
I'm seeing just this one line erorr msg after making a change to the
standalone.xml in both the console and server.log:
12:44:31,346 ERROR [org.jboss.as.server] Boot update failed:
"java.lang.IllegalArgumentException"
Putting this in the debugger to see where this is coming from, it has
something to do with the web subystem as the failure is dispatched from:
* doExecute():219, ServerControllerImpl {org.jboss.as.server}
with an address of:
[
("subsystem" => "web"),
("virtual-server" => "localhost")
]
Apparently it is not liking this change I made to the web subsystem:
<subsystem xmlns="urn:jboss:domain:web:1.0">
<connector name="http" protocol="HTTP/1.1" socket-binding="http"
scheme="http"/>
<virtual-server name="localhost" enable-welcome-root="false" />
</subsystem>
from the default of:
<subsystem xmlns="urn:jboss:domain:web:1.0">
<connector name="http" protocol="HTTP/1.1" socket-binding="http"
scheme="http"/>
<virtual-server name="localhost" enable-welcome-root="true">
<alias name="example.com" />
</virtual-server>
</subsystem>
I'm guessing it is because the alias is required, but that should not be
true and is not indicated by the schema.
I'll look into that, but we need more context to know what is failing.
14 years, 10 months
AS7 Arquillian update call
by Thomas Diesler
Folks,
unless otherwise agreed, we meet Thu 26-May at the usual time (14:00 UTC)
Conference code
6624229975
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 10 months
