[wildfly-dev] WFLY 9.0 startup message

Brian Stansberry brian.stansberry at redhat.com
Fri Jul 25 13:23:08 EDT 2014


On 7/25/14, 12:09 PM, James R. Perkins wrote:
>
> On 07/24/2014 06:24 PM, Brian Stansberry wrote:
>> On 7/24/14, 6:54 PM, James R. Perkins wrote:
>>>
>>> On 07/24/2014 03:15 PM, Brian Stansberry wrote:
>>>> On 7/24/14, 5:03 PM, Frank Langelage wrote:
>>>>> When using current WildFly build from sources I see this message after
>>>>> startup is complete:
>>>>> 24.07. 21:12:26,131 INFO  [org.jboss.as#done] WFLYSRV0025: WildFly
>>>>> 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services
>>>>> (179 services are lazy, passive or on-demand)
>>>>>
>>>>> Two things I suppose to be changed:
>>>>> 1. version is now the version of the underlying core, but version
>>>>> of the
>>>>> server should also be shown, or not? May be something like "WildFly
>>>>> 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ?
>>>> IMHO it should just be the version of the full dist, with the core
>>>> version only shown if whatever mechanism we add for letting a
>>>> dist-based
>>>> on core control this isn't implemented by a particular dist.
>>> Probably not ideal, but something like this almost kind of works
>>> https://github.com/jamezp/wildfly/compare/name-test.
>>
>> Yeah, IIRC (which is chancy) in an IRC chat a few weeks back something
>> like that looked like the likely solution. Some things to think about:
>>
>> 1) This is the EAP mechanism, so we'll need to think about how it will
>> relate to EAP once that becomes relevant (i.e. don't steal its thing
>> and then get stuck when it wants it back.) I think that's mostly just
>> thinking about the log message we'll want to write adn ensuring
>> ProductConfig can support that with the needed data.
> Agreed.
>>
>> 2) product.conf as a file name kind of sucks for something that isn't
>> a product
> Again agreed.

EAP will probably want to keep it though, so perhaps ProductConfig can 
check for 2 things, giving precedence to product.conf.

>>
>> 3) How this relates to the process of building a server when each of
>> the pieces that make up that server (e.g. web-build) try to write that
>> file, unless it's just trivial to have the final build win.
> Maybe it's something we can enhance the build plugin to do now. Seems
> there should be a reasonable solution. Maybe a simple properties file
> lookup or something like that. Anyway I don't want to jump in the middle
> if someone is already looking at it.

I doubt anyone is looking into this; IIRC it was just something that was 
chatted about a bit. Ping Stuart if no one responds; if anyone is doing 
anything it's likely him.

It's possible the provisioning stuff already handles all this just fine; 
I am far from an expert on the current status.

>>
>>> We could clean the
>>> Version API up though and probably do it a little different.
>>>>
>>>> Right now I assume we have no mechanism to let dists based on the core
>>>> control this.
>>>>
>>>>> 2. the nickname "Kenny" already was used for WildFly 8.x. Time to
>>>>> create
>>>>> a new one for 9.0.x, or?
>>>> Please, let's drop code names!!! It's just another thing to screw up.
>>> +1
>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>
>>
>>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list