ClientLoginModule
by Jan Lanik
Hi,
I have a few questions concerning the client login module.
1) Java doc says "This simply sets
the SecurityContext principal to the value of the NameCallback"
How can I get to the "SecurityContext principal"?
2) Is this supposed to be used in container or from servlet or even from remote application?
Is there some usage example?
Thanks, Jan
12 years
Re: [jboss-as7-dev] Breakup quickstarts into separate repos?
by Pete Muir
Adding Scott and jboss-as7-deb(a)lists.jboss.org.
No, I'm not on the jboss as internal list, not sure why we need to discuss it there?
This has come up a couple of times recently. The main issue I see is that this will result in around 80-100 git repositories, and a lot of scripting to create coordinated releases. It sounds like an admin and contribution nightmare to me.
I've thought about the problem Scott raises, and the best solution I've come up with so far is copy and paste:
git clone git://github.com/jbossas/quickstart.git ../quickstaets
cp -r ../quickstart/kitchensink/* .
git add src pom.xml
git push
which is only one more command.
We can also use a subtree merge (which is what you need to look at Scott, not submodules), but I feel this is much more complex to advise to users, as it involves explaining what a subtree merge is, over everyone knowing what a copy and paste is.
On 14 Mar 2012, at 01:00, Sande Gilda wrote:
> Did you see this? It sounds like it would be a problem to administer and release. What do you think?
>
> -------- Original Message --------
> Subject: Breakup quickstarts into separate repos?
> Date: Tue, 13 Mar 2012 17:11:25 -0400 (EDT)
> From: Scott Stark <sstark(a)redhat.com>
> To: jboss-as(a)redhat.com
>
> Would it make sense to break each quickstart into it's own repository and then integrate them back into the quickstart repository using the git submodule? What I would like to be able to do is something like the following in an openshift app repo to switch over to the quickstart:
>
> git remote add upstream -m master git://github.com/jbossas/kitchensink.git
> git pull -s recursive -X theirs upstream master
> git push
>
> There is no notion of checking out a subdirectory of a git repo. One problem I see with using submodules is that when I checkout the root project containing the submodules, the submodules content is not checked out. There is a comment in one submodule tutorial that claims later versions of git due checkout the submodule content, but with my git version 1.7.9.1 I don't see that happening.
>
>
12 years
Re: [jboss-as7-dev] Problems with .deploy markers in shared directories
by Brian Stansberry
The deployment-scanner and the CLI are both clients using the management
API. Under the covers, they both do the same thing -- take an archive
somewhere on the filesystem and upload it to the server, which stores it
in data/content and then deploys it.
The deployment-scanner is for people who prefer to use OS gestures (like
the cp command) as their user interface instead of using the CLI.
On 4/4/12 12:47 AM, Bela Ban wrote:
> I understand the CLI places applications into a separate directory
> ('data' ?), so I'm wondering why we have 2 different locations:
> 'deployments' for manual deployment and 'data' for deploying via the CLI ?
>
> If this is the case, then this would be inconsistent
>
>
> On 4/3/12 10:41 PM, Brian Stansberry wrote:
>> Did this kind of deployment dir sharing work on previous AS releases? I
>> suppose it might have for .war files since IIRC wars were copied into
>> tmp/. For other deployment types I believe doing this would have led to
>> file lock problems on Windows.
>>
>> Anyway, I've opened https://issues.jboss.org/browse/AS7-4383 to look
>> into not writing marker files or optionally writing them in data/. Part
>> of the purpose of those marker files was a request that we provide in
>> the dir itself input to users as to what was happening with the
>> deployment.
>>
>> Even if AS7-4383 were done I don't think *exploded* deployments would
>> work reliably at all if scanners on multiple servers were scanning the
>> same dir. There would likely be file lock problems and deleting the
>> .deployed file is the intended trigger for undeploy. Deleting the
>> deployment itself also triggers undeploy, but it is very dangerous to do
>> it that way for an exploded deployment.
>>
>> More in-line...
>>
>> On 3/30/12 7:34 AM, Bela Ban wrote:
>>> I have a big problem with the way AS deploys applications: I have a
>>> web.war and a cluster of AS 7.1.1 instances.
>>>
>>> Each instance has separate work, data, log, tmp etc directories
>>> (jboss.node.name, jboss.server.data.dir, jboss.server.temp.dir etc).
>>>
>>> I have a $HOME/jboss/standalone/deployments dir into which I copied
>>> web.war, assuming that web.war is an application that can be shared by
>>> all cluster nodes.... However, the markers screw things up, as they
>>> actually modify things.
>>>
>>> The first node is started and adds a suffix web.war.dodeply -->
>>> .isdploying --> .deployed.
>>>
>>> The second node is started and does the same. (The weird thing is why
>>> does the 2nd node even deploy web.war anymore, as the marker .deployed
>>> suggested that the app has already been deployed !)
>>>
>>
>> It knows it's not deployed, because it can check the server-side state.
>>
>>> However, if I start a few nodes concurrently, then this lifecycle is
>>> screwed, and I end up with some nodes having web.war deployed and others
>>> not. This apparently gets sorted out, and after some time the marker is
>>> .deployed again. But this spits out nasty warnings in-between.
>>>
>>> Is there a recommended way to share web.war between cluster nodes ?
>>>
>>
>> Recommended is to use the CLI to do the deployments. This can be
>> scripted easily enough if you know the addresses/ports the servers are
>> listening on. (I realize that may be a problem in some situations.)
>>
>> You can also configure the AS to use a deployment at a specific location:
>>
>> <deployments>
>> <deployment name="demo.war" runtime-name="demo.war">
>> <fs-archive path="demo.war" relative-to="user.home"/>
>> </deployment>
>> </deployments>
>>
>> The value for fs-archive "path" can be absolute if the relative-to
>> attribute is not used.
>>
>> I just filed a JIRA to make it easier to set this up via the CLI:
>>
>> https://issues.jboss.org/browse/AS7-4385
>>
>>> IMO, markers should be in the *data* dir for a node, which can easily be
>>> separated by using -Djboss.server.data.dir=xxx !
>>>
>>
>> See above; the request was to provide input to the user as to what went
>> on. The user is not meant to look in the data/ dir; it's the AS' private
>> playground. Also, the recommended trigger for undeploy is deleting the
>> .deployed file.
>>
>>> What's the recommended way to share applications between nodes ? (I
>>> tried domain mode, but couldn't get it to work after half a day...)
>>>
>>> If this is an RTFM, perhaps I didn't google enough, then let me know !
>>>
>>
>>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12 years
Maven system dependencies
by Kabir Khan
Recently there have been a few pull requests using system dependencies, which work on Windows and Linux but which blow up on OS X due to its JDK directory structure being different such as:
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>jconsole</artifactId>
<version>1.6.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/jconsole.jar</systemPath>
</dependency>
</dependencies>
Instead of doing ^ please do the following. There is an example in clustering/pom.xml for tools.jar, and there will be one (once tests pass) in cli/pom.xml for jconsole.jar:
<profiles>
<profile>
<id>linux-windows</id>
<activation>
<file><exists>${java.home}/../lib/tools.jar</exists></file>
</activation>
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>jconsole</artifactId>
<version>jdk</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/jconsole.jar</systemPath>
</dependency>
</dependencies>
</profile>
<profile>
<id>os-x</id>
<activation>
<file><exists>${java.home}/bundle/Classes/classes.jar</exists></file>
</activation>
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>jconsole</artifactId>
<version>jdk</version>
<scope>system</scope>
<systemPath>${java.home}/bundle/Classes/jconsole.jar</systemPath>
</dependency>
</dependencies>
</profile>
</profiles>
12 years
Re: [jboss-as7-dev] Problems with .deploy markers in shared directories
by Brian Stansberry
Did this kind of deployment dir sharing work on previous AS releases? I
suppose it might have for .war files since IIRC wars were copied into
tmp/. For other deployment types I believe doing this would have led to
file lock problems on Windows.
Anyway, I've opened https://issues.jboss.org/browse/AS7-4383 to look
into not writing marker files or optionally writing them in data/. Part
of the purpose of those marker files was a request that we provide in
the dir itself input to users as to what was happening with the deployment.
Even if AS7-4383 were done I don't think *exploded* deployments would
work reliably at all if scanners on multiple servers were scanning the
same dir. There would likely be file lock problems and deleting the
.deployed file is the intended trigger for undeploy. Deleting the
deployment itself also triggers undeploy, but it is very dangerous to do
it that way for an exploded deployment.
More in-line...
On 3/30/12 7:34 AM, Bela Ban wrote:
> I have a big problem with the way AS deploys applications: I have a
> web.war and a cluster of AS 7.1.1 instances.
>
> Each instance has separate work, data, log, tmp etc directories
> (jboss.node.name, jboss.server.data.dir, jboss.server.temp.dir etc).
>
> I have a $HOME/jboss/standalone/deployments dir into which I copied
> web.war, assuming that web.war is an application that can be shared by
> all cluster nodes.... However, the markers screw things up, as they
> actually modify things.
>
> The first node is started and adds a suffix web.war.dodeply -->
> .isdploying --> .deployed.
>
> The second node is started and does the same. (The weird thing is why
> does the 2nd node even deploy web.war anymore, as the marker .deployed
> suggested that the app has already been deployed !)
>
It knows it's not deployed, because it can check the server-side state.
> However, if I start a few nodes concurrently, then this lifecycle is
> screwed, and I end up with some nodes having web.war deployed and others
> not. This apparently gets sorted out, and after some time the marker is
> .deployed again. But this spits out nasty warnings in-between.
>
> Is there a recommended way to share web.war between cluster nodes ?
>
Recommended is to use the CLI to do the deployments. This can be
scripted easily enough if you know the addresses/ports the servers are
listening on. (I realize that may be a problem in some situations.)
You can also configure the AS to use a deployment at a specific location:
<deployments>
<deployment name="demo.war" runtime-name="demo.war">
<fs-archive path="demo.war" relative-to="user.home"/>
</deployment>
</deployments>
The value for fs-archive "path" can be absolute if the relative-to
attribute is not used.
I just filed a JIRA to make it easier to set this up via the CLI:
https://issues.jboss.org/browse/AS7-4385
> IMO, markers should be in the *data* dir for a node, which can easily be
> separated by using -Djboss.server.data.dir=xxx !
>
See above; the request was to provide input to the user as to what went
on. The user is not meant to look in the data/ dir; it's the AS' private
playground. Also, the recommended trigger for undeploy is deleting the
.deployed file.
> What's the recommended way to share applications between nodes ? (I
> tried domain mode, but couldn't get it to work after half a day...)
>
> If this is an RTFM, perhaps I didn't google enough, then let me know !
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12 years
Running AS7 tests in eclipse?
by Jeff Mesnil
Hi,
It's a silly question but I ask it anyway: how do you run individual AS7
tests in eclipse?
I can not manage to run either messaging subsystem or integration tests
individually from eclipse...
I followed docs[1][2] (incl. setting up the Maven profile) without any
success. Any Arquillian test fails with the error:
org.jboss.arquillian.container.spi.ConfigurationException: jbossHome
'null' must exist
and setting the jboss.home env variable in the run configuration does
not work. Am I missing something obvious?
It seems weird that the file
testsuite/integration/smoke/src/test/config/arq/arquillian.xml is not in
eclipse's Build Path. But adding it does not have any effect
I made a simple project to familiarize myself with Arquillian and it
works fine, I can deploy a JMS queue, test it, everything's fine.
But I'm at loss to run Arquillian individual tests from AS7...
The messaging susbystem tests fails too when in run them in eclipse with
the error:
java.lang.Exception: java.lang.ExceptionInInitializerError
at
org.jboss.as.subsystem.test.AbstractSubsystemTest$ModelControllerService.boot(AbstractSubsystemTest.java:763)
at
org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:185)
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.ExceptionInInitializerError
at
org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
at
org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200)
at
org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:149)
at
org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:190)
at
org.jboss.as.subsystem.test.AbstractSubsystemTest$ModelControllerService.boot(AbstractSubsystemTest.java:759)
... 3 more
Caused by: java.lang.IllegalArgumentException: Invalid logger interface
org.jboss.as.controller.ControllerLogger (implementation not found)
at org.jboss.logging.Logger.getMessageLogger(Logger.java:2250)
at org.jboss.logging.Logger.getMessageLogger(Logger.java:2214)
at
org.jboss.as.controller.ControllerLogger.<clinit>(ControllerLogger.java:51)
... 8 more
I have imported both jboss-as-messaging and jboss-as-controller projects
in eclipse.
Is there something specific to do to have logging working in eclipse?
I feel dumb not being able to run a single test from eclipse... :)
thanks,
jeff
[1] https://community.jboss.org/wiki/HackingAS7UsingEclipse
[1] https://community.jboss.org/wiki/WritingAAS7TestCaseInTestsuiteModule
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
12 years
Naming a domain controller
by ssilvert＠redhat.com
In the first element of standalone.xml I can rename my server <server
name="George" ...
But for a domain controller, I don't see any way to give it a name. It
has no name at all. Is there any reason for this?
It would be helpful to give your domain controller a name. That way if
you have more than one you can tell which one you are talking to over
the management interface.
Stan
12 years
update messaging subsystem config to 1.2
by Jeff Mesnil
Hi,
I am working on a JIRA issue to add missing configuration parameters to
messaging resources[1]
I did a quick patch to unblock the performance teams but I am revisiting
it to fix it properly[2].
As I am changing the XSD schema, I need to bump up its version.
My changes are small (I'm just adding elements) but I wonder what the
policy to manage schema changes is.
* should I be able to read any previous configuration version? or only
the last 2?
* if I am reading an old configuration version, should I persist it at
the same old version or the latest version?
I looked at ejb3 subsystem to see how configuration schemas are handled.
Is it a good candidate to copy?
thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-4330
[2]
https://github.com/jmesnil/jboss-as/commit/2f4389a10fe61bd054a5e4729ae8c6...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
12 years
Q about http management api
by Heiko W.Rupp
>From time to time I see
405 errors
11:16:10,103 DEBUG [ASConnection] We got a 405 for url http://127.0.0.1:49990/management and operation Operation{operation='read-attribute', address=Address{path: }, additionalProperties={name=launch-type, include-defaults=true}}, method=POST
conn = (HttpURLConnection) url.openConnection();
conn.setDoOutput(true);
conn.setRequestMethod("POST");
conn.addRequestProperty("Content-Type", "application/json");
conn.addRequestProperty("Accept", "application/json");
My understanding is that those only should show when content type is wrong. Looking at the sources I see that they
may happen
- on OPTIONS method (which we don't do)
- for other contexts that only support GET ( like / )
Any idea what may go wrong here?
And then for requests for stuff that is e.g. not deployed , the API returns "internal server error" 500,
11:16:15,370 ERROR [ASConnection] Operation{operation='read-resource', address=Address{path: subsystem=connector}, additionalProperties={include-defaults=true}} failed with 500 (Internal Server Error) - response body was [{"outcome" : "failed", "failure-description" : "JBAS014739: No handler for read-resource at address [(\"subsystem\" => \"connector\")]", "rolled-back" : true}].
I think a 404 not found would be much more correct. Especially as it looks like URLConnections throw exceptions on 500 errors.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
12 years
