From alexey.loubyansky at redhat.com  Mon Dec  2 09:06:52 2013
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Mon, 02 Dec 2013 15:06:52 +0100
Subject: [jboss-as7-dev] cli variables
Message-ID: <529C93FC.5050407@redhat.com>

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 at localhost:9990 /] echo prod_db
/subsystem=datasources/data-source=ExampleDS

And unset with

[standalone at 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

From hmlnarik at redhat.com  Mon Dec  2 09:26:57 2013
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 02 Dec 2013 15:26:57 +0100
Subject: [jboss-as7-dev] cli variables
In-Reply-To: <529C93FC.5050407@redhat.com>
References: <529C93FC.5050407@redhat.com>
Message-ID: <1478660.jOllsIsUWy@logrus.brq.redhat.com>

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 at localhost:9990 /] echo $prod_db
instead of proposed:
    [standalone at 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 at localhost:9990 /] set prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
[standalone at localhost:9990 /] set prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
[standalone at localhost:9990 /] set ds=pgsqlDS
[standalone at 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 at localhost:9990 /] echo prod_db
> /subsystem=datasources/data-source=ExampleDS
> 
> And unset with
> 
> [standalone at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20131202/f536bf5c/attachment.html 

From spederse at redhat.com  Mon Dec  2 09:32:06 2013
From: spederse at redhat.com (=?iso-8859-1?Q?St=E5le_W=2E?= Pedersen)
Date: Mon, 2 Dec 2013 15:32:06 +0100
Subject: [jboss-as7-dev] cli variables
In-Reply-To: <1478660.jOllsIsUWy@logrus.brq.redhat.com>
References: <529C93FC.5050407@redhat.com>
	<1478660.jOllsIsUWy@logrus.brq.redhat.com>
Message-ID: <20131202143206.GH7980@beistet>

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 at localhost:9990 /] echo $prod_db
>instead of proposed:
>    [standalone at 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 at localhost:9990 /] set prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>[standalone at localhost:9990 /] set prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>[standalone at localhost:9990 /] set ds=pgsqlDS
>[standalone at 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 at localhost:9990 /] echo prod_db
>> /subsystem=datasources/data-source=ExampleDS
>>
>> And unset with
>>
>> [standalone at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

>_______________________________________________
>jboss-as7-dev mailing list
>jboss-as7-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


From dandread at redhat.com  Thu Dec  5 03:19:00 2013
From: dandread at redhat.com (Dimitris Andreadis)
Date: Thu, 05 Dec 2013 09:19:00 +0100
Subject: [jboss-as7-dev] cli variables
In-Reply-To: <1478660.jOllsIsUWy@logrus.brq.redhat.com>
References: <529C93FC.5050407@redhat.com>
	<1478660.jOllsIsUWy@logrus.brq.redhat.com>
Message-ID: <52A036F4.6090303@redhat.com>

+1 on Hynek's comments, especially the echo $var

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?

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 at localhost:9990 /] echo $prod_db
>
> instead of proposed:
>
> [standalone at 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 at localhost:9990 /] set
> prod_db_pgsqlDS=/subsystem=datasources/data-source=ExampleDSPgSQL
>
> [standalone at localhost:9990 /] set
> prod_db_mysqlDS=/subsystem=datasources/data-source=ExampleDSMySQL
>
> [standalone at localhost:9990 /] set ds=pgsqlDS
>
> [standalone at 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 at localhost:9990 /] echo prod_db
>
>  > /subsystem=datasources/data-source=ExampleDS
>
>  >
>
>  > And unset with
>
>  >
>
>  > [standalone at 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 at lists.jboss.org
>
>  > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

From m.alkahtani at gmail.com  Wed Dec 18 05:27:16 2013
From: m.alkahtani at gmail.com (Mohammad Alkahtani)
Date: Wed, 18 Dec 2013 13:27:16 +0300
Subject: [jboss-as7-dev] Help with ClusterJPA & OpenJPA
Message-ID: <CACNma3OL93LNWnxhKBn8dR81CnCJrKN-mdCtvRb3S8Ehva26VA@mail.gmail.com>

 I'm trying to do J2EE version of this tutorial which J2SE
http://www.clusterdb.com/mysql-cluster/using-clusterjpa-part-of-mysql-cluster-connector-for-java-a-tutorial
I installed OpenJPA as module in JBoss add the MySQL JDBC datasource
to JBoss AS 7 then I run my application with persistence.xml
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
 xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="SQLTPU" transaction-type="JTA">
    <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
       <jta-data-source>java:/mcube/DefaultDS</jta-data-source>

 <class>org.ksu.SQLT.entities.Employee</class>
 <class>org.ksu.SQLT.entities.Department</class>
 <properties>

 <property name="jboss.as.jpa.providerModule" value="org.apache.openjpa" />
<!--   IMPORTANT PROPERTIES   -->
           <property name="openjpa.DynamicEnhancementAgent" value="false"/>
           <property name="openjpa.RuntimeUnenhancedClasses"
value="supported" />
<property name="openjpa.jdbc.SynchronizeMappings"
value="buildSchema(ForeignKeys=true)" />
     <!-- <property name="openjpa.jdbc.DBDictionary" value="mysql" /> !-->
<property name="openjpa.ConnectionDriverName"
 value="com.mysql.jdbc.Driver" />
 <property name="openjpa.ConnectionURL"
 value="jdbc:mysql://192.168.1.13:3306/clusterdb" />
 <property name="openjpa.ConnectionUserName" value="root" />
 <property name="openjpa.ConnectionPassword" value="Password" />
 <property name="openjpa.BrokerFactory"
value="com.mysql.clusterj.openjpa.NdbOpenJPABrokerFactory" />
 <property name="openjpa.jdbc.DBDictionary" value="TableType=ndbcluster" />
 <property name="openjpa.ndb.connectString" value="192.168.1.13:1186" />
 <property name="openjpa.ndb.database" value="clusterdb" />
 </properties>
 </persistence-unit>
</persistence>

I add the .jar files ClusterJPA, ClusterJ and ClusterAPI to the
project library folder in NetBeans. the application deployed but dose
not create the tables in the database