WebSocket sendObject vs sendText
by Arun Gupta
The WebSocket Chat sample was not working on WildFly, until now.
I figured out that getBasicRemote().sendObject(...) was used to send a
String to all the connected clients. The code in @OnMessage looked
like:
for (Session peer : client.getOpenSessions()) {
peer.getBasicRemote().sendText(message);
}
I changed sendObject to sendText(...) and now its working. What is
causing this to break ?
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
12 years, 10 months
Re: [wildfly-dev] [jboss-as7-dev] cli variables
by Alexey Loubyansky
On 12/05/2013 09:19 AM, Dimitris Andreadis wrote:
> +1 on Hynek's comments, especially the echo $var
I've changed echo to assume $.
> I'm not sure also if those should be equivalent:
>
> set var=
> unset var
>
> to cover the case where you need var to be an empty string, rather than completely unset. I
> think it works as you propose on Windoze shells, but not on Unix shells?
I was not sure about it myself actually, which is why I mentioned it. It
might make sense make the difference.
Alexey
>
> On 02/12/2013 15:26, Hynek Mlnarik wrote:
>> Hi,
>>
>> thanks for the effort, this feature will be very helpful indeed!
>>
>> Overall I like your approach, yet in case of "echo" command I'd prefer mandatory use of $
>> character before variable name, i.e. to use:
>>
>> [standalone@localhost:9990 /] echo $prod_db
>>
>> instead of proposed:
>>
>> [standalone@localhost:9990 /] echo prod_db
>>
>> In other words, to apply the same substitution rules to "echo" parameters as to the rest of
>> use cases where variable value is read. This would also be more consistent with shell
>> standards, hence will be easily grabbed by administrators.
>>
>> Further, do you plan recursive substitution evaluation? E.g. something like this:
>>
>> [standalone@localhost:9990 /] set
>> prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>>
>> [standalone@localhost:9990 /] set
>> prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>>
>> [standalone@localhost:9990 /] set ds=pgsqlDS
>>
>> [standalone@localhost:9990 /] echo ${prod_db_$ds}
>>
>> /subsystem=datasources/data-source=ExampleDSPgSQL
>>
>> --Hynek
>>
>> On Mon December 2 2013 15:06:52 Alexey Loubyansky wrote:
>>
>> > There is this issue to provide CLI preferences
>>
>> > https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>>
>> > mainly this part
>>
>> >
>>
>> > "prod-db = /subsystem=jadada/database=jadada/
>>
>> > so you could call prod-db:read-resource"
>>
>> >
>>
>> > I'd like to get some opinion on the way it's gonna be implemented (and
>>
>> > what I've done so far on a local branch).
>>
>> >
>>
>> > So, to address that I introduced variables. A variable starts with a $,
>>
>> > e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>>
>> > conflict with actual parts of the paths, names, etc)
>>
>> >
>>
>> > Variables can be introduced with
>>
>> >
>>
>> > [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>
>> >
>>
>> > Read with
>>
>> >
>>
>> > [standalone@localhost:9990 /] echo prod_db
>>
>> > /subsystem=datasources/data-source=ExampleDS
>>
>> >
>>
>> > And unset with
>>
>> >
>>
>> > [standalone@localhost:9990 /] unset prod_db
>>
>> >
>>
>> > 'echo' without parameters will list all the variables and their values,
>>
>> > 'set prod_db=' will have the same effect as 'unset prod_db',
>>
>> > set/echo/unset will work with and w/o '$' prefix, tab-completion works
>>
>> > everywhere.
>>
>> >
>>
>> > The variables may appear in:
>>
>> >
>>
>> > - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>>
>> > - operation names, e.g. $prod_db:$op(include-runtime=true);
>>
>> > - operation parameter names and values, e.g.
>>
>> > $prod_db:$op($param=$param_value);
>>
>> > - the same for commands.
>>
>> >
>>
>> > Tab-completion helps complete the names as long as you type in '$' and
>>
>> > then the rest of the line after the variable as usual.
>>
>> >
>>
>> > Variables added during the session are not persisted anywhere. But I've
>>
>> > added .jbossclirc file. This file can be located in the current
>>
>> > directory, wildfly home bin directory or specified with a system
>>
>> > property. The content of the file is usual CLI commands and/or
>>
>> > operations. So, the variables could be initialized there. This file, if
>>
>> > located, will be executed before the CLI session (interactive or not)
>>
>> > starts (but also after the system properties specified with --properties
>>
>> > are set).
>>
>> >
>>
>> > As a side effect, '$' is now a special character and will have to be
>>
>> > escaped. Otherwise the CLI might complain about an unresolved variable.
>>
>> > So, this could potentially cause problems for existing scripts using $.
>>
>> >
>>
>> > Note, most of this replacement stuff can already be done with system
>>
>> > properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>>
>> > won't be affected, of course).
>>
>> >
>>
>> > And for now I've made variable names follow the rules for Java identifiers.
>>
>> >
>>
>> > Any remarks, objections or suggestions?
>>
>> >
>>
>> > Thanks,
>>
>> > Alexey
>>
>> > _______________________________________________
>>
>> > jboss-as7-dev mailing list
>>
>> > jboss-as7-dev(a)lists.jboss.org
>>
>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
12 years, 10 months
Netty 4.0.12 messages
by Frank Langelage
After today's upgrade of HornetQ and Netty to V4 I see this in my logs:
03.12. 20:10:09,207 FINE
[io.netty.util.internal.logging.InternalLoggerFactory#<clinit>] Using
java.util.logging as the default logging framework
03.12. 20:10:10,032 FINE
[io.netty.util.internal.PlatformDependent#isRoot0] Could not determine
the current UID using /usr/bin/id; attempting to bind at privileged ports.
03.12. 20:10:10,038 FINE
[io.netty.util.internal.PlatformDependent#isRoot0] UID: non-root (failed
to bind at any privileged ports)
03.12. 20:10:10,263 FINE
[io.netty.util.internal.PlatformDependent#javaVersion0] Java version: 7
03.12. 20:10:10,265 FINE
[io.netty.util.internal.PlatformDependent#hasUnsafe0]
-Dio.netty.noUnsafe: false
03.12. 20:10:10,273 FINE
[io.netty.util.internal.PlatformDependent0#<clinit>]
java.nio.ByteBuffer.cleaner: unavailable
03.12. 20:10:10,493 FINE
[io.netty.util.internal.PlatformDependent0#<clinit>]
java.nio.Buffer.address: unavailable
03.12. 20:10:10,495 FINE
[io.netty.util.internal.PlatformDependent#hasUnsafe0] sun.misc.Unsafe:
unavailable
03.12. 20:10:10,502 FINE
[io.netty.util.internal.PlatformDependent#hasJavassist0]
-Dio.netty.noJavassist: false
03.12. 20:10:10,505 FINE
[io.netty.util.internal.PlatformDependent#hasJavassist0] Javassist:
unavailable
03.12. 20:10:10,506 FINE
[io.netty.util.internal.PlatformDependent#hasJavassist0] You don't have
Javassist in your class path or you don't have enough permission to load
dynamically generated classes. Please check the configuration for
better performance.
03.12. 20:10:10,508 FINE
[io.netty.util.internal.PlatformDependent#<clinit>]
-Dio.netty.noPreferDirect: true
03.12. 20:10:10,509 INFO
[io.netty.util.internal.PlatformDependent#<clinit>] Your platform does
not provide complete low-level API for accessing direct buffers
reliably. Unless explicitly requested, heap buffer will always be
preferred to avoid potential system unstability.
03.12. 20:10:10,532 FINE [io.netty.util.ResourceLeakDetector#<clinit>]
-Dio.netty.noResourceLeakDetection: false
03.12. 20:10:14,125 FINE
[io.netty.channel.MultithreadEventLoopGroup#<clinit>]
-Dio.netty.eventLoopThreads: 4
03.12. 20:10:14,208 FINE [io.netty.channel.nio.NioEventLoop#<clinit>]
-Dio.netty.noKeySetOptimization: false
03.12. 20:10:14,209 FINE [io.netty.channel.nio.NioEventLoop#<clinit>]
-Dio.netty.selectorAutoRebuildThreshold: 512
03.12. 20:10:14,249 FINE
[io.netty.buffer.PooledByteBufAllocator#<clinit>]
-Dio.netty.allocator.numHeapArenas: 2
03.12. 20:10:14,250 FINE
[io.netty.buffer.PooledByteBufAllocator#<clinit>]
-Dio.netty.allocator.numDirectArenas: 2
03.12. 20:10:14,252 FINE
[io.netty.buffer.PooledByteBufAllocator#<clinit>]
-Dio.netty.allocator.pageSize: 8192
03.12. 20:10:14,253 FINE
[io.netty.buffer.PooledByteBufAllocator#<clinit>]
-Dio.netty.allocator.maxOrder: 11
03.12. 20:10:14,254 FINE
[io.netty.buffer.PooledByteBufAllocator#<clinit>]
-Dio.netty.allocator.chunkSize: 16777216
03.12. 20:10:14,300 FINE
[io.netty.util.internal.ThreadLocalRandom#newSeed]
-Dio.netty.initialSeedUniquifier: 0xe6abbdc3bd390fb7
03.12. 20:10:14,360 FINE [io.netty.util.NetUtil#<clinit>] Loopback
interface: lo0
03.12. 20:10:14,362 FINE [io.netty.util.NetUtil#<clinit>] Loopback
address: /127.0.0.1 (primary)
Okay, /usr/bin/id -u or /bin/id -u etc. are not working on Solaris.
Therefore /usr/xpg4/bin/id -u would have to be added.
But running without root access only binding to 127.0.0.1 should be
sufficient, or?
But why is javassist is not found?
Or should I simply reduce log level for io.netty to simply hide these
messages?
12 years, 10 months
Servlet Samples on Beta2 snapshot
by Arun Gupta
I tried Servlet samples from:
https://github.com/arun-gupta/javaee7-samples/tree/master/servlet
and encountered the following issues:
1). An HttpOnly cookie is set as:
cookie = new Cookie("myHttpOnlyCookieKey", "myHttpOnlyCookieValue");
cookie.setHttpOnly(true);
cookie.setMaxAge(60);
response.addCookie(cookie);
and
document.write(document.cookie);
displays the cookie and its value.
2). event-listeners sample is not getting deployed and throwing the
following exception:
Caused by: java.lang.IllegalArgumentException: UT010012: Listener
class class org.javaee7.servlet.event.listeners.MyHttpSessionBindingListener
must implement at least one listener interface
even though the class is defined as:
@WebListener
public class MyHttpSessionBindingListener implements
HttpSessionBindingListener {
...
}
3). file-upload sample allows to upload a file and writes it to /tmp
directory as:
for (Part part : request.getParts()) {
fileName = part.getSubmittedFileName();
part.write(fileName);
}
part.write() is not throwing any exception but not even writing the file.
4). In order to try servlet-security sample, I was trying to add a new
user in application realm as:
./bin/add-user.sh -g g1-u u1 -p p1 -r ApplicationRealm
but getting:
* Error *
JBAS015281: The user supplied realm name 'ApplicationRealm' does not
match the realm name discovered from the property file(s)
'ManagementRealm'.
Adding a user in the default realm, as expected, did not pass
authentication for the secure page. How should the user be added such
that the credentials can be used in an application ?
Thanks,
Arun
--
Blog: http://blog.arungupta.me
Twitter: http://twitter.com/arungupta
12 years, 10 months
Re: [wildfly-dev] [jboss-as7-dev] cli variables
by Kabir Khan
Just routing this back to the proper wildfly-dev list rather than jboss-as7-dev
On 2 Dec 2013, at 14:32, Ståle W. Pedersen <spederse(a)redhat.com> wrote:
> hi, just wanted to let you know that both echo and export is being
> worked on in æsh atm. - but we need to rewrite jboss-cli to use the
> latest api.
> ill make an effort into putting some time to do this.
>
> regards, ståle
>
> On 02.12.13 15:26, Hynek Mlnarik wrote:
>> Hi,
>>
>> thanks for the effort, this feature will be very helpful indeed!
>>
>> Overall I like your approach, yet in case of "echo" command I'd prefer mandatory use of $ character before variable name, i.e. to use:
>> [standalone@localhost:9990 /] echo $prod_db
>> instead of proposed:
>> [standalone@localhost:9990 /] echo prod_db
>>
>> In other words, to apply the same substitution rules to "echo" parameters as to the rest of use cases where variable value is read. This would also be more consistent with shell standards, hence will be easily grabbed by administrators.
>>
>>
>> Further, do you plan recursive substitution evaluation? E.g. something like this:
>> [standalone@localhost:9990 /] set prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>> [standalone@localhost:9990 /] set prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>> [standalone@localhost:9990 /] set ds=pgsqlDS
>> [standalone@localhost:9990 /] echo ${prod_db_$ds}
>> /subsystem=datasources/data-source=ExampleDSPgSQL
>>
>>
>> --Hynek
>>
>> On Mon December 2 2013 15:06:52 Alexey Loubyansky wrote:
>>> There is this issue to provide CLI preferences
>>> https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address
>>> mainly this part
>>>
>>> "prod-db = /subsystem=jadada/database=jadada/
>>> so you could call prod-db:read-resource"
>>>
>>> I'd like to get some opinion on the way it's gonna be implemented (and
>>> what I've done so far on a local branch).
>>>
>>> So, to address that I introduced variables. A variable starts with a $,
>>> e.g. $prod_db. (Using simply prod_db is not a good idea since it might
>>> conflict with actual parts of the paths, names, etc)
>>>
>>> Variables can be introduced with
>>>
>>> [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS
>>>
>>> Read with
>>>
>>> [standalone@localhost:9990 /] echo prod_db
>>> /subsystem=datasources/data-source=ExampleDS
>>>
>>> And unset with
>>>
>>> [standalone@localhost:9990 /] unset prod_db
>>>
>>> 'echo' without parameters will list all the variables and their values,
>>> 'set prod_db=' will have the same effect as 'unset prod_db',
>>> set/echo/unset will work with and w/o '$' prefix, tab-completion works
>>> everywhere.
>>>
>>> The variables may appear in:
>>>
>>> - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource;
>>> - operation names, e.g. $prod_db:$op(include-runtime=true);
>>> - operation parameter names and values, e.g.
>>> $prod_db:$op($param=$param_value);
>>> - the same for commands.
>>>
>>> Tab-completion helps complete the names as long as you type in '$' and
>>> then the rest of the line after the variable as usual.
>>>
>>> Variables added during the session are not persisted anywhere. But I've
>>> added .jbossclirc file. This file can be located in the current
>>> directory, wildfly home bin directory or specified with a system
>>> property. The content of the file is usual CLI commands and/or
>>> operations. So, the variables could be initialized there. This file, if
>>> located, will be executed before the CLI session (interactive or not)
>>> starts (but also after the system properties specified with --properties
>>> are set).
>>>
>>> As a side effect, '$' is now a special character and will have to be
>>> escaped. Otherwise the CLI might complain about an unresolved variable.
>>> So, this could potentially cause problems for existing scripts using $.
>>>
>>> Note, most of this replacement stuff can already be done with system
>>> properties using ${xxx} format (and btw scripts using '$' as in '${xxx}'
>>> won't be affected, of course).
>>>
>>> And for now I've made variable names follow the rules for Java identifiers.
>>>
>>> Any remarks, objections or suggestions?
>>>
>>> Thanks,
>>> Alexey
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12 years, 10 months
