December 2015 - wildfly-dev - Jboss List Archives

AUTO: Andreas Kalk ist außer Haus (Rückkehr am 04.01.2016) [Virus checked]

by Andreas.Kalk＠nordsee.com

Ich kehre zurück am 04.01.2016. Ich werde ab 19.12.2015 nicht im Büro sein. Ich kehre zurück am 04.01.2016. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen wenden Sie sich bitte an den Support (1377) Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "wildfly-dev Digest, Vol 33, Issue 7 [Virus checked]" gesendet am 19.12.2015 20:47:42. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. NORDSEE - Wir sind Fisch. Jetzt neu! Frisch gegrillte Jakobsmuscheln auf Balsamico-Linsen! "frisch für dich!" - direkt nach der Bestellung frisch für dich zubereitet. Genießen Sie für kurze Zeit unsere innovative Produkt-Neuheit: Hochwertige Hummerstücke mit Estragon-Creme im Butter-Croissant P Denken Sie bitte an die Umwelt - bevor Sie ausdrucken! NORDSEE Holding GmbH * Klußmannstraße 3 * 27570 Bremerhaven Registergericht Bremen * Reg.-Nr. HRB 3579 Geschäftsführer: Hiltrud Seggewiß (Vors.) * Robert Jung * Claus Schlüter Aufsichtsratsvorsitzender: Heiner Kamps

10 years

1
0
0 / 0

Thread Pool Utilities

by James Perkins

Hello All, The thread-pool utilities don't currently allow the shutdown() or shutdownNow() [1] to be executed on the delegate executor. This made sense when we had a thread subsystem, but now that we don't it makes these executors hard to use for things like graceful shutdown. For example if a graceful shutdown limit has been reached threads submitted from these thread-pools continue running as there's no way to shut them down and kill running threads. I'd propose that since these are utilities now that these methods be exposed for usage [2]. Does anyone see an issue with that? Or have alternative ides? [1] : https://github.com/wildfly/wildfly-core/blob/69fed63548cbebed86e31ba376f0... [2]: https://github.com/wildfly/wildfly-core/compare/master...jamezp:thread-po... -- James R. Perkins JBoss by Red Hat

10 years

2
2
0 / 0

Permission on https://github.com/jboss/jaxb

by Carlo de Wolf

I've extended push permission to Alessio on https://github.com/jboss/jaxb. Of course this also means he is now the defacto component lead. :-) Please let me know if there any objections. Carlo

10 years

1
0
0 / 0

Modular classloader to verify against duplicates and ambiguities?

by Sanne Grinovero

As an app developer I remember that some years ago I fell in love with JBoss Tattletale [1], as I would use it on my projects regularly to verify that I wasn't screwing up my deployed dependencies.. something which was quite common as a naive developer using Maven.. Nowadays I'm loving WildFly's modules system as it would allow me to break down complex applications further (if I still were to develop apps on it), or as a Hibernate / Search / Infinispan developer allows us to package things in a much nicer way, exposing a minimal API surface to end users. Then we have deployers such as the JPA subsystem which "automagically" add dependencies to apps at runtime, and while I like the fact that I don't have to add specific module-related descriptor files to my app and trust that the app server *might* do the right thing in most cases, I'm actually not very happy with the transparency of this system as I believe most application developers would need an exhaustive list of what's being added - and such details are all too fleeting in our different versions. I think it would be a great feature if the modular classloader wouldn't just have a well-defined order to find class definitions, but could go beyond that by actually verify that for a given class name there are no ambiguous resolutions, within each module (and each application). Personally, I would totally love such an appserver who's going to yell at me: "you bundled two copies of blah, I refuse to deploy that!". Or similarly: "you're bundling Hibernate, but we're giving it to you already as we recognized a JPA app and you didn't disable the embedded module!" "Seriously, one more copy of the JTA API ?" Please? Thanks, Sanne 1 - http://tattletale.jboss.org/

10 years

3
4
0 / 0

BeanManager usage in EAR deployments

by James Netherton

Hi all, I'm using Apache Camel with its CDI component (which uses DeltaSpike). Can anyone help to clarify the behavior I see with the CDI BeanManager in the following deployment scenarios. If I deploy my Camel application as an EAR deployment with the camel dependencies contained in the EAR archive lib directory: - my-application.ear |--- lib |--- camel-cdi-2.16.1.jar |--- camel-core-2.16.1.jar |--- deltaspike-core-api-1.5.1.jar |--- deltaspike-core-impl-1.5.1.jar |--- my-module.jar |--- META-INF |--- beans.xml |--- com.myapplication |--- Bootstrap.class |--- HelloBean.class Camel is capable of resolving beans that I have annotated with @Named through this BeanManager used by the Camel CDI extension: Weld BeanManager for my-camel-cdi-app.ear.external.jar:file:/home/james/.m2/repository/org/apache/camel/camel-cdi/2.16.1/camel-cdi-2.16.1.jar!/META-INF/beans.xml [bean count=42] However, if I deploy an EAR with a JAR sub-deployment and modularize my Camel dependencies like this: - my-application.ear |--- my-module.jar |--- META-INF |--- beans.xml |--- com.myapplication |--- Bootstrap.class |--- HelloBean.class - module: org.apache.camel.cdi:main |-- camel-cdi-2.16.1.jar |-- camel-core-2.16.1.jar |-- deltaspike-core-api-1.5.1.jar |-- deltaspike-core-impl-1.5.1.jar The BeanManager assigned to the Camel CDI extension is no longer capable of resolving my @Named annotated beans (HelloBean.class). Is this the expected behavior in this deployment scenario? There's some test cases which may explain things better here: https://github.com/jamesnetherton/camel-cdi-ear-tests Any help to clarify would be appreciated. Cheers, James

10 years

4
7
0 / 0

Shall we limit size of the deployment in WildFly?

by Lin Gao

Hi, WildFly does not limit the deployment file size, users with appropriate privilege(deployer) can select any file to deploy from both CLI and web console. For the too big file, it may exhaust all available disk space, and in some cases, even small file can exhaust the disk space if the current disk space is not big enough. So shall we limit file size of the deployment in WildFly? or shall we limit the available disk space? or shall we just show a warning message to users? If we do, where in the management API configuration for this should be done, if it is done this way? Arbitrary limits will break users, so if we have an arbitrary limit it needs to be easily adjusted. In case of domain mode, different hosts may have different disk space, which means they are likely have different capacity to hold deployment files. For example, servers in server-group-A may have 2GB available disk space, servers in server-group-B may have 200MB available disk space. An unified limit for the whole domain seems not fair for the servers with more available disk space. Also, WildFly does not limit type of the deployment file, but it might need a separate discussion if necessary? Any thoughts? FYI: https://issues.jboss.org/browse/WFCORE-1057 Best Regards -- Lin Gao Software Engineer JBoss by Red Hat

10 years

11
39
0 / 0

Early-access build b95 of JDK 9 is available for download

by Rory O'Donnell

Hi Jason/Tomaz, Early-access builds of JDK 9 with Project Verona [0] in b95 are available for download here <https://jdk9.java.net/download>. The goal of this Project is to implement the new JDK version string as described in JEP-223 <http://openjdk.java.net/jeps/223> [1]. The new version-string scheme is designed to easily distinguish major, minor, and security-update releases. For more information please see Iris Clark's email [2] , also see Dalibor Topic's blog on this topic [3]. Please send usage questions, feedback and experience reports to the verona-dev <http://mail.openjdk.java.net/mailman/listinfo/verona-dev> mailing list. Note: If you haven’t already subscribed to that mailing list then please do so first, otherwise your message will be discarded as spam. Rgds,Rory [0] http://openjdk.java.net/projects/verona/ [1] http://openjdk.java.net/jeps/223 [2] http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html [3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

10 years

1
0
0 / 0

Embedded servers, modules and logging

by Ken Wills

[resending as the last one got held for moderation for some reason]. Hi All, I've been working on a fix for https://issues.jboss.org/browse/WFCORE-950, and while I think I have the problem mitigated, a couple of issues have turned up regarding starting & stopping an embedded instance (either standalone or host-controller) and resetting / reloading modules. I'm not sure if these are realistic goals for this, so I'm asking here :) 1) Modules: during embedded start a module loader is obtained via Module.getBootModuleLoader(). This in turn initializes a static var to return it's BOOT_MODULE_LOADER. In the case of stopping an embedded server and restarting with a new --jboss-home-dir, subsequent module use continues to return the original BOOT_MODULE_LOADER. I expect this isn't a normal use case of modules, so I'm looking for some suggestions regarding perhaps the addition of a reset() method to Module or something similar to allow this behavior. Would this be a good idea? Other thoughts? (Note, I'll probably do this as a different change from #950.) 2) Property org.jboss.boot.log.file: This gets set on the first embedded server start, and I can't find where the actual logger is referencing the logfile in order to reset it to the new jboss-home-dir. Anyone have a clue for me? :^) Subsequent embedded servers continue to log to the previous server.log, which I expect will confuse people somewhat. Thanks! Ken

10 years

2
1
0 / 0

WFLY-4200 WAR MDB cannot obtain superclass on module classpath

by Eduardo Sant´Ana da Silva

I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module classpath This is what I posted about it: "I believe that the problem is because AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the parse phase: Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS Since the dependencies will be resolved at Phase.DEPENDENCIES, your build will not work. Regarding WFLY, my suggestion is not throw the EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass) only bring up some flag that the required interfaces were not yet resolved, some attachment could be useful, just to retain the super class name. When the dependencies were solved, the class will be present on the class index and the test against the annotation should be performed again. Since that work will be done twice, to verify the required interfaces, this requires some experts advice." Thanks, -- __________________________ Eduardo Sant'Ana da Silva

10 years

2
5
0 / 0

Best practices for management API text descriptions

by Brian Stansberry

This thread is to flesh out some thinking about best practices for the content of the free form text descriptions of the resources, attributes and operations in the WildFly management model. Red Hat's user experience team has been looking at some of the text in the admin console, much of which comes from the server side management API descriptions. As they start pinging subsystem authors looking for improvements, I think it will be helpful if we use this thread to come to some consensus around best practices. There is a lot of information provided by the server about the management API, going well beyond free form text descriptions. I encourage people to review [1] and particularly sections [2] and [3]. Any management client that tries to read the text description of, say, an attribute will automatically get the other descriptive data as well. Type information, whether a value is required, legal values, affect on the runtime of changing an attribute, etc. Because the full set of descriptive data is available to a tool whenever the text is, IMHO it makes sense *in general* to avoid repeating information in the free form text that is already available elsewhere in the descriptive data[4], for a number of reasons: 1) Whether or not particular bits of info will be added to the free form text will be inconsistent, depending on what an author chose to do. 2) The language quality of the free form text will vary widely. 3) The size of our metadata payloads is already a concern. Duplicating data by putting it in free form text increases this problem. 4) Duplicating data leads to maintenance troubles when details change, since now the information needs to be updated in two places. 5) People doing localization need to translate more text. Instead of duplicating data in the free form text, we're better off looking into how our standard clients (admin console, CLI, JConsole plugin) can best present the information present in the other descriptor fields. For example, put a '*' next to required fields in a graphical UI. (I think there's a HAL JIRA for that one!) In some cases the right answer for a UI is to show a chunk of text, e.g. in a tooltip. But even there I think the best way to show standard info is to append standardized text to the free form text provided by the server. So, if some attribute "max-size" has restart-required=all-services and the free form text for "max-size" reads "The maximum number of threads in the pool", then the console could generate a tool tip that reads: The maximum number of threads in the pool. Servers must be reloaded for changes to take effect. I think this kind of approach can work well for the "nillable", "expressions-allowed", "min", "max", "default", "alternatives", "requires" and "restart-required" descriptors. For the "allowed" descriptor, the only reason to include the allowed values in the free form text is if the meaning of the legal values isn't clear and the free form text includes some explanation. Otherwise, a UI can already use the "allowed" descriptor to show the legal values, e.g. via a pull down in a GUI or tab completion in the CLI. I'm not advocating we go off on a major expedition to change our existing text. I do however want to avoid us adhoc adding a lot of duplicate text, unless we come to a consensus that that's the best approach. [1] https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Descr... [2] https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Descr... [3] https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Arbit... [4] For example, the "restart-required" descriptor on an attribute indicates what must happen for a change to the attribute to take effect. So including "The server must be reloaded for a change to take effect" in the free form text is duplication. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

10 years

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev December 2015