Implementing enforce-victims-rule in wildfly builds
by David Jorm
Hi All
First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation:
http://www.victi.ms/about.html
enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central:
http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi...
Please see the README.md and sample app here for configuration details:
https://github.com/victims/victims-enforcer
I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database.
What do people think? Is this something you'd consider implementing?
Thanks
--
David Jorm / Red Hat Security Response Team
9 years, 9 months
Feature showcasing
by Jason Greene
One thing I think we should do for one of the Betas is to showcase some of the new features in WildFly 8. I am hoping for a volunteers to write up a blog or article by then which does a walkthrough of the feature.
So like as an example, the EE concurrency APIs are new to Java EE7, and it would be nice to show how they could be used with the Beta to build interest and momentum for the eventual final release.
Let me know if you are interested!
Thanks
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 10 months
Package name
by Tomaž Cerar
Hi,
What should be package name for new stuff being added to WildFly?
org.wildfly.<subsystem-name>
or
org.wildfly.as.<subsystem-name>
or something else?
I would go for org.wildfly.<subsystem-name>
this mostly applies to new subsystems and as we agreed we won't rename
packages for existing code until it break compatibility.
--
tomaz
9 years, 10 months
duel between JPA use of ClassFileTransformer and CDI implicit/explicit Bean Manager (why can't we just get along)...
by Scott Marlow
For application deployments that use ClassFileTransformer to
enhance/rewrite entity classes, we start the persistence unit service
(PersistenceProvider.createContainerEntityManagerFactory()) during the
Phase.FIRST_MODULE_USE (before any application classes have been loaded).
For application deployments that have an explicit CDI Bean Manager,
there is a beans.xml that means the ClassFileTransformer will not work,
since the CDI Bean Manager will scan all of the application classes
(loading them), before the persistence unit service is started (so that
the persistence provider can use CDI in entity listeners).
The same is also true for implicit CDI Bean manager support [1], expect
all application deployments that contain an ejb3 module, will be wired
for CDI (meaning JPA ClassFileTransformer support will work even less).
I raised this on the JPA 2.1 EG [2] in response to an earlier
discussion, about switching to a two phase approach to address problems
like this (didn't discuss CDI implicit support then but am raising that
now).
[3] talks about why we don't create the CDI bean managers before the
Install phase (would cause all application classes to be read which
breaks JPA ClassFileTransformer use).
[4] is for adding implicit CDI support but is blocked currently by [5].
We can add persistence unit flags (jboss.as.jpa.classtransformer=false)
for disabling JPA ClassFileTransformer support as a workaround but that
doesn't help enough since many deployments will have implicit CDI
support enabled (since they contain EJB modules). We could add a way to
disable implicit CDI support as another workaround for deployments that
want to use ClassFileTransformer.
I'm not yet seeing a proper fix for this. Anyone else?
Scott
[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
[2]
https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/m...
[3] https://issues.jboss.org/browse/WFLY-1322
[4] https://issues.jboss.org/browse/WFLY-476
[5] https://issues.jboss.org/browse/WFLY-1463
9 years, 11 months
Call For Help (Testsuite)
by Jason Greene
We still have a number intermittent test failures that have been around for over a year now. I'm asking for everyone's help in doing what we can to make them stable. If you submit a PR, and you see what looks like an intermittent failure, can you do some investigation and report your findings even if it is not your area? It would be awesome if you can report what you find to the mailing list, and rope in help.
Nearly all of these seem to only occur when virtualization is involved, so if need be we can work out a plan to create either a special run to capture diagnostic info, or I can give access to a dedicated slave.
If anyone has any further ideas on how to tackle these issues I am all ears.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 11 months
How to expose javax.batch classes to all deployments?
by Cheng Fang
I'm trying to integrate javax.batch API (part of EE 7) into WildFly.
I've added a couple of batch-related modules, updated build module, and
also added javax.batch.api module to javaee.api module's dependency
list, hoping that would automatically expose javax.batch to all
deployments. javax.batch is required API in EE 7 full profile.
This is how the part of javaee.api module.xml I touched:
<dependencies>
<module name="javax.activation.api" export="true"/>
<module name="javax.annotation.api" export="true"/>
<module name="javax.batch.api" export="true"/>
<module name="javax.ejb.api" export="true"/>
...
When deploying a webapp that uses javax.batch, I'm still seeing class
not found errors from Weld (these batch classes are annotated with @Named)
Is there anything else I need to change to make javax.batch classes
available to all deployments?
Thanks for the help.
java.lang.LinkageError: Failed to link
com/ibm/jbatch/tck/artifacts/specialized/StartLimitStateMachineVariation1Batchlet
(Module
"deployment.jslxml_web_vehicle.ear.jslxml_web_vehicle_web.war:main" from
Service Module Loader)
at
org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75)
[jboss-modules.jar:1.2.2.Final]
at org.jboss.modules.Module.loadModuleClass(Module.java:526)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119)
[jboss-modules.jar:1.2.2.Final]
at java.lang.Class.getEnclosingMethod0(Native Method) [rt.jar:1.7.0_25]
at java.lang.Class.getEnclosingMethodInfo(Class.java:959)
[rt.jar:1.7.0_25]
at java.lang.Class.getEnclosingConstructor(Class.java:1035)
[rt.jar:1.7.0_25]
at
org.jboss.weld.util.reflection.Reflections.isNonStaticInnerClass(Reflections.java:388)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
org.jboss.weld.util.Beans.isTypeManagedBeanOrDecoratorOrInterceptor(Beans.java:503)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:226)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:74)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:72)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
[weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
[rt.jar:1.7.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[rt.jar:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.NoClassDefFoundError: javax/batch/api/AbstractBatchlet
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
[rt.jar:1.7.0_25]
at
org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422)
[jboss-modules.jar:1.2.2.Final]
... 23 more
Caused by: java.lang.ClassNotFoundException:
javax.batch.api.AbstractBatchlet from [Module
"deployment.jslxml_web_vehicle.ear.jslxml_web_vehicle_web.war:main" from
Service Module Loader]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374)
[jboss-modules.jar:1.2.2.Final]
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119)
[jboss-modules.jar:1.2.2.Final]
9 years, 11 months
JSR 236 support landing
by Eduardo Martins
I opened https://github.com/wildfly/wildfly/pull/4705 , which provides both the JSR 236 a.k.a. EE Concurrent implementation and it's plugging into Wildfly EE subsystem. In a first short summary this allows EE components to retrieve (through @Resource or JNDI lookup) and use the specs default managed objects (managed executor services, managed thread factory and managed context service).
There are still a few things to discuss, but let me first explain what's in the PR, making life easier for the reviewer(s):
1) ee-concurrent module - the JSR 236 Impl.
While thread factory and context service are quite trivial, the executors are a bit more complex, due to the spec decision to introduce the concepts of ManagedTask (+ related ManagedTaskListener), and Trigger scheduling, which go way beyond what in java.util.concurrent and IMHO just complicate the impl without providing key functionality.
Anyway what I did was a TaskDecorator family of ThreadPoolExecutors extensions, which simply are aware of tasks implementing specific interfaces, and delegate to these tasks the decoration of RunnableFutures. Then there are the managed executor services which wrap the original tasks, which contain all the logic to support the fancy features of the API, and delegate to the TaskDecorator executors. The module contains an extensive unit test suite, which (I think) validates every possible use case of the API.
2) "concurrent" package in ee extension - the deployment unit processor, msc services, jndi bindings and interceptors
The ee-concurrent does not includes any logic wrt setting the invocation context, that is provided in the ee extension through interceptors. I added another list of interceptors to the EE components, and when creating contextual objects these are used + a terminal invoking interceptor that uses reflection to the call, for instance for Runnable#run(). There is also a new ConcurrentContextInterceptor that goes into almost every of the other lists of interceptors, which is responsible for capturing the data needed to recreate context, and also to locate the actual JSR 236 managed objects, since the ones coming from jndi are just front ends not bound to a specific component (for instance one EJB may be injected with the DefaultManagedExecutorService, but if the context switches to another component than invoking the executor must then consider the actual component in context, not the one which did the lookup).
Additionally, there is a DUP that for each EE component adds its own JSR 236 managed objects, is responsible for doing the jndi bindings and interceptor setup, but note that the TaskDecorator executors, who actually have the execution resources such as threads, are shared by all, thus added along the subsystem. Also please note that right now there is no subsystem management wrt JSR 236 (that's the WFLY-238 last piece to be worked out next), there are only the default managed objects mandated by the spec, and without configuration, but still a draft of what I think we should have can be seen at https://github.com/wildfly/wildfly/pull/4705/files#diff-76
3) Integration tests - I added one for ManagedExecutorService and another for ManagedScheduledExecutorService, which both do a similar test, an EJB that submits/schedules a task, and upon task execution it's confirmed that security, class loading, naming and transaction contexts are correctly set and working, which are the ones required by the spec. I guess more should be added, but these already cover most of the functionality , good enough for the initial PR.
To discuss:
a) ee-concurrent + ee versus ee/extension + ee/concurrent?
Tomaz recently brought this and the package/module names subjects to the mail list, but I don't think there was any real agreement on any. I think it's the best time for making "ee" just a maven parent, and move its sources to ee/extension, and then drop concurrent there too, instead of adding this new top level ee-concurrent maven module. Obviously we could instead just merge everything into "ee", but then we will never accomplish the EE breakup, and it's probably going to get messy in the future.
b) security context interceptor
The interceptor that restores the security context depends on picketbox, and it shouldn't be on wildly-security, since an EE->Security dependency brings a circular dependency, so there is an EE->Picketbox dependency now, is this an issue or undesirable? Or perhaps there is an alternative to restore the security context that I'm not aware? The interceptor can be seen at https://github.com/wildfly/wildfly/pull/4705/files#diff-62
c) More interceptors?
The current interceptors used can be seen at https://github.com/wildfly/wildfly/pull/4705/files#diff-55 , these are the ones the integrations tests required for everything there to work. Are there other interceptors that should be added?
d) DUP phase
I added the DUP to the end of the queue in the POST_MODULE, because the DUP needs EE components with the views already set (for an easy plugging of the concurrent context interceptor), and that seemed the safest place to put it into. Sincerely dunno if that's the best choice…
e) Go to the beach? It's touching 40ºC here lately!
--E
9 years, 11 months
Test run with standalone-jbossweb configuration
by Chao Wang
Hey all,
For the tests inside wildfly/web, currently they run peacefully with
undertow (all passed). However, if I change the test Config file
arquillian.xml and switch serverConfig back to standalone-jbossweb.xml
to run them? I got an unexpected failures list:
Tests run: 209, Failures: 10, Errors: 95, Skipped: 9
The line I changed in integration/basic/src/test/config/arq/arquillian.xml :
<property
name="serverConfig">${jboss.server.config.file.name:standalone.xml}</property>
modify to:
<property name="serverConfig">standalone-jbossweb.xml</property>
Then inside /testsuite, run $ mvn clean install -Dts.noSmoke -Dts.basic
Is this reasonable action to switch server configuration file for tests
like this? Or an expected result and its forbidden to make such change?
Thanks,
Chao
9 years, 11 months
