Secure HTTP API Endpoint
by Heiko Braun
I would suggest we do provide an out-the-box config that secures the HTTP endpoint:
<management>
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<users>
<user username="admin">
<password>password</password>
</user>
</users>
</authentication>
</security-realm>
</security-realms>
</management>
Any objections or good reasons not to do it?
Ike
14 years, 12 months
Adding a new module during runtime
by Jaikiran Pai
Is there an API which will allow me to install a new module into a
server at runtime? What I'm looking for, is a way to add a module and
then add a dependency on that module in my deployment, from within a
testcase.
-Jaikiran
14 years, 12 months
FYI, something amiss in OSGiXServiceParseProcessor
by Scott Stark
I'm seeing this NPE when trying to deploy a resteasy war that only
contains a couple of the json related jars, apparently because the
jettison-1.2.jar include some osgi bundle attributes.
[198](ironmaiden:deployments) > ls agent-1.0.war/WEB-INF/lib/
jettison-1.2.jar resteasy-jettison-provider-2.2-RC-1.jar
[217](ironmaiden:deployments) > java DumpManifest
agent-1.0.war/WEB-INF/lib/resteasy-jettison-provider-2.2-RC-1.jar
Build-Jdk: 1.6.0_24
Built-By: billburke
Manifest-Version: 1.0
Created-By: Apache Maven
Archiver-Version: Plexus Archiver
[218](ironmaiden:deployments) > java DumpManifest
agent-1.0.war/WEB-INF/lib/jettison-1.2.jar
Export-Package:
org.codehaus.jettison.util;version=1.2,org.codehaus.jettison.badgerfish;uses:="org.codehaus.jettison.util,javax.xml.stream,org.codehaus.jettison.json,org.codehaus.jettison,javax.xml.namespace";version=1.2,org.codehaus.jettison.mapped;uses:="org.codehaus.jettison.util,javax.xml.stream,org.codehaus.jettison.json,org.codehaus.jettison,javax.xml.namespace";version=1.2,org.codehaus.jettison.json;version=1.2,org.codehaus.jettison;uses:="org.codehaus.jettison.json,javax.xml.parsers,javax.xml.transform.dom,javax.xml.stream.events,org.w3c.dom,javax.xml.namespace,org.codehaus.jettison.util,javax.xml.stream,javax.xml.stream.util,javax.xml.transform,javax.xml.transform.stream";version=1.2
Private-Package: !*
Implementation-Title: Jettison
Implementation-Version: 1.2
Manifest-Version: 1.0
Tool: Bnd-0.0.160
Bundle-Name: jettison
Created-By: 1.6.0_17 (Apple Inc.)
Bundle-Version: 1.2
Bnd-LastModified: 1263724814999
Bundle-ManifestVersion: 2
Bundle-Description: A StAX implementation for JSON.
Bundle-SymbolicName: org.codehaus.jettison.jettison
Include-Resource: src/main/resources
Import-Package:
javax.xml.namespace,javax.xml.parsers,javax.xml.stream,javax.xml.stream.events,javax.xml.stream.util,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.stream,org.codehaus.jettison;version=1.2,org.codehaus.jettison.badgerfish;version=1.2,org.codehaus.jettison.json;version=1.2,org.codehaus.jettison.mapped;version=1.2,org.codehaus.jettison.util;version=1.2,org.w3c.dom
11:50:01,783 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
MSC00001: Failed to start service
jboss.deployment.unit."agent-1.0.war".PARSE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."agent-1.0.war".PARSE: Failed to process phase
PARSE of deployment "agent-1.0.war"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
[jboss-as-server-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
[jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by: java.lang.NullPointerException
at
org.jboss.as.osgi.deployment.OSGiXServiceParseProcessor.deploy(OSGiXServiceParseProcessor.java:55)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
[jboss-as-server-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
... 4 more
15 years
Bundling content with deployments
by David M. Lloyd
I was chatting with Ales about his issues trying to incorporate a
seam-int module into a deployment, such that every deployment (which
bundles seam) would get a copy of those classes added to it.
So I thought I'd cover some options for a general approach to solving
this issue.
First, it is important to note that such content should NOT be made into
a static module. Modules are only for JARs which only have a single
instance in the app server.
I think a good possible approach would be to define a resource root in a
(different) module which contains the JAR file itself as an opaque
resource, and then reference that resource when constructing the deployer.
In this example I'll have a fictional module called
"org.jboss.ales.deployer".
The module.xml for this module should look something like this:
<module xmlns="urn:jboss:module:1.0" name="org.jboss.ales.deployer">
<resources>
<resource-root path="bundled"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.as.controller"/>
<module name="org.jboss.as.server"/>
...other modules here...
</dependencies>
</module>
Then we deposit the nested seam-int JAR into the "bundled" subdirectory
of our module through some sort of build.xml modification, taking care
to use a predictable name for the JAR (as opposed to the long Maven name).
Having done this, code from the org.jboss.ales.deployer module can now
reliably acquire this file path:
File jarFile = new File(getClass().getResource("/seam-int.jar").toURI());
The File can then make its way to the deployment as a resource root,
thus creating a copy of the content in each deployment which our
deployer wishes to add it to.
Questions/comments?
--
- DML
15 years
Deployment API List Deployments
by James Perkins
I'm working on the deployment maven plugin. I want the redeploy goal to
either deploy if the deployment does not exist or redeploy if it does
exist. I'm having trouble determining if the deployment already exists.
This bit of CLI :read-children-names(child-type=deployment) shows me
what deployments exist. I've tried to duplicate it via a ModelNode.
ModelNode op = new ModelNode();
op.get("operation", READ_CHILDREN_NAMES_OPERATION).set(CHILD_TYPE,
DEPLOYMENT);
final InetAddress host = InetAddress.getByName(hostname);
final ModelControllerClient client =
ModelControllerClient.Factory.create(host, port);
ModelNode result = client.execute(op);
which results in
{
"outcome" => "failed",
"failure-description" => "No handler for {\"read-children-names\"
=> (\"child-type\" => \"deployment\")} at address []"
}
I tried assigning an address, but I don't know I did it right. Any
pointers would be appreciated.
--
James R. Perkins
JBoss by Red Hat
15 years
Issue with access to java:comp/UserTransaction from non EE threads
by Lincoln Baxter, III
Hi Guys,
I've written a little app (using Seam 3, RichFaces, a bunch of our projects,
but namely Seam Persistence.) While working with Scott Marlow, we discovered
that the reason for this failure: http://pastebin.com/KC7v90YK, is because
the thread attempting to access the UserTransaction is outside of the EE
threads: http://pastie.org/2010007
This works well on JBoss AS6, but does not on AS7. Wondering if we should
loosen up the access to the UserTransaction to anonymous/non-EE threads.
In addition, when deploying the application on the latest snapshots, I have
been getting weird Weld failures. Seems like Weld is not in a usable state
by the time my @Stateful EJB is requesting for an @Inject BeanManager.
15:44:08,075 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1)
> MSC00001: Failed to start service
> jboss.deployment.unit."hatchling.war".component.EjbSynchronizations.WeldInstantiator:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."hatchling.war".component.EjbSynchronizations.WeldInstantiator:
> Failed to start service
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1696)
> [jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> [:1.6.0_24]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
> [:1.6.0_24]
> at
> org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1209)
> at
> org.jboss.as.weld.injection.WeldManagedReferenceFactory.start(WeldManagedReferenceFactory.java:119)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> [jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
> ... 3 more
>
Thoughts welcomed.
Thanks,
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
15 years
JBoss Web Custom Authenticators
by Darran Lofthouse
Within previous JBoss AS releases it was always possible to override the
mapping between the method in the web.xml and the actual Authenticator
that was used to perform authentication.
In AS7 I see there is still a default configuration within the JBoss Web
jar but how can custom authenticators be defined?
Regards,
Darran Lofthouse.
15 years
Re: [jboss-as7-dev] jboss-as7-dev Digest, Vol 7, Issue 34
by Michael Musgrove
Can you give me an example of what other projects are providing you with
or indicate what you prefer. Then I can look into adding it.
BTW AS7 will be consuming JBOSSTS_4_14_0_Final so what is the process
for making changes.
> Can these TxStats be accessed via something other than JMX? If at all
> possible I want the AS management layer (in the AS transactions module)
> to not rely on JMX to pull data from subsystems.
>
> On 5/11/11 9:42 AM, Michael Musgrove wrote:
>> Can you clarify what it is that you need to know. I don't understand where these attributes are coming from nor what their values mean.
>>
>> We do have various beans that we have, in the past, exposed via JMX or via RHQ. For example, consider the first attribute "core-environment" => .... I guess this is referring to our CoreEnvironment bean which does have a property called socketProcessIdPort which we use to facilitate creation of unique ids and it also has a property called nodeIdentifier which we use to ensure that different recovery managers don't end up recovering each others transactions. But there are also other properties in that bean which your snippet does not mention.
>>
>> The enable-statistics property simply enables metrics gathering for transaction counts (heuristics, commits etc). Once enabled the statistics can be retrieved from our TxStats MBean.
>>
>> Mike
>>
>>
>> ----- Original Message -----
>>
>>>> From: "Heiko Braun"<hbraun(a)redhat.com>
>>>> To:"jboss-as7-dev(a)lists.jboss.org Development"<jboss-as7-dev(a)lists.jboss.org>
>>>> Sent: Tuesday, May 10, 2011 9:07:24 AM
>>>> Subject: [jboss-as7-dev] TX subsystem management use cases
>>>>
>>>>
>>>>
>>>> Can anyone shed some light on the management op's for the transaction
>>>> subsystem?
>>>> The attribute names indicate more sophisticated features, like
>>>> statistics.
>>>>
>>>> I would need to know how to work with this data in order expose
>>>> reasonable functionality through the web UI.
>>>>
>>>> [domain@localhost:9999 /]
>>>> /profile=default/subsystem=transactions:read-resource(recursive=true)
>>>> {
>>>> "outcome" => "success",
>>>> "result" => {
>>>> "core-environment" => {
>>>> "socket-binding" => "txn-socket-process-id",
>>>> "node-identifier" => undefined
>>>> },
>>>> "recovery-environment" => {
>>>> "socket-binding" => "txn-recovery-environment",
>>>> "status-socket-binding" => "txn-status-manager"
>>>> },
>>>> "coordinator-environment" => {
>>>> "enable-statistics" => undefined,
>>>> "default-timeout" => undefined
>>>> },
>>>> "object-store" => {
>>>> "relative-to" => undefined,
>>>> "path" => undefined
>>>> }
>>>> },
>>>> "compensating-operation" => undefined
>>>> }
>>>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
15 years
