WildFly EE Concurrency Utilities (JSR 236) Enhancements
by Eduardo Martins
Last slide of my presentation at Brno, wrt WildFly support for JSR 236, I presented possible future directions to extend the feature set, and now I would like to discuss these and understand which are truly desired:
* Fork/Join
Requires forking the JSR 236 RI and hacking the ManagedThreadFactory implementation
* Distributed task execution
The specification goes the extra mile defining it, but this may require big dev effort compared to its real life utility
* Re-usage by other module/extensions:
Provide Batch executors?
Replace executors handling EJB @async?
* Customizable ContextService
Configurable set of ContextHandleFactories to use for each ContextService instance, allowing the customisation of which context data should be propagated.
There are minimal code changes at the ConcurrentContext needed, so the major effort will be at the management operations.
—E
10 years, 9 months
JNDI and java:comp, slimming the server, and componentless naming contexts
by David M. Lloyd
I think we need to look into a small redesign of how we handle
java:comp, java:module, and java:app. The reasoning comes in three parts:
* Various specs require that certain names be bound globally across all
of java:comp.
* Various other specs implicitly expect to be able to query these
globally bound names even if there is no actual component context.
* Duplicating these bindings uses more resources than are necessary.
Therefore I think we need to make a small change - we should have a
"global" version of the three context-specific namespaces that act as a
sort of fallback if there's no (component|module|app)-specific name
bound at a location. This allows us to do a few things:
* Satisfy the spec issues
* Reduce resource overhead
* Allow globally-configured things in the management config to bind to
component/module/app-specific namespaces
Thoughts?
--
- DML
10 years, 9 months
JBoss Modules canonical sample
by Arun Gupta
I'm trying to create a simple sample that shows JBoss Modules and
source code is checked in at:
https://github.com/arun-gupta/wildfly-samples/tree/master/jboss-modules
Also created the following directories in "modules":
modules/org
modules/org/samples
modules/org/samples/greet
modules/org/samples/greet/greet-api-1.0-SNAPSHOT.jar
modules/org/samples/greet/greet-simple-1.0-SNAPSHOT.jar
modules/org/samples/greet/modules.xml
modules.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="org.samples.greet">
<resources>
<resource-root path="greet-api-1.0.0-SNAPSHOT.jar" />
<resource-root path="greet-simple-1.0.0-SNAPSHOT.jar" />
</resources>
</module>
The web application accesses a service from API module but no results
are returned. No error logs, no service not resolved error, nothing.
Seems like I'm doing something incorrectly basic. Suggestions how to
debug this further ?
Thanks,
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
10 years, 9 months
wildfly-maven-plugin 1.0.1.Final Released
by James R. Perkins
I wanted to start doing more releases of the plugin, but I wasn't
expecting one this soon :)
With the release of 1.0.0.Final I forgot to change the version that gets
downloaded for the run and start goals. This releases fixes that as well
as includes a hack for class loading issues and in shutdown hooks[1].
Other than those two things there were no other changes for this release.
[1]: https://issues.jboss.org/browse/JBASMP-61
--
James R. Perkins
Red Hat JBoss Middleware
10 years, 9 months
http-executor
by Hamed Hatami
Hi,
I want to use http-executor for my http-listener but it can not possible
what is the solution?
Regards,
Hamed Hatami.
10 years, 9 months
Netty vs. Undertow
by Jaromir Hamala
Hi,
first of all: Congratulations on the WildFly 8 release! I've been watching
the development closely and I'm very excited to get my hands dirty with it!
There is one thing I don't quite understand: What is a relation between the
Netty and Undertow? My understanding is they have very similar goals yet
the Undertow is a completely different project. What have been the main
drivers to write the Undertow from scratch for WildFly rather than bulding
on top of Netty?
I apologize if this is a wrong mailing-list; I appreciate if you could
point me to a better direction!
Cheers,
Jara
--
“Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.”
Antoine de Saint Exupéry
10 years, 9 months
Adding Wildfly to the TechEmpower Web Framework Benchmarks
by Cody Lerum
I've had this queued up for a bit but Stuart suggested I hold off
until Wildfly went final so here it is.
Some of you are probably aware of a Web Framework Benchmark project
that is being put on by TechEmpower
(http://www.techempower.com/benchmarks/). They are currently up to the
8th round with 90 participating "frameworks". Undertow as been around
for a few rounds and is routinely at or near the top of the charts.
My goal here is to incorporate EE7 into these results with Wildfly
providing the implementation. There are a lot of different ways to go
here, but my preference is to stay portable with the application so
that if another EE7 implementation wanted to use the same code it
would be an apples to apples comparison. IMO this means for example
that it shouldn't dip down into undertow/hibernate/resteasy/etc
specific features that wouldn't be available on other application
servers. Stick to EE7 API.
There currently are 6 tests
1. Plaintext: Simple "Hello World!" Text response. Not that
interesting and not dynamic. Implemented via JAX-RS.
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
2. JSON Serialization: "Hello World" placed into a new object and then
serialized out to JSON. Again not really a real world thing since
nothing dynamic is happening here. Implemented via JAX-RS.
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
3. Single Query: Select a single random result from a database and
serialize out to JSON. First real world test. Implemented via JAX-RS,
CDI, JPA. https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
4. Multiple Queries: Select a specified number of random results from
database one by one. Add to list and serialize out to JSON.
Implemented via JAX-RS, CDI, JPA.
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
5. Data Updates: Select a specifed number of random results from
database one by one and update a value on each of them. Then return
the result via JSON. Implemented via JAX-RS, CDI, JPA.
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
6. Fortunes: Select all from database and store in a list. Add a new
result and sort. Display sorted results as an html table. Implemented
via JSF, CDI, JPA.
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
Since 1 and 2 are handled so well by undertow and really aren't
anything someone would do real world with an application server I
could see dropping them and just not participating in those tests.
Unless anyone thinks differently.
On the other tests it would be helpful if you could review the code to
see if there are better/faster ways to accomplish the same tasks
without dipping into implementation specific features that would not
be portable.
Thanks!
-C
10 years, 9 months
cli variables
by Alexey Loubyansky
There is this issue to provide CLI preferences
https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
mainly this part
"prod-db = /subsystem=jadada/database=jadada/
so you could call prod-db:read-resource"
I'd like to get some opinion on the way it's gonna be implemented (and
what I've done so far on a local branch).
So, to address that I introduced variables. A variable starts with a $,
e.g. $prod_db. (Using simply prod_db is not a good idea since it might
conflict with actual parts of the paths, names, etc)
Variables can be introduced with
[disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
Read with
[standalone@localhost:9990 /] echo prod_db
/subsystem=datasources/data-source=ExampleDS
And unset with
[standalone@localhost:9990 /] unset prod_db
'echo' without parameters will list all the variables and their values,
'set prod_db=' will have the same effect as 'unset prod_db',
set/echo/unset will work with and w/o '$' prefix, tab-completion works
everywhere.
The variables may appear in:
- operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
- operation names, e.g. $prod_db:$op(include-runtime=true);
- operation parameter names and values, e.g.
$prod_db:$op($param=$param_value);
- the same for commands.
Tab-completion helps complete the names as long as you type in '$' and
then the rest of the line after the variable as usual.
Variables added during the session are not persisted anywhere. But I've
added .jbossclirc file. This file can be located in the current
directory, wildfly home bin directory or specified with a system
property. The content of the file is usual CLI commands and/or
operations. So, the variables could be initialized there. This file, if
located, will be executed before the CLI session (interactive or not)
starts (but also after the system properties specified with --properties
are set).
As a side effect, '$' is now a special character and will have to be
escaped. Otherwise the CLI might complain about an unresolved variable.
So, this could potentially cause problems for existing scripts using $.
Note, most of this replacement stuff can already be done with system
properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
won't be affected, of course).
And for now I've made variable names follow the rules for Java identifiers.
Any remarks, objections or suggestions?
Thanks,
Alexey
10 years, 9 months
