<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 12, 2015 at 1:40 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">We wouldn’t be able to use that approach because its shipped under an incompatible viral license (GPL with additional restrictions). Theres also the other negative that we try to avoid shipping native bits if at all possible. <div><div class="h5"><div><br></div></div></div></div></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif">That a good reason to avoid that...<br><br>And what about Commons Daemon?, it stills depends on the native part, but wildfly already includes native binaries for windows, a separate download of the native part could be an option for both unix and windows...<br></div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><div><blockquote type="cite"><div>On Jun 12, 2015, at 12:02 PM, Jorge Solórzano <<a href="mailto:jorsol@gmail.com" target="_blank">jorsol@gmail.com</a>> wrote:</div><br><div><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><br></div></div></div></div></blockquote><div><div 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" target="_blank">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><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>
</div></blockquote></div><br><div>
--<br>Jason T. Greene<br>WildFly Lead / JBoss EAP Platform Architect<br>JBoss, a division of Red Hat
</div>
<br></div></div></div></div></blockquote></div><br></div></div>