Deploying JSR 352 job as a module
by Gunnar Morling
Hi,
Is there any example which shows how to deploy a JSR 352 batch job via a
module added to WildFly rather than through a deployed application? This
batch job should then be usable from applications which declare a
dependency to that module.
Trying this, I'm getting an error saying that the batch job's XML
descriptor cannot be found [1]. I.e. the module with the batch job is
visible to the deployed application (as the MassIndexer class can be
accessed), but then JBeret cannot "see" the job XML descriptor within that
module.
Is there anything I can configure in the module.xml of the batch job's
module for exposing its contents to JBeret?
The use case is Hibernate Search where a GSoC student is working on a JSR
352 batch job for re-indexing entities. This job eventually should be part
of Hibernate Search's modules, allowing users to run it if Hibernate Search
is enabled for their application.
Thanks for any pointers,
--Gunnar
[1] Exception: javax.batch.operations.JobStartException: JBERET000601:
Failed to get job xml file for job mass-index.xml
at
org.jberet.creation.ArchiveXmlLoader.getJobXml(ArchiveXmlLoader.java:129)
at
org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:91)
at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
at org.hibernate.search.jsr352.MassIndexer.start(MassIndexer.java:90)
at
org.hibernate.search.jsr352.PerformanceIT.testNewMassIndexer(PerformanceIT.java:167)
...
8 years, 4 months
Pretty-printing XML validation errors
by Toby Crawley
I've done some work to pretty-print XML validation errors that occur
when parsing (standalone|domain|host).xml, and wanted to get some
feedback on what I have so far to see if:
1) there is interest in seeing this completed
2) the current approach is the best way to integrate with WildFly
3) this same approach could be used to pretty-print issues with other
xml parsed by WildFly (web.xml, jboss-deployment-structure.xml,
etc)
# Background
Inspired by error reporting in the Elm language[1] and improvements in
configuration feedback for Clojure tooling[2], I looked at what it
would take to provide better feedback when parsing XML configuration.
My goals were:
* Give users clear feedback that can be used to correct the
configuration error without the user having to context-switch to
documentation, and, in most cases, enable the user to quickly
identify and understand the issue before looking away from the
validation output, by:
* Showing (instead of telling) where in the XML the error occurred
* Providing richer feedback than the native validation error
provides (detect potential misspellings, provide alternate
locations, etc)
* Showing documentation for the element/attribute where possible
(pulled from the XSD)
* Use what we already produce (XSDs), without having to create
additional context-specific schema.
I've partially implemented a library (vdx)[3] that, given a validation
error, the source document, and the relevant schemas, generates and
prints a friendly error message. I've also made minimal changes to
WildFly to report validation errors to vdx (see below).
# Examples
Below is some examples of the current startup output from WildFly when
a validation error occurs:
## Detecting a misspelled attribute
13:18:03,798 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
13:18:03,949 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
13:18:04,010 INFO [org.jboss.as] (MSC service thread 1-6)
WFLYSRV0049: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" starting
13:18:04,751 ERROR [org.jboss.as.controller] (Controller Boot Thread)
====================== Validation Error in standalone.xml ======================
28: <extension module="org.wildfly.extension.request-controller"/>
29: <extension module="org.wildfly.extension.security.manager"/>
30: <extension modue="org.wildfly.extension.undertow"/>
^ 'modue' isn't an allowed attribute for the
'extension' element
31: </extensions>
32: <management>
33: <security-realms>
Did you mean 'module'?
================================================================================
13:18:04,753 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:175)
at org.jboss.as.server.ServerService.boot(ServerService.java:357)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
at java.lang.Thread.run(Thread.java:745)
13:18:04,754 FATAL [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0056: Server boot has failed in an unrecoverable manner;
exiting. See previous messages for details.
13:18:04,762 INFO [org.jboss.as] (MSC service thread 1-3)
WFLYSRV0050: WildFly Core 2.2.0.CR5-SNAPSHOT "Kenny" stopped in 4ms
## Detecting a misplaced attribute
...
14:32:23,842 ERROR [org.jboss.as.controller] (Controller Boot Thread)
====================== Validation Error in standalone.xml ======================
89: </console-handler>
90: <periodic-rotating-file-handler name="FILE" autoflush="true"
91: category="WARN">
^ 'category' isn't an
allowed attribute for the 'periodic-rotating-file-handler' element
92: <formatter>
93: <named-formatter name="PATTERN"/>
94: </formatter>
'category' is allowed on elements: subsystem > logger, subsystem >
logging-profiles > logging-profile > logger
Did you intend to put it on one of those elements?
================================================================================
...
## Detecting a misplaced element
...
10:54:27,359 ERROR [org.jboss.as.controller] (Controller Boot Thread)
====================== Validation Error in standalone.xml ======================
81: </management>
82: <profile>
83: <extension/>
^ 'extension' isn't an allowed element here
84: <subsystem xmlns="urn:jboss:domain:logging:3.0">
85: <console-handler name="CONSOLE">
86: <level name="INFO"/>
'extension' is allowed in elements: domain > extensions, domain >
host-excludes > host-exclude > excluded-extensions, host > extensions,
host > servers > server > extensions, server > extensions
Did you intend to put it in one of those elements?
================================================================================
...
# Changes to WildFly
To support this, I've made some small changes changes to
wildfly-core[4], but anticipate more before this is complete.
The current changes are:
* Modifications to ParseUtils to wrap the XMLStreamExceptions with
an exception that can convey more context to vdx
* Modifications to XmlConfigurationPersistor to:
* catch the wrapped exception
* see if ${jboss.home.dir}/docs/schema/ is available. If so,
pretty-print the error. If not, throw the wrapped exception
(which is the behavior before my changes).
# Current issues
* Only the first validation issue is reported, but this is
unavoidable, since the subsystem parsers throw on the first error
encountered
* This uses xmlschema-walker from Apache XmlSchema[5], which has a
couple of bugs that will need to be fixed and released (or forked)
* Only errors reported by throwing Exceptions returned by ParseUtils
are pretty-printed. Exceptions that come from within STAX reader
aren't yet handled (for example, a misplaced element in the logging
parser causes reader.handleAny() to be called[6], which triggers an
unwrapped exception)
* vdx itself is far from complete[7] - that work is pending the
outcome of this discussion
# Next steps
As I said above, the first question to answer is: is this an
interesting feature that you would like to see completed? If so, I'm
willing to continue working on this, and would be happy to discuss
here or on JIRA/HipChat as appropriate.
[1]: http://elm-lang.org/blog/compilers-as-assistants
[2]: http://rigsomelight.com/2016/05/17/good-configuration-feedback-is-essenti...
[3]: https://github.com/projectodd/vdx
[4]: https://github.com/tobias/wildfly-core/commit/b4d03897a6ea1b8c786d983da3b...
[5]: https://ws.apache.org/xmlschema/
[6]: https://github.com/wildfly/wildfly-core/blob/2.x/logging/src/main/java/or...
[7]: https://github.com/projectodd/vdx/issues
8 years, 4 months
Wildfly JAAS HttpServletRequest.login does not keep logged in for subsequent requests
by Jan-Willem Gmelig Meyling
Hi everyone,
I encountered some problems when trying to use the Servlet 3.0 login method in Wildfly 10. After logging in using `HttpServletRequest.login(String, String)`, using the code below, on successive requests I still get a Basic Authentication prompt.
I have also found the same issue on the JBoss developer forum in a post that goes back to september 2015: developer.jboss.org/thread/262640?start=0&tstart=0 <http://developer.jboss.org/thread/262640?start=0&tstart=0> .
Why is the `login` function not working in my configuration?
My endpoint:
@POST
@Path("login")
@Consumes(MediaType.APPLICATION_JSON)
public void login(@Valid LoginRequest loginRequest) {
try {
User user = userController.findUserByUsername(loginRequest.getUsername()).orElseThrow(NotFoundException::new);
httpServletRequest.login(loginRequest.getUsername(), loginRequest.getPassword());
log.info(securityContext); // not null now!
}
catch (ServletException e) {
throw new NotAuthorizedException(e.getMessage(), e, AuthenticationHeaderFilter.CHALLENGE);
}
}
And my `jboss-web.xml`
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.jboss.com/xml/ns/javaee
http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd">
<security-domain>MyRealm</security-domain>
</jboss-web>
And my `web.xml`:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>MyRealm</realm-name>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
<security-constraint>
<display-name>Authenticated content</display-name>
<web-resource-collection>
<web-resource-name>Authentication required</web-resource-name>
<url-pattern>/api/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<display-name>Anonymous content</display-name>
<web-resource-collection>
<web-resource-name>Exclude from Security</web-resource-name>
<url-pattern>/api/me/login</url-pattern>
</web-resource-collection>
</security-constraint>
Furthermore, I declared my security domain as follows in standalone.xml
<security-domain name="MyRealm" cache-type="default">
<authentication>
<login-module code="Database" flag="required">
<module-option name="dsJndiName" value="java:jboss/MysqlXADS"/>
<module-option name="principalsQuery" value="SELECT password AS Password FROM user WHERE username = ?"/>
<module-option name="rolesQuery" value="select 'user' as Role, 'Roles' as RoleGroup union select 'admin' as Role, 'Roles' AS RoleGroup from user where admin is true and username = ?"/>
</login-module>
</authentication>
</security-domain>
I have also posted the question on Stackoverflow, so any answer posted there will receive the bounty points: http://stackoverflow.com/questions/38896538/httpservletrequest-login-does... <http://stackoverflow.com/questions/38896538/httpservletrequest-login-does...>
Thanks in advance!
Jan-Willem Gmelig Meyling
8 years, 4 months
ConcurrentAccessTimeoutException using producer in stateful bean
by arjan tijms
Hi,
I came across a situation where a ConcurrentAccessTimeoutException is
thrown on WildFly 10.0.0 and 10.1cr1 when an @Stateful @ViewScoped bean
contains a CDI producer.
In short, there are 3 beans all @Stateful @ViewScoped. Beans 1 and 2 are
injected in bean 3.
Bean 1 contains a CDI producer.
Bean 2 is injected with a type from said producer.
The following causes a ConcurrentAccessTimeoutException to be thrown:
bean3.somemethod:
tx start
access stateful bean 1
access stateful bean 2
(from statefull bean 2): access injected type that causes producer from
bean 1 to be called
tx end
If the call to stateful bean 1 is omitted, the producer is called normally
when bean 2 accesses the injected type.
If bean 2 is injected directly with bean 1, then bean 1 can be accessed
without any ConcurrentAccessTimeoutException being thrown.
The code runs fine on WildFly 8.2.
I'll do some further digging, but wonder if this problem rings any bells.
Could it be that CDI obtains a reference to the stateful bean in such a way
that the implicit EJB interceptor doesn't see it's still within the same
TX? But since there's no call to bean 1 in progress at that point, should
this even matter?
Kind regards,
Arjan Tijms
8 years, 4 months
Set descriptor property replacement setting in jboss-web.xml?
by arjan tijms
Hi,
I wonder if it would make sense to be able to set the
"spec-descriptor-property-replacement" from standalone.xml in jboss-web.xml
(or other jboss specific files for e.g. a .ear)?
This is one of the few settings that we always need to change and it
prevents devs using a stock JBoss/WildFly to deploy most of our
applications to. Would be really great if this could be switched from
within the application archive.
Kind regards,
Arjan Tijms
8 years, 4 months
Need write to standalone.xml after parsing
by Stan Silvert
The Keycloak server is currently configured via a keycloak-server.json
file. We are converting this to configuration through
standalone.xml/domain.xml.
To automatically upgrade, I need to read keycloak-server.json and write
back to standalone.xml. I can easily add the operations to do this at
parse time. The parser has this method:
@Override
public void readElement(final XMLExtendedStreamReader reader, final
List<ModelNode> list) throws XMLStreamException
So one way to do this is to parse keycloak-server.json at this time and
add operations to the list.
That puts everything into the management model. But nothing will be
written to standalone.xml unless someone manually does a write operation
from CLI.
So my question is, what is the best way to accomplish this? Is there a
good, safe way to manually trigger a flush to standalone.xml at this
point or at some later point during startup?
Stan
8 years, 4 months
enhancement: layers.conf can use maven artifacts
by Bill Burke
I was thinking about how installation, patching, and distribution could
be made easier and more flexible. What if layers.conf could reference a
maven artifact?
layers=org.keycloak:keycloak-modules:1.5
The module layer of keycloak could be stored in a maven repo.
Upgrading/patching could be just bump the version in layers.conf. If
layers.conf also honored the list as a priority list, listed layers
could override previously listed layers.
If module layer the module defs also reference their jars as maven
artifacts, patches are really small as they are just module.xml files.
Bill
8 years, 4 months
Re: [wildfly-dev] Need write to standalone.xml after parsing
by Ken Wills
On Wed, Aug 3, 2016 at 2:02 PM, Stan Silvert <ssilvert(a)redhat.com> wrote:
> On 8/3/2016 2:49 PM, Ken Wills wrote:
>
> On Wed, Aug 3, 2016 at 8:53 AM, Stan Silvert <ssilvert(a)redhat.com> wrote:
>
>> The Keycloak server is currently configured via a keycloak-server.json
>> file. We are converting this to configuration through
>> standalone.xml/domain.xml.
>>
>> To automatically upgrade, I need to read keycloak-server.json and write
>> back to standalone.xml. I can easily add the operations to do this at
>> parse time. The parser has this method:
>>
>> @Override
>> public void readElement(final XMLExtendedStreamReader reader, final
>> List<ModelNode> list) throws XMLStreamException
>>
>> So one way to do this is to parse keycloak-server.json at this time and
>> add operations to the list.
>>
>> That puts everything into the management model. But nothing will be
>> written to standalone.xml unless someone manually does a write operation
>> from CLI.
>>
>>
> Not sure if this is exactly what you're looking for, but subsystems /
> extensions usually register an XMLElementWriter for themselves to handle
> this, see for exmaple:
>
>
> https://github.com/wildfly/wildfly/blob/9de9217e0106da10c7d05228bcf0559c8...
>
> Ken
>
> My problem is that the XMLElementWriter is never called during startup.
> I would like it to be called after the management model is read from
> standalone.xml but before deployments are handled.
>
Hmm. Not sure about that one, I"ll have a look.
PS: Sorry for replying only to you, I mean't to include the list too. [cc:
wildfly-dev added back.]
8 years, 4 months
