EntityManager is not injected inside a Jboss module
by alex orl
I'm working with jboss wildfly 9. I have a provider deployed as module into the modules directory.Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.Now i m facing the real problem: it seems i cannot use the PersistenceContext annotation to inject the entity manager into my EntityManager variable wich is always null. Why i cannot inject the a context into a jar modules? What am i wrong?
11 years
WF10 CR1 Delay - Tentatively Moved to the 16th
by Jason Greene
Hello Everyone,
As mentioned Thursday, the CR1 release was delayed on some intermittent failures in our main test suite related to a new messaging update that resolves a number of reported bugs. The good news is that the those have been resolved, but we are still seeing some related regressions in the EE TCK test suite. I have tentatively pushed the date for CR1 to Wed the 16th.
I apologize for the delay, but promise to provide updates along the way.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years
Upcoming WF10 Dates (Reminder)
by Jason Greene
Hello Everyone,
First off, I just wanted to say thank you everyone for hitting the major deliverables for the WF10 Beta release that went out over the weekend!
The remaining schedule for WF10 is as follows:
WildFly 10 CR1 - September 9th
WildFly 10 CR2 (if needed) - September 16th
WildFly 10 Final - October 8th (contigent on certification)
So that means we have 26 days (17 workdays left) to:
- Stabilize features brought in during Alpha/Beta cycle
- Finish/polish compatibility (transformers, management ops, etc)
- Upgrade all components to Final (preferable) or CR (exceptional)
- Fix broken and/or intermittent tests relating to the above
- Address any other loose ends
We should avoid (if possible) introducing new major features to allow for enough time to do the above. Let me know ASAP if thats a problem.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years
CLI batches in control flow blocks
by Alexey Loubyansky
Hello everyone,
I've been thinking about changing how the bodies of if-else and
try-catch-finally are treated by the CLI.
Up until now every control flow block (i.e. between if and else, between
else and end-if, etc) was executed as a batch. So, when a block was
selected for the execution, the CLI would enter the batch mode and
proceed adding operations (and commands translated to operations) to it.
If a command can't be translated to an operation, it would be executed
outside the batch immediately (that's done for commands like cd, ls,
etc). After the last line of the body processed, the batch (if not
empty) is executed.
But this doesn't work when mixing operations with shutdown or reload
commands (they do translate to operations but they have additional logic
related to re-connecting). shutdown/reload will be executed outside the
batch and before the batch is complete.
Currently open issues for this
https://issues.jboss.org/browse/WFCORE-876
https://issues.jboss.org/browse/WFCORE-533
So, I think it was a mistake to execute the bodies of control flow
blocks as batches. It would be better leave them as usual sequences of
command lines and if the user wants a batch, he/she could add batch
command explicitly.
I wanted to ask for opinions. Could we make this change in WildFly 10?
Thanks,
Alexey
11 years
CLI Non-Interactive Output Changes
by Edward Wertz
Hello All,
I've been doing some work on the non-interactive mode of the CLI, when using --file or --commands, and since the current version of the work changes the output slightly I'd like to get some opinions on it. The changes are necessary in order to pass the non-interactive commands through the AESH console system, which enables additional functionality like the history file and 'alias' command. If not done, the non-interactive mode functionality won't behave the same as the interactive mode. Commands handled by AESH like 'alias' will be missing entirely, and non-interactive commands won't show up in the cli history file. If AESH is expanded further in the future, more commands will be inaccessible in non-interactive mode.
The existing output for this mode only includes the command output. It doesn't include the commands entered, or the interactive command prompts like '[disconnected /]'. Exampled like so:
[joe@localhost bin]$ ./jboss-cli.sh --commands=version,connect,version,"echo tim"
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
tim
The new output, as it exists right now, contains the command and it's output. Like so:
[joe@localhost Changed Output]$ ./wildfly-cli-2.0.0.CR1-SNAPSHOT-client-new.jar --commands=version,connect,version,"echo tim"
WARN: can't find jboss-cli.xml. Using default configuration values.
version
JBoss Admin Command-line Interface
JBOSS_HOME: null
JBoss AS release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
connect
Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
version
JBoss Admin Command-line Interface
JBOSS_HOME: null
JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
echo tim
tim
'version', 'connect', 'version', and 'echo tim' lines are now in the output, along with some information messages. I think this makes the output more useful, since the user can see which command was entered before the output or possible error occurs. It shouldn't have an impact on existing scripts, because the output still contains the expected output from any command and still ends with the last command output, so if someone is doing string analysis I wouldn't expect it to fail.
I'd actually prefer to extend this change and add the command prompts into the output as well. Which would look like this:
[joe@localhost bin]$ ./jboss-cli.sh --commands=version,"alias v=version",connect,v,"echo tim"
[disconnected /] version
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
[disconnected /] alias v=version
[disconnected /] connect
[standalone@localhost:9990 /] v
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
[standalone@localhost:9990 /] echo tim
tim
[standalone@localhost:9990 /]
This, to me, adds more information to the output making it more useful. I like the idea of the non-interactive mode imitating the interactive mode closely and essentially pretending to be a user, and this output is almost identical to a user entering these commands one at a time. It does, however, modify the end of the output stream which could break analysis scripts. A contains would be fine, but an ends-with would be broken because of the last prompt.
Normal interactive mode output is unchanged. This will only effect '--file=' and '--commands=' output.
Thoughts?
Joe Wertz
11 years
WildFly PR testing notification changes
by Tomaž Cerar
Hey guys,
this mail is just heads up about recent changes to our CI <--> GitHub PR
integration.
As we started adding more and more different jobs to test each PR number of
comments
on each PR became almost like spam as each job added one comment when it
started
and second one with report of the build.
With changes we did in past few weeks, we now have:
- all build statuses only as part of github PR status check [1]
- comments get added only when there is build failure
- usual, retest this please & friends still work as they use to
- *in testing* auto lableling / unlabling of rebase-this/fixme lables.
So to see the actual status of the builds and if all checks passed,
you will need to look at the pull request itself and not only mail
notifications like till now.
--
tomaz
[1]
https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
11 years
Permissions for Arquillian in test deployments
by Ondrej Kotek
Hi,
I am investigating failing tests in WildFly and WildFly Core testsuites [1,2] when security manager is enabled.
There are test cases using org.jboss.as.arquillian.container.ManagementClient in non-runAsClient mode. While running with Java Security Manager without AllPermission assigned, the test cases fail. This is caused by insufficient permissions assigned to deployments -- deployments require permissions that Arquillian uses to create connection for ManagementClient, e.g. read FilePermission for modules/system/layers/base/org/jboss/xnio/nio/main/* (XNIO module), connect,resolve SocketPermission, * * MBeanPermission, getClassLoader RuntimePermission.
There are probably about 27 such tests ([1,2] and other related issues).
Adding permissions for Arquillian to a deployment could mask bugs related to such permissions. The demand of permissions for Arquillian should be shielded by Arquillian. Is it doable?
In case it is not doable, there are several other ways how to solve adding permissions for Arquillian:
* Adding such permissions to minimum-permissions set in security-manager subsystem
* Adding such permissions to each permissions.xml
* Creating a custom permission containing such permissions and adding it to each permissions.xml
Which one do you consider the most correct? Or, is there another way?
[1] https://issues.jboss.org/browse/WFLY-5169
[2] https://issues.jboss.org/browse/WFCORE-848
Thanks,
Ondrej Kotek
11 years
Perf tip for folks writing management code
by Brian Stansberry
If you're writing code that manipulates potentially large chunks of the
management model, be cautious of the following:
1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource)
This makes a deep clone of all the DMR model nodes in the given resource
tree. That may be a good thing, but is expensive with large trees, so be
aware.
2) org.jboss.dmr.ModelNode.asPropertyList()
For each Property in the returned list, the 'value' member is a deep
clone of the corresponding element in the original model node. So, again
expensive with large trees, so be aware.
You can replace this:
for (Property prop : node.asPropertyList() {
String name = prop.getName();
ModelNode value = prop.getValue();
... do something with name and value
}
with
for (String name : node.keys()) {
ModelNode value = node.get(name);
... do something with name and value
}
I'll fix a few high impact cases of this usage.
Please resist the urge to send in lots of refactoring PRs until WF 10 is
done. ;)
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
11 years
Adding permissions to tests
by Stuart Douglas
Hi everyone,
There have been a few PR's lately that add permissions to tests via
permissions.xml so that they pass under the security manager.
The security manager focus is great, however if you are submitting a PR
like this it would make reviewers jobs much easier if you include a simple
justification of why the test needs the permission.
Basically if we have a permissions problem in our code we should not just
be covering it up via permissions.xml in our tests, and as a reviewer is
very hard to tell which permissions are genuinely needed.
Ideally this will take the form of the problematic stack trace in the PR,
although if the test just needs a permission to do something test specific
(like reading the ts.timeout.factor property) then a simple comment will
suffice.
Thanks,
Stuart
11 years
