<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 10:51 AM, Jason Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">That just monitors console output.<div><div><div class="h5"><br></div></div></div></div></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif">Not exacly, there are various modes of integration, posibly the most complex but flexible aproach is to use a listener[1] so it can be adapted properly to what we want.<br><br>[1] <a href="http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html">http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html</a></div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><div><blockquote type="cite"><div>On Jun 12, 2015, at 11:32 AM, Jorge Solórzano <<a href="mailto:jorsol@gmail.com" target="_blank">jorsol@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div style="font-family:verdana,sans-serif"><span lang="en">It has been considered the use of Java Service Wrapper[1]? it depends on native binaries but almost all platforms are supported. <br></span></div><div style="font-family:verdana,sans-serif"><br>[1] <a href="http://wrapper.tanukisoftware.com/" target="_blank">http://wrapper.tanukisoftware.com</a><br></div><div class="gmail_extra"><br clear="all"><div><div><br>Jorge Solórzano<br><a href="http://www.jorsol.com/" target="_blank">http://www.jorsol.com</a></div></div>
<br><div class="gmail_quote">On Fri, Jun 12, 2015 at 8:27 AM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How does EAP 5 deal with this? IIRC disabling console logging is not<br>
something new in EAP 6.<br>
<span><br>
On 6/11/15 6:29 PM, Chao Wang wrote:<br>
> Thanks for your reply. Please see in-line below<br>
><br>
> On 06/11/2015 12:44 AM, Brian Stansberry wrote:<br>
>> A couple thoughts:<br>
>><br>
>> 1) Looking at wildfly-init-redhat.sh at least, I don't see how that<br>
>> check is actually testing for successful startup. It looks like it's<br>
>> just trying to delay start() returning for a while, max 30 secs.<br>
>><br>
>> So, what purpose is this fulfilling?<br>
> My bad about issue background. It's actually an case in EAP 6 (not yet<br>
> in wildfly). EAP 6.x script has launched state like:<br>
> <a href="https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110" rel="noreferrer" target="_blank">https://github.com/jbossas/jboss-eap/blob/6.4.x/build/src/main/resources/bin/init.d/jboss-as-standalone.sh#L110</a><br>
> (not in wildfly's script). Also, console log handler has been removed<br>
> only in EAP full-ha mode long time ago due to performance<br>
> concern.(wildfly keeps it for the moment). This leads to issue in<br>
</span>> bz1224170 <<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224170" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1224170</a>>.<br>
<div><div>> That's why I try to seek an better option than current behavior from<br>
> wildfly.<br>
>><br>
>> 2) How does other software solve this problem? If it's solving a valid<br>
>> problem, it seems like there would be a typical solution.<br>
> I have checked some other application servers, most of them let users<br>
> themselves to write a script to run as service for their OS. Geronimo<br>
> does provide a script, Although I did damage to its configuration file<br>
> to make a fatal error, terminal output still displays "Server started".<br>
> In fact, process does not event exist and detail error can be seen in<br>
> log file.<br>
>> On 6/9/15 8:59 AM, Chao Wang wrote:<br>
>>> Hi all,<br>
>>><br>
>>> The Wildfly start-up as service scripts wildfly-init-redhat.sh and<br>
>>> wildfly-init-debian.sh currently depend on a grep action of key message<br>
>>> 'WFLYSRV0025:' in console log to determinate whether service start is<br>
>>> successful. The log message indication is accurate, however, it's not<br>
>>> that robust since user can always remove console handler from logging<br>
>>> subsystem. I have opened a WFCORE enhancement jira<br>
>>> <a href="https://issues.jboss.org/browse/WFCORE-747" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/WFCORE-747</a> for it.<br>
>>><br>
>>> For the moment, I have tried three options, they're all not that perfect<br>
>>> to implement<br>
>>><br>
>>> 1. Stay with exact log message, users need to define their jboss log<br>
>>> directory such as $JBOSS_HOME/standalone/log/server.log for standalone<br>
>>> and $JBOSS_HOME/domain/log/host-controller.log for domain instead of<br>
>>> searching in console log. This is more like another workaround since it<br>
>>> is also volatile once we update log message in future release.(EAP has<br>
>>> 'JBAS015874:')<br>
>>><br>
>>> 2. Use service pid, this is not precise because a long start-up can<br>
>>> crash in the last second. It needs to wait a suitable seconds before<br>
>>> checking pid existence. and still it can not avoid fake success in rare<br>
>>> case just before timeout.<br>
>>><br>
>>> 3. Use read-attribute server-state through CLI connection as I did in<br>
>>> Pull Request on Jira. This is declined as it is possible that<br>
>>> authentication is required before connection. In such case, any non<br>
>>> encrypted password is not advised in configuration files.<br>
>>><br>
>>> Therefore, I would like to listen for your opinions for them. Any other<br>
>>> suggestion is certainly welcomed in mail or on jira.<br>
>>><br>
>>> Best regards,<br>
>>><br>
>>> Chao<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> wildfly-dev mailing list<br>
>>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>><br>
>><br>
><br>
> [1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1224170" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1224170</a><br>
><br>
> --<br>
> Chao Wang<br>
> Software Engineer<br>
> JBoss by Red Hat<br>
><br>
><br>
><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
</font></span><div><div>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div></div>
_______________________________________________<br>wildfly-dev mailing list<br><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></div></blockquote></div><br></div></div><div>
--<br>Jason T. Greene<br>WildFly Lead / JBoss EAP Platform Architect<br>JBoss, a division of Red Hat
</div>
<br></div></div></blockquote></div><br></div></div>