Update the Logging IDs Page
by Darran Lofthouse
Hi all,
Recently we have had some issues reported where logging IDs are
suspected to be duplicates.
Can I suggest that one thing we do need is to update the page tracking
the reserved ID's to make it easier to identify what block is available
next?
https://community.jboss.org/wiki/LoggingIds
Would it would be easier if the ranges column was sequential, if a
subsystem takes multiple allocations then it should just appear in the
list more than once. At the moment to find a free block you need to
scan up and down the page to check the subsequent allocations.
Regards,
Darran Lofthouse.
13 years, 1 month
Re: [wildfly-dev] Change CLI to Default to Remoting
by Brian Stansberry
On 7/10/13 6:26 AM, Heiko W.Rupp wrote:
>
> Am 09.07.2013 um 18:41 schrieb Brian Stansberry:
>> Remember also that people will use the new CLI binary to manage legacy
>> servers where HTTP upgrade is not an option. So even if by default WF
>> isn't using 9999, there will be need for the CLI to deal cleanly with 9999.
>
> And the other way around.
>
The issue there is whether port 9999 is even open. Jason has commented
he wants to eliminate it by default for WF 8. I'm personally just so-so
about that idea, but can't really make a good argument against it.[1] A
user can turn 9999 back on though if desired; the capability isn't being
removed.
If 9999 is open an older CLI will have no problem dealing with WF 8.
[1] I see this as kind of like ripping off a band-aid. At some point
external forces are going to force us toward using a minimal-port-count
default config. So if the band-aid is going to eventual come all the way
off, best to hurry up and get it over with.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 1 month
Put MyFaces JSF into WildFly?
by ssilvert＠redhat.com
Ever since we switched from MyFaces to Mojarra I've incurred the wrath
of MyFaces fans. Regardless of the relative quality of each
implementation, we have stuck with Mojarra because it always implements
the latest spec long before MyFaces. Now is no exception as Mojarra
fully supports JSF 2.2 and MyFaces 2.2 is incomplete.
However, with Multi-JSF in place, it is now trivial to ship both
implementations and allow the end user to choose which one they like best.
Any thoughts on this?
Stan
13 years, 1 month
Pull request building improvements
by Tomaž Cerar
Hi everyone!
In last few months we have been working on improving our pull request
testing & reporting.
As most of you know we have been running many test scenarios on "my"
teamcity instance at http://teamcity.cafe-babe-org and it has proven that
it works very well.
In many cases much better than what we had with jenkins on lightning.
That is why new solution is done on top of TeamCity rather than Jenkins.
Today we are turning off lightning's cron jobs for processing and turning
on new pull request building & github integration that we build on top of
TeamCity.
Given that reinstalation of the system(we also got some new disks that
require us to reconfigure RAID) is not trivial procedure from server uptime
point of view, we have setup pull processing to be done on "my" teamcity
while lightning will be offline.
As precaution we have just stopped pull player on lightning and we wont be
taking it offline until tomorrow evening (EST) given that new system works
as expected.
You can login to teamcity as guest, there is a little link on login page
and you don't need account created for watching build logs/progress.
So if you notice any problems in coming days let me know.
cheers,
Tomaz
13 years, 1 month
Re: [wildfly-dev] Update the Logging IDs Page
by Tomaž Cerar
forgot to cc list
/me goes to get some coffee
On Thu, Jul 4, 2013 at 12:27 PM, Darran Lofthouse <
darran.lofthouse(a)jboss.com> wrote:
> Not sure if you meant to drop the list.
>
> But then I agree provided searching based on the ID and finding a solution
> written for a JBoss Web problem has the same meaning and solution within
> Undertow then there should be no problem re-using the ID and actually that
> probably should be something we do to allow an existing solution to be
> re-used.
>
> Regards,
> Darran Lofthouse.
>
>
>
> On 04/07/13 11:18, Tomaž Cerar wrote:
>
>> Yes where they are reused they mean exactly same thing.
>> We didn't reused all messages but just in integration places that are
>> the same as with jbossweb.
>> undertow subsystem also has bunch of extra messages that are unique to it
>>
>>
>> On Wed, Jul 3, 2013 at 6:29 PM, Darran Lofthouse
>> <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@**jboss.com<darran.lofthouse(a)jboss.com>>>
>> wrote:
>>
>> On 03/07/13 17:22, Tomaž Cerar wrote:
>>
>>
>> On Wed, Jul 3, 2013 at 6:04 PM, Darran Lofthouse
>> <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@**jboss.com<darran.lofthouse(a)jboss.com>
>> >
>> <mailto:darran.lofthouse@__jbo**ss.com <http://jboss.com>
>>
>> <mailto:darran.lofthouse@**jboss.com <darran.lofthouse(a)jboss.com>>>>
>> wrote:
>>
>> Are they reporting the same problem and do they have the
>> same solution?
>>
>> They are exactly the same, same id and msg....
>>
>>
>> That wasn't my question ;-)
>>
>> Do they have the same meaning and same solution?
>>
>> Or if someone searches based on these IDs is it going to mean
>> something different when it applies to Undertow?
>>
>>
>>
13 years, 1 month
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
13 years, 1 month
Logging Model Changes and Questions
by James R. Perkins
I talked to Tomaz a bit about this last Friday, but thought I would open
it up to a wider audience and get others opinions as well.
All handlers, except the async-handler, have an attribute called
formatter. The formatter allows a string value which is the pattern used
to format the log message. This only allows for the use of the
org.jboss.logmanager.formatters.PatternFormatter.
There is a JIRA [1], I thought an RFE too but I can't find it, to allow
for the use of custom formatters. For example the use of
java.util.logging.XMLFormatter. I actually think this could be useful.
Possibly something like a JSONFormatter to help the console team with
displaying log messages on the web console [2].
There is also a JIRA [3] to allow the colors for the log output to be
changed.
The current model, we'll just use the console-handler for simplicity,
looks like the following:
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
"level" => "INFO",
"name" => "CONSOLE",
"target" => "System.out"
}
}
The easiest option (A) in both cases would be to add something like a
"custom-formatter" attribute and a "formatter-color-mapping" attribute.
What bothers me about this though is it doesn't seem logical. Having
attributes that may or may not be used together doesn't make a lot of
sense to me.
Another option (B) would be to change the model to look something like:
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => {
"pattern" => {
"format-pattern" => "%K{level}%d{HH:mm:ss,SSS} %-5p
[%c] (%t) %s%E%n",
"color-mapping" => "warn=yellow,error=red,info=clear"
}
},
"level" => "INFO",
"name" => "CONSOLE",
"target" => "System.out"
}
}
-- OR --
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => {
"custom" => {
"module" => "sun.jdk",
"class" => "java.util.logging.XMLFormatter",
"properties" => {
"key1" => "value1",
"key2" => "value2"
}
}
},
"level" => "INFO",
"name" => "CONSOLE",
"target" => "System.out"
}
}
I know some people don't like complex attribute values. Personally I
don't mind them, but they are a PITA with regards to CLI. A model change
like this would also require some transformers for backwards
compatibility. Though that doesn't really bother me all that much.
Anyone have opinions on should be used? I tend to lean option B because
it feels more logical.
[1]: https://issues.jboss.org/browse/WFLY-1188
[2]: https://issues.jboss.org/browse/WFLY-1144
[3]: https://issues.jboss.org/browse/WFLY-1059
--
James R. Perkins
Red Hat JBoss Middleware
13 years, 2 months
Can not build WildFly upstream
by Wolf-Dieter Fink
I pulled the latest upstream of WildFly today
commit 536d8de429f91d4e9d098a44f243e705dcef8055
Author: Jeff Mesnil <jmesnil(a)gmail.com>
Date: Mon May 13 14:34:01 2013 +0200
fix JBoss AS/WildFly Maven GAV for subsystem tests
and can not build (neither with build.sh nor with mvn clean install).
Also tried with a new system (clean mvn repository).
Is the code broken or did I miss something. I use Fedora16/18 and Java
1.7.0_25
This is the build output:
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building WildFly: Shared Security Utilities 8.0.0.Alpha1-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
wildfly-security-manager ---
[INFO] Deleting /data/devel/readonly/wildfly/security-manager/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (ban-bad-dependencies) @
wildfly-security-manager ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-java-version) @
wildfly-security-manager ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven-version) @
wildfly-security-manager ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.2:create-timestamp
(get-build-timestamp) @ wildfly-security-manager ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @
wildfly-security-manager ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
wildfly-security-manager ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/data/devel/readonly/wildfly/security-manager/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
wildfly-security-manager ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 27 source files to
/data/devel/readonly/wildfly/security-manager/target/classes
[INFO] -------------------------------------------------------------
[WARNING] COMPILATION WARNING :
[INFO] -------------------------------------------------------------
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[37,19]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[37,19]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[37,19]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[37,19]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[247,20]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[247,52]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[248,20]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[249,19]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[281,20]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[281,52]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[282,20]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[WARNING]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[283,19]
sun.reflect.Reflection is internal proprietary API and may be removed in
a future release
[INFO] 12 warnings
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[247,30]
method getCallerClass in class sun.reflect.Reflection cannot be applied
to given types;
required: no arguments
found: int
reason: actual and formal argument lists differ in length
[ERROR]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[248,30]
method getCallerClass in class sun.reflect.Reflection cannot be applied
to given types;
required: no arguments
found: int
reason: actual and formal argument lists differ in length
[ERROR]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[249,29]
method getCallerClass in class sun.reflect.Reflection cannot be applied
to given types;
required: no arguments
found: int
reason: actual and formal argument lists differ in length
[ERROR]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[281,30]
method getCallerClass in class sun.reflect.Reflection cannot be applied
to given types;
required: no arguments
found: int
reason: actual and formal argument lists differ in length
[ERROR]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[282,30]
method getCallerClass in class sun.reflect.Reflection cannot be applied
to given types;
required: no arguments
found: int
reason: actual and formal argument lists differ in length
[ERROR]
/data/devel/readonly/wildfly/security-manager/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java:[283,29]
method getCallerClass in class sun.reflect.Reflection cannot be applied
to given types;
required: no arguments
found: int
reason: actual and formal argument lists differ in length
[INFO] 6 errors
[INFO] -------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] WildFly: Build Configuration ...................... SUCCESS [0.881s]
[INFO] WildFly: Parent Aggregator ........................ SUCCESS [0.456s]
[INFO] WildFly: Protocol Utilities ....................... SUCCESS [7.485s]
[INFO] WildFly: Controller Client ........................ SUCCESS [1.783s]
[INFO] WildFly: Shared Security Utilities ................ FAILURE [0.191s]
13 years, 2 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
13 years, 2 months
