Custom wildfly subsystem deployer
by Dejan Kitic
Hi,
First of all my apologies, if I am asking the question in wrong place,
though my gut feeling tells me that people on this list would know the most
about this matter.
I am trying to write my own subsystem, and have wrote most of it, using
https://docs.jboss.org/author/display/AS72/Extending+JBoss+AS+7 and maven
archtype there.
I have my own annotation, which user can add onto the attribute of EJB or
CDI bean, and deployment processor for my subsystem finds all classes with
this annotation.
>From my understanding inside deployment processor executed during
Phase.PARSE, getAttachment(Attachments.ANNOTATION_INDEX) will enable me to
find all classes with my annotation, without loading the classes (jandex).
After finding them all, I am trying to modify the class to inject instance
to that annotated field with value that has been created in my subsystem
for that deployment.
I think options are to rely on Weld, or modify bytecode to set this field
with my value stored in my subsystem when class is instantiated.
If I change phase
Am I going in the right direction with this, what would be recommended way
to do something like this? Any pointers would be welcome.
Regards,
Dejan
12 years, 1 month
Missing implementatoin class for WebSocket test
by Arun Gupta
Trying to run a simple WebSocket test from:
https://github.com/arun-gupta/javaee7-samples/tree/master/websocket/binary
But this is throwing the following exception:
Running org.javaee7.websocket.binary.test.WebsocketByteBufferEndpointTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.055
sec <<< FAILURE!
testEndPointByteBuffer(org.javaee7.websocket.binary.test.WebsocketByteBufferEndpointTest)
Time elapsed: 0.023 sec <<< ERROR!
java.lang.RuntimeException: Could not find an implementation class.
at javax.websocket.ContainerProvider.getWebSocketContainer(ContainerProvider.java:73)
at org.javaee7.websocket.binary.test.WebsocketByteBufferEndpointTest.testEndPointByteBuffer(WebsocketByteBufferEndpointTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
What is missing ?
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
12 years, 1 month
Re: [wildfly-dev] Debugging transformers and reverse controller check
by Kabir Khan
Hi,
I am forwarding this to the list since it will hopefully help others as well.
Now, the main concept behind this is that CLI scripts written against for example AS 7.1.3 should still work against WildFly 8. The way we did this is the reverse controller checks (crap name, but they were written very quicky before a deadline). They hook into the transformers tests where you boot up the main and legacy controllers with some xml, i.e. not the reject variety which boots them up with an empty one.
So what happens in a typical transformers test when you call KernelServicesBuilder.build() is
1) The xml is parsed into ops by the WF 8 parser
2) We boot up the main controller with the current WF 8 classpath
3) The ops from 1) are transformed into the model version of the legacy controller
4) We then boot up the legacy controller using the old jars using the ops from 3
5) We then boot up another ‘main controller’, using the current WF 8 classpath using the ops from 3- this controller is not used in the rest of the tests, only the ones from 2 and 4
6) Compare the model in the controller from 5 with the model from the controller in 2
The theory is that the ops parsed in 3) are something which would have worked for the old AS version and should still work today, which is what step 5 checks.
LegacyKernelServicesInitializer has a few methods to control what happens at 5 when it cannot work perfectly:
.skipReverseControllerCheck() - this turns off step 5 totally
.configureReverseControllerCheck(AdditionalInitialization additionalInit, ModelFixer modelFixer) and .configureReverseControllerCheck(AdditionalInitialization additionalInit, ModelFixer modelFixer, OperationFixer operationFixer)
The configure varieties are preferred to skip. I’ll try to explain what problems the different parameters to the configure methods are below.
Pass in an AdditionalInitialization.MANAGEMENT, this in some cases is all you need to do if the main kernel services builder is configured with an AdditionalInitialization which does the runtime part of the tests, and helps avoid port conflicts etc. when starting the second controller in 5. In fact, I should probably have made sure that happens by default, at the moment it seems to use one which does the runtime part when .configureReverseControllerCheck() has not been called, or is called with a null additionalInit.
If that does not solve it and you get a problem somewhere in ModelTestUtils.compare() this means that the ‘reverse controller’ booted, but its model differs from the main controller model. This can be fixed by passing in a ModelFixer to fix inconsistencies in the model of the ‘reverse’ controller before the comparison is done. This fixer will be used in step 6. For example, in some cases the ops for the legacy controller change the model slightly, which is often fine, and can be fixed this way.
If the ‘reverse’ controller fails to boot in 5, put a logging breakpoint which prints the stack trace in AbstractOperationContext.executeStep() and figure out the offending operation(s). You can then use the OperationFixer to fix the offending operations. For Infinispan, I don’t remember the details but I think you had something called segments and now you have virtual-nodes (or the other way round), and some slightly complex conversion was done between the two. So if step 3 changed virtual-nodes in the ops to segments, and this is then attempted used in step 5 fixing these operations is a valid fix since segments is deprecated in the current model.
On 19 Nov 2013, at 01:07, Richard Achmatowicz <rachmato(a)redhat.com> wrote:
> Hi Kabir
>
> I have been debugging some transformer code and came across this in SubsystemTestDelegate:
>
> SubsystemTestDelegate.LegacyKernelServicesInitializer.skipReverseControllerCheck()
>
> What is the testing concept behind this, in general terms?h
> And behind the notion of "reverse services"?
>
> My transformer tests pass with reverse controller check turned off, and fail with it turned on.
> I'd like to know whether I am allowed to turn it off and under what circumstances.
>
> Richard
12 years, 1 month
NoClassDefFoundError for WildFlyBatchMessages
by Arun Gupta
Running a test from
https://github.com/arun-gupta/javaee7-samples/tree/master/batch/batchlet-...
gives the following error:
14:41:34,818 INFO [org.jboss.as.server] (management-handler-thread -
1) JBAS018559: Deployed "f3b403ce-26a3-4f80-be51-8bb46dccc819.war"
(runtime-name : "f3b403ce-26a3-4f80-be51-8bb46dccc819.war")
14:41:35,067 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner]
(pool-1-thread-1) Failed:
org.javaee7.batch.batchlet.simple.MyBatchletTest.testBatchletProcess:
java.util.ServiceConfigurationError:
javax.batch.operations.JobOperator: Provider
org.jberet.operations.JobOperatorImpl could not be instantiated:
java.lang.NoClassDefFoundError: Could not initialize class
org.wildfly.jberet._private.WildFlyBatchMessages
at java.util.ServiceLoader.fail(ServiceLoader.java:224) [rt.jar:1.7.0_45]
at java.util.ServiceLoader.access$100(ServiceLoader.java:181) [rt.jar:1.7.0_45]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
[rt.jar:1.7.0_45]
at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_45]
at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:57)
[jboss-batch-api_1.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.javaee7.batch.batchlet.simple.MyBatchletTest.testBatchletProcess(MyBatchletTest.java:37)
[classes:]
The workspace was updated a few mins ago.
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
12 years, 1 month
Status of EntityListener CDI Injection
by Jens Schumann
Hi all!
Could you please tell me if it's ok to report bugs for broken EntityListener injection for the current Wildfly 8.0.0 Beta2 SNAPSHOTs? It seems there is still a lot missing, and maybe it's way too early to report bugs.
Thanks,
Jens
12 years, 1 month
Changing one subsystem from another
by ssilvert＠redhat.com
I'm inside a DeploymentProcessor and I want to execute a management
operation on another subsystem. How can I get a
ModelControllerClient in order to do that?
Stan
12 years, 1 month
Property Representation (name/value) pairs in Management model
by Heiko Braun
While working on the console extension mechanism [1], I discovered that we don't use a common representation of properties within the management model. Below are two descriptions of properties (name/value pairs) taken from security domains and server-groups. Server-groups use a addressable resource representations for name value pairs, while security domains use some (bogus?) definition of type=object and value-type=String.
Is it possible to make resources rely on the same representation for properties?
I don't even know how it's currently possible to define a login module option using the CLI today. Non addressable resources cannot be *:add()'ed, can't they?
/profile=default/subsystem=security/security-domain=other/authentication=classic/login-module=RealmDirect
"module-options" => {
"type" => OBJECT,
"description" => "List of module options containing a name/value pair.",
"expressions-allowed" => true,
"nillable" => true,
"value-type" => STRING,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
/server-group=*
"system-property" => {
"description" => "A list of system properties to set on all servers in this server-group.",
"model-description" => {"*" => {
"description" => "A system property to set on all servers in this server-group.",
"access-constraints" => {"sensitive" => {"system-property" => {"type" => "core"}}},
"attributes" => {
"value" => {
"type" => STRING,
"description" => "The value of the system property.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 0L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"boot-time" => {
"type" => BOOLEAN,
"description" => "If true the system property is passed on the command-line to the started server jvm. If false, it will be pushed to the server as part of the startup sequence.",
"expressions-allowed" => true,
"nillable" => true,
"default" => true,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"children" => {}
}}
}
12 years, 1 month
To bloat or not to bloat...
by Paul Ferraro
While attempting to validate Wildfly against Infinispan master, in
preparation for the imminent 6.0.0.Final component upgrade, I ran into a
bit of an issue, the resolution of which is not immediate clear, and,
while apparently insignificant at first glance, is perhaps more
appropriately made within the larger context of how we design layered
projects.
Here the issue.
Sometime in the AS7 release cycle, indexing support was added to the
Infinispan subsystem. This was done in response to a request by the
capedwarf project - the idea being - that, while AS7 would not ship the
modules required to support querying an infinispan cache, it could at
least support the ability to configure such a cache. I'm not sure if
there are other projects that rely on this functionality - so please
make yourself known if you are.
In retrospect, this was probably not a good idea. Indexing should
probably have been implemented as a separate subsystem, which could
reference configuration from the infinispan subsystem - but alas, that's
how it was originally implemented.
The trouble begins with a seemingly innocent jira:
https://issues.jboss.org/browse/ISPN-3583
which adds validation within Infinispan itself, where a cache can no
longer be configured to use indexing unless the requisite module (i.e.
infinispan-query and its dependencies) is available.
The consequence of this, however, is that the unit tests that validate
the parsing and management of indexing configuration is now broken in
Wildfly, since Wildfly does not ship the requisite modules required to
validate such a configuration.
So, as I see it, the way forward can take a number of different paths:
1. Restore the status quo, i.e. remove this validation from Infinispan
itself. This still leaves us the the ability to configure an unusable
cache - since indexing is only useful if the modules required to utilize
it are available.
2. Remove the testing of indexing configuration from the Infinispan
subsystem's unit tests. This retains all of he disadvantages of #1, and
additionally results in poorer test coverage, pushes the burden of
testing this functionality to downstream projects, and will likely
morally offend some of you.
3. Add the requisite modules to Wildfly. This would make downstream
projects (e.g. capedwarf) happy, but arguably bloats Wildfly
unnecessarily, given that Wildfly has no internal need for these
modules, nor this functionality. However, these modules would never
need to be loaded unless configured to do so, therefore this would only
bloat the distribution size, not the actual runtime.
4. Drop indexing from the supported infinispan subsystem configuration,
reject any such configuration from previous versions of the management
api, and force downstream projects to implement indexing support
themselves. This may very well be the "correct" approach, but may not
be the most practical one at this stage. Certainly, if multiple
downstream projects require the ability to configuring cache querying,
they would benefit from being able to inherit this functionality from a
common downstream project.
What do people think?
Paul
12 years, 1 month
