system properties on server group level
by Heiko Braun
have the system properties for server groups been dropped?
[localhost:9999 /] /server-group=development-group:read-children-types
{
"outcome" => "success",
"result" => [
"jvm",
"deployment"
],
"compensating-operation" => undefined
}
In that case they need to be removed form the schema as well.
Ike
15 years
Create new server group error
by Heiko Braun
the following operation leads to the error below:
[INFO] {
[INFO] "operation" : "add",
[INFO] "address" : {
[INFO] "PROPERTY_VALUE" : {
[INFO] "server-group" : "dev"
[INFO] }
[INFO] },
[INFO] "profile" : "default"
[INFO] }
[Host Controller] 13:18:39,972 INFO [org.jboss.as.domain.controller] (pool-1-thread-15) Execution exception reading host controller response: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException
[Host Controller] at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) [:1.6.0_24]
[Host Controller] at java.util.concurrent.FutureTask.get(FutureTask.java:83) [:1.6.0_24]
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl.processHostFuture(DomainControllerImpl.java:582)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl.pushToHosts(DomainControllerImpl.java:523)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl.execute(DomainControllerImpl.java:278)
[Host Controller] at org.jboss.as.controller.AbstractModelController.execute(AbstractModelController.java:101)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl.execute(DomainControllerImpl.java:219)
[Host Controller] at org.jboss.as.domain.http.server.DomainHttpServer.processRequest(DomainHttpServer.java:173)
[Host Controller] at org.jboss.as.domain.http.server.DomainHttpServer.handle(DomainHttpServer.java:104)
[Host Controller] at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82) [:1.6.0_24]
[Host Controller] at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:80)
[Host Controller] at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:85) [:1.6.0_24]
[Host Controller] at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:606)
[Host Controller] at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:82) [:1.6.0_24]
[Host Controller] at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:578)
[Host Controller] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24]
[Host Controller] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_24]
[Host Controller] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_24]
[Host Controller] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24]
[Host Controller] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) [:1.6.0_24]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
[Host Controller] at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
[Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[Host Controller] Caused by: java.lang.IllegalArgumentException
[Host Controller] at org.jboss.dmr.ModelValue.asInt(ModelValue.java:58)
[Host Controller] at org.jboss.dmr.ModelNode.asInt(ModelNode.java:117)
[Host Controller] at org.jboss.as.domain.controller.DomainModelImpl.isOperationForHost(DomainModelImpl.java:249)
[Host Controller] at org.jboss.as.domain.controller.DomainModelImpl.execute(DomainModelImpl.java:241)
[Host Controller] at org.jboss.as.controller.AbstractModelController.execute(AbstractModelController.java:101)
[Host Controller] at org.jboss.as.controller.BasicTransactionalModelController.execute(BasicTransactionalModelController.java:89)
[Host Controller] at org.jboss.as.domain.controller.DomainModelImpl.executeForDomain(DomainModelImpl.java:264)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl$LocalDomainModelAdapter.execute(DomainControllerImpl.java:899)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl.executeOnHost(DomainControllerImpl.java:798)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl.access$000(DomainControllerImpl.java:110)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl$2.call(DomainControllerImpl.java:602)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerImpl$2.call(DomainControllerImpl.java:596)
[Host Controller] ... 8 more
15 years
JBAS-9151 requires an api change to InterfaceCriteria
by Scott Stark
So digging into this more, the issue cannot be resolved without an api
change because there are interface criteria that aggregate other
criteria. For example, the
NetworkServiceInterface.OverallInterfaceCriteria, NotInterfaceCriteria,
AnyInterfaceCriteria, etc. The current issue I have is that the
LoopbackInterfaceCriteriaWithAddress is wrapped in a
NetworkServiceInterface.OverallInterfaceCriteria instance, and therefore
I cannot determine that it provides a InterfaceCriteriaWithAddress
implementation. The proper change would require a change to the
InterfaceCriteria to return the bindAddress to use when the criteria is
accepted, with the default implementation simply returning the input
address:
public interface InterfaceCriteria extends Serializable {
/**
* Gets whether the given network interface and address are
acceptable for
* use. Acceptance is indicated by returning the address which
should be used for binding against
* the network interface, typically this is the input address. For
those criteria which override the
* bind address, the overriden address should be returned.
*
* @param networkInterface the network interface. Cannot be
<code>null</code>
* @param address an address that is associated with
<code>networkInterface</code>. Cannot be <code>null</code>
* @return <code>InetAddress</code> the non-null address to bind to
if the criteria is met, null if the criteria does not apply
*
* @throws SocketException
*/
InetAddress isAcceptable(NetworkInterface networkInterface,
InetAddress address) throws SocketException;
}
15 years
Re: [jboss-as7-dev] AS7 Arquillian and OSGi
by Andrew Lee Rubinger
On 03/25/2011 08:49 AM, Kabir Khan wrote:
> It is in the jbosgi github repo
https://github.com/jbosgi/arquillian
Thank you. :)
S,
ALR
>
>
> -----Original Message-----
> From: Andrew Lee Rubinger [andrew.rubinger(a)redhat.com]
> Received: Friday, 25 Mar 2011, 7:09
> To: jboss-as7-dev(a)lists.jboss.org
> Subject: [jboss-as7-dev] AS7 Arquillian and OSGi
>
>
> I'm looking to upgrade ARQ in AS:
>
> https://issues.jboss.org/browse/JBAS-8946
>
> ...but AS is using a fork of Arquillian:
>
> <version.org.jboss.arquillian>1.0.0.Alpha4.SP9</version.org.jboss.arquillian>
>
> First, I can't find the source location for this tag. Closest I can see is:
>
> https://github.com/tdiesler/arquillian/commits/1.0.0.Alpha4.SP7
>
> ...and also there's some ARQ branch:
>
> https://github.com/arquillian/arquillian/commits/1.0.0.Alpha4-OSGi
>
> It's possible/probable that I missed some discussion on the reasoning
> behind this, but I want to put a stop to this kind of forking. Yes, I
> know that AS needed a release of ARQ before ARQ was ready for alpha-5.
>
> AS is in a position to fuel Arquillian development, and at the very
> least if forks are needed in a clutch, they've got to go into the
> authoritative Arquillian repository:
>
> https://github.com/arquillian/arquillian
>
> That said, I'm looking to resolve this and bring any changes that are
> demanded by AS back in line with current ARQ upstream/master.
>
> If you can point me at where the SP9 tag lives, I can start a discussion
> w/ Aslak about what we need to do to bring these changes into
> upstream/master. Perhaps some additional layering will be necessary to
> tack on OSGi-specific stuff that shouldn't be in ARQ core, and we should
> handle that too.
>
> But long-term, AS is going to need a version of ARQ that's not forked
> off current development so that we can do drop-in-place upgrades.
>
> S,
> ALR
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
15 years
Server instances again
by Heiko Braun
Looks like there is nothing at /host=local/sever=<XYZ>
It is not implemented or am I missing something?
I need to query the status of a server (started/stopped)
Ike
15 years
Equivalent of -b/--host in AS7
by Scott Stark
I'm not seeing the various server ports defined in the
socket-binding-group use the default-interface value for the interface
to which they bind. Rather, they are showing up bound to any. How do I
achieve the equivalent of AS6 --host=aaa.bbb.ccc.ddd to have all server
listening ports bound to the aaa.bbb.ccc.ddd address?
<interfaces>
<interface name="default">
<inet-address value="127.0.0.1"/>
</interface>
<interface name="any">
<any-address/>
</interface>
<interface name="complex">
<any>
<subnet-match value="192.168.0.0/16"/>
<public-address/>
</any>
<not>
<site-local-address/>
</not>
<up/>
<multicast/>
</interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="default">
<socket-binding name="jndi" port="1099"/>
<socket-binding name="jmx-connector-registry" port="1090"/>
<socket-binding name="jmx-connector-server" port="1091"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8447"/>
<socket-binding name="osgi-http" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<socket-binding name="txn-socket-process-id" port="4714"/>
<socket-binding name="messaging" port="5445" />
<socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
15 years
Re: [jboss-as7-dev] Requirements and Design Proposal: AS7 TestSuite
by Shelly McGowan
Why don't we consider what was done for the CDI and BV TCKs. Annotations[1] are used to define the test type.
If it is a spec assertion, the spec reference is clearly identified:
@SpecAssertion(section = "2.1.1", id = "c")
or you could annotate the Test with @IntegrationTest which could be used to denote that AS-specific test.
Test (not code) coverage reports can be generated to identify what the coverage is for each component. The report
provides links to fisheye and the test code in svn.
[1]http://community.jboss.org/wiki/BeanValidationTCK#What_do_all_the_annot...
Other references:
http://docs.jboss.org/hibernate/stable/beanvalidation/tck/reference/html_...
http://anonsvn.jboss.org/repos/weld/cdi-tck/trunk/impl/src/main/java/org/...
Shelly McGowan
JBoss, by Red Hat
----- Original Message -----
From: "Andrew Lee Rubinger" <andrew.rubinger(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Saturday, March 19, 2011 5:34:30 PM
Subject: Re: [jboss-as7-dev] Requirements and Design Proposal: AS7 TestSuite
It occurs to me I might not have been clear about the JIRA-per-test thing.
Say you're working on Feature X. You might commit the feature and the
test alongside one another, citing the same JIRA, with the commit message:
"[JBAS-XXX] Implement Feature X and tests".
That's great. No separate issues needed for the feature and the test each.
What's no good is going in and adding a bunch of tests for EJB, Web, etc
while we pump up our coverage, alongside a commit message:
"[JBAS-XXX] Add spec coverage to the testsuite"
...that tells us nothing about each test being made, just that we dumped
'em in there. Which is obvious, because they're there.
S,
ALR
On 03/19/2011 05:25 PM, Andrew Lee Rubinger wrote:
> Inline.
>
> On 03/19/2011 03:19 PM, Jason Greene wrote:
>> I really like the idea of our primary test suite covering API interaction and your typical unit test which is tightly coupled to internals. I also like your idea to separate spec Apis from JBoss aAPIs.
>>
>> However, I disagree on the Jira per test requirement. This is only because I worked with a similar model (all jiras require a test), and you ended up with lots of duplicate tests, and you always had to read Jira to understand what was being tested. Also, the tests ended up being too specific, typically an exact replication of the reporter's workflow.
>
> Consider this: If you had to read JIRA to understand what was being
> tested, that's a clear violation of point 3): Document the test. And
> failing good documentation, with no JIRA to turn to, you're flying blind.
>
> Also, how exactly does registering a JIRA encourage test duplication?
> Whether the tests are in an issue tracker or not seems to be unrelated
> to folks writing duplicate tests.
>>
>> IMO a better way to organize it would be by functional area, with generous descriptions. All spec tests should reference spec sections, for example. If we have a Jira that demonstrates lack of coverage, we should translate the problem into meaningful and reusable tests for the gaps we missed. Those tests should primarily refer to the API contract and not the Jira. Although commenting a list of jiras for extra info may be useful provided the Jira doesn't confuse what the correct behavior should be.
>
> I'm a fan of organizing by functional areas and spec references. We'd
> done that in EJB3 with success: some packages were even named for the
> spec. Regardless, every commit had a JIRA association.
>
> In the end, so long as it's perfectly clear what we're testing and why,
> I'll have no objections. But I do believe that JIRA is the obvious
> answer to that question, and requires minimal effort to make a new
> issue. Especially since every commit is isolated to one concern and
> linked back to JIRA anyway, right? ;)
>
> S,
> ALR
>
>>
>> Sent from my iPad
>>
>> On Mar 18, 2011, at 2:21 AM, Andrew Lee Rubinger<andrew.rubinger(a)redhat.com> wrote:
>>
>>> Looks like a lot of us have different ideas for what the AS7 Integration
>>> TestSuite should consist of, so I'll kickoff with what I believe is the
>>> first design proposal towards getting coverage focused on the end-user
>>> (not certifying our own internals).
>>>
>>> I suspect this breaks down into two categories, which may be modelled as
>>> separate modules under the existing "testsuite" aggregator parent:
>>>
>>> * Specification
>>> * AS-specific APIs
>>>
>>> This isn't difficult work, though I do think it's important we consider
>>> some hard rules. IMO we should be developing these suites as if we were
>>> application developers, not wearing our server dev hats.
>>>
>>> ----------------
>>>
>>> [End Goal]
>>>
>>> 1) No compile-time dependencies in the module except for what's
>>> absolutely necessary.
>>>
>>> For the spec suite, this means: JDK and EE Spec APIs only in the
>>> compilation classpath. Testable asset sources and resources (ie. EJBs,
>>> Servlets, etc) would live under src/main/* to enforce that. Only the
>>> tests themselves would be located under "src/test/*".
>>>
>>> The AS-specific API suite may also add in our own APIs to the
>>> compilation classpath, but the line should end there. In "test" scope
>>> we can place all runtime dependencies.
>>>
>>> For the specification suite, AS-specific grammars like our own
>>> deployment descriptors are fine; these are in many ways equivalent to
>>> the TCK porting layer. We're not building a TCK; we're showing that our
>>> implementation supports the features advertised.
>>>
>>> 2) Every single new test created is to have an associated JIRA.
>>>
>>> We all remember the nightmare it was when the old AS4-6 suite would fall
>>> down. We'd comb through each test, at times trying to determine its
>>> purpose. By linking to JIRA we get history of intent, which acts as a
>>> nice record even in the case that the test isn't so well-documented.
>>> I'd argue that tests are a bigger asset than our code, and we should be
>>> thinking about these in terms of long-term maintenance to outlive any
>>> specific impl.
>>>
>>> 3) Documentation
>>>
>>> Alongside the JIRA reference, a quick note about we're looking to
>>> accomplish is something I find very helpful. I don't personally buy the
>>> argument that code is self-documenting if written well. It gets
>>> refactored and stale over time.
>>>
>>> 4) Run-mode profiles
>>>
>>> Arquillian provides a wonderful abstraction such that we can get
>>> coverage for AS in both remote managed *and* embedded modes without
>>> changing the test itself. To certify that everything is working as
>>> advertised no matter the runtime, we should be able to run the same
>>> suite in standalone, domain, and embedded modes (generally speaking).
>>>
>>> 5) Porting of AS6 Tests
>>>
>>> There's no discounting the value this coverage has given us, though I
>>> question the purpose of a lot of these tests. I think a great majority
>>> of these need to come into the new codebase, refactored to align if needed.
>>>
>>> ----------------
>>>
>>> [Current State]
>>>
>>> Here[1] is an example of what I believe to be a simple, well-written
>>> test, with the exception that the tested Servlet and EJB are in the same
>>> test source folder.
>>>
>>> The current "testsuite" aggregator contains modules which mix our
>>> end-user certification stuff alongside internals, so I think these
>>> should be separated out.
>>>
>>> A lot of this is set up in some fashion already, but I would like to see us:
>>>
>>> 1) Agree upon a strict scope for each type of testsuite along the lines
>>> of my points above, once we reach agreement
>>> 2) Upgrade to ARQ 1.0.0.Alpha5 (which implies ShrinkWrap
>>> 1.0.0-alpha-12), just released tonight. Currently AS is on a forked
>>> release of ARQ for OSGi purposes, and these changes, if necessary, need
>>> to get upstream so we can do upgrades.
>>>
>>> It's clear that AS7 has made full-steam-ahead progress since last
>>> summer, and with a little organization our testsuite can give us a great
>>> view of where we stand, from an end-user's perspective, with minimal
>>> investment.
>>>
>>> S,
>>> ALR
>>>
>>>
>>> [1]
>>> https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/src...
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
15 years
Error messages on Ctrl+C
by Max Rydahl Andersen
When doing Ctrl+C(stop server)
14:39:01,539 INFO [com.arjuna.ats.jbossatx] ARJUNA-32018 Destroying TransactionManagerService
14:39:01,545 INFO [com.arjuna.ats.jbossatx] ARJUNA-32014 Stopping transaction recovery manager
Why is that marked with an error code marker - and why is it in the output ?
(just curious if this is intended or accidental...)
/max
http://about.me/maxandersen
15 years
RFC: Model normalization
by Heiko Braun
The following are three responses to query server-config resources:
Take a look at the "jvm" property and imagine the number of if-statements
you need to come with to deal with the three different representations.
[INFO] {
[INFO] "path" : null,
[INFO] "system-property" : null,
[INFO] "interface" : null,
[INFO] "jvm" : {"default" : null},
[INFO] "name" : "server-one",
[INFO] "group" : "main-server-group",
[INFO] "auto-start" : true
[INFO] }
[INFO] {
[INFO] "path" : null,
[INFO] "system-property" : null,
[INFO] "interface" : null,
[INFO] "jvm" : {"default" : {"heap" : {
[INFO] "size" : "64m",
[INFO] "max-size" : "256m"
[INFO] }}},
[INFO] "name" : "server-two",
[INFO] "group" : "main-server-group",
[INFO] "socket-binding-group" : "standard-sockets",
[INFO] "socket-binding-port-offset" : -106,
[INFO] "auto-start" : true
[INFO] }
[INFO] {
[INFO] "path" : null,
[INFO] "system-property" : null,
[INFO] "interface" : null,
[INFO] "jvm" : null,
[INFO] "name" : "server-three",
[INFO] "group" : "other-server-group",
[INFO] "socket-binding-group" : "standard-sockets",
[INFO] "socket-binding-port-offset" : -6,
[INFO] "auto-start" : false
[INFO] }
IMO we need to think thoroughly about the following questions:
- Can the model be normalized somehow?
- How do we deal with inherited properties?
- Would it make sense to separate the actual state from the structural information?
Ike
15 years
