Re: [jboss-dev-forums] [JBoss AS7 Development] - Data Source Configuration in AS 7
by Tomasz Siedlik
Tomasz Siedlik [http://community.jboss.org/people/tomasz.siedlik] commented on the document
"Data Source Configuration in AS 7"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16657#comment-6962
--------------------------------------------------
Hi,
Have you tried the configuration with JBoss AS 7.0.0.CR1 and jtds-1.2.5.jar
I am getting following service status report:
New missing/unsatisfied dependencies:
service jboss.jdbc-driver.net_sourceforge_jtds (missing)
With
driver definition:
<driver name="net.sourceforge.jtds" module="net.sourceforge.jtds"/>
and module definition:
<module xmlns="urn:jboss:module:1.0" name="net.sourceforge.jtds">
<resources>
<resource-root path="files"/>
<resource-root path="jtds-1.2.5.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="javax.api" />
</dependencies>
</module>
--------------------------------------------------
14 years, 10 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - Data Source Configuration in AS 7
by tmanning
tmanning [http://community.jboss.org/people/tmanning] commented on the document
"Data Source Configuration in AS 7"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16657#comment-6961
--------------------------------------------------
In case anyone else has had problems with mysql and datasources in AS7 CR1 - I've found that if you drop the mysql connector jar into the standalone/deployments directory then your driver name must be the filename of the driver's jar file (in both locations). You can check this with the CLI to see what driver has been created. However, if you include the mysql-connector jar inside your war file, then the driver that's installed has a driver name equal to the file name of your war file (again, you can see this with the CLI).
The CLI seems to be a great way to see what drivers the system is actually deploying, and what names they have. Run bin/jboss-admin.sh, type "connect" (while your server is up), and then type "/subsystem=datasources:installed-drivers-list" to see the system's installed drivers.
--------------------------------------------------
14 years, 10 months
[JBoss AS7 Development] - Remote EJB lookup and invocation in JBoss AS 7.0.0
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabirkhan] modified the document:
"Remote EJB lookup and invocation in JBoss AS 7.0.0"
To view the document, visit: http://community.jboss.org/docs/DOC-16994
--------------------------------------------------------------
Since JBoss AS 7.0.0 targets the Java EE6 Web Profile, no support is available for remote connectivity beyond http (and the management functionality). That means that out of the box you can't do things like look up things in JNDI and invoke upon them from outside the server. This will be added later this year in JBoss AS 7.1.0, which will support the full Java EE6 stack.
In the meantime, if you want to invoke upon EJBs remotely, I have created a hack which lives here: https://github.com/kabir/as7-remote https://github.com/kabir/as7-remote. Use JDK 6 and maven 3+ to build it.
It is still a bit rough around the edges since I don't want to spend too much time on it until someone says if they are interested in this or not. Ideally if it is useful to someone, they can get involved in this. *DISCLAIMER:* This is a temporary stop-gap until we support proper remote invocations :-)
Instead of doing JNDI lookups on the client, I am forwarding lookup requests to an MBean that is deployed as part of an ear. So instead of
> InitialContext ctx = new InitialContext();
> TestStateless bean = ctx.lookup("java:global/test/test-ejb/TestStatelessBean");
You need to do
> Client client = ClientFactory.INSTANCE.getOrCreateClient(new ObjectName("jboss:name=test,type=remote"), "localhost", 1090); //This only needs doing once to initialize the client
> TestStateless bean = client.lookup(TestStateless.class, "java:global/test/test-ejb/TestStatelessBean");
https://github.com/kabir/as7-remote/blob/master/src/test/java/org/jboss/a... https://github.com/kabir/as7-remote/blob/master/src/test/java/org/jboss/a... deploys an ear containing the sar and an ejb jar, and then looks up and invokes upon the beans via JMX. It also shows how to grant access to and use JMS from a remote client.
The sar's META-INF/jboss-service.xml lets you explicitly declare the jndi names of EJBs that should be exposed via this mechanism:
> <server xmlns="urn:jboss:service:7.0"
> xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
>
>
> <mbean name="jboss:name=test,type=remote" code="org.jboss.as.remote.jmx.mbean.RemoteViaJMX">
>
> <!-- A comma separated list of jndi names of stateless session beans -->
> <attribute name="statelessBeanNames">java:global/test/test-ejb/TestStatelessBean</attribute>
>
> <!-- A comma separated list of jndi names of stateful session beans -->
> <attribute name="statefulBeanNames">java:global/test/test-ejb/TestStatefulBean</attribute>
>
> <!-- A comma separated list of jndi names of things that do not need extra proxying -->
> <attribute name="rawNames">RemoteConnectionFactory,queue/test</attribute>
> </mbean>
> </server>
The EJBs are then looked up on the server by the MBean which then returns a proxy allowing the remote client to invoke upon the EJBs by invoking via the MBean again. EJBs not declared are not accessible via this mechanism.
It works fine for simple cases but has the following limitations. Most of these are very simple to fix if there is enough interest:
* If an EJB method were to return a reference interface to another EJB that will not work at the moment.
* Only EJBs exposing interfaces are supported, in other words the no-interface views are not handled.
* For stateful session beans you need to put the @Remove annotation on the interface method as well as the bean class method.
* Asynchronous invocations are not handled
* I think the MBean needs to be deployed as part of the EAR containing the EJBs. Making it possible to load things from other deployments should be simple if someone wants that.
* No attempt is made to propagate security and transactional context from the client to the server
* Probably a load of other stuff I haven't thought of :-)
I obviously have all the AS 7 stuff in my local maven repository so if someone is having problems building it due to missing maven artifacts please let me know and I'll fix. Also, the test included relies on a AS 7 CR 1 instance being up and running.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16994]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 10 months
[JBoss AS7 Development] - Remote EJB lookup and invocation in JBoss AS 7.0.0
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabirkhan] created the document:
"Remote EJB lookup and invocation in JBoss AS 7.0.0"
To view the document, visit: http://community.jboss.org/docs/DOC-16994
--------------------------------------------------------------
Since JBoss AS 7.0.0 targets the Java EE6 Web Profile, no support is available for remote connectivity beyond http (and the management functionality). That means that out of the box you can't do things like look up things in JNDI and invoke upon them from outside the server. This will be added later this year in JBoss AS 7.1.0, which will support the full Java EE6 stack.
In the meantime, if you want to invoke upon EJBs remotely, I have created a hack which lives here: https://github.com/kabir/as7-remote https://github.com/kabir/as7-remote. Use JDK 6 and maven 3+ to build it.
It is still a bit rough around the edges since I don't want to spend too much time on it until someone says if they are interested in this or not. Ideally if it is useful to someone, they can get involved in this. *DISCLAIMER:* This is a temporary stop-gap until we support proper remote invocations :-)
Instead of doing JNDI lookups on the client, I am forwarding lookup requests to an MBean that is deployed as part of an ear. So instead of
> InitialContext ctx = new InitialContext();
> TestStateless bean = ctx.lookup("java:global/test/test-ejb/TestStatelessBean");
You need to do
> Client client = ClientFactory.INSTANCE.getOrCreateClient(new ObjectName("jboss:name=test,type=remote"), "localhost", 1090); //This only needs doing once to initialize the client
> TestStateless bean = client.lookup(TestStateless.class, "java:global/test/test-ejb/TestStatelessBean");
https://github.com/kabir/as7-remote/blob/master/src/test/java/org/jboss/a... https://github.com/kabir/as7-remote/blob/master/src/test/java/org/jboss/a... deploys an ear containing the sar and an ejb jar.
The sar's META-INF/jboss-service.xml lets you explicitly declare the jndi names of EJBs that should be exposed via this mechanism:
> <server xmlns="urn:jboss:service:7.0"
> xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
>
>
> <mbean name="jboss:name=test,type=remote" code="org.jboss.as.remote.jmx.mbean.RemoteEjb">
> <!-- A comma separated list of jndi names of stateless session beans -->
> <attribute name="statelessBeanNames">java:global/test/test-ejb/TestStatelessBean</attribute>
> <!-- A comma separated list of jndi names of stateful session beans -->
> <attribute name="statefulBeanNames">java:global/test/test-ejb/TestStatefulBean</attribute>
> </mbean>
> </server>
The EJBs are then looked up on the server by the MBean which then returns a proxy allowing the remote client to invoke upon the EJBs by invoking via the MBean again. EJBs not declared are not accessible via this mechanism.
It works fine for simple cases but has the following limitations. Most of these are very simple to fix if there is enough interest:
* If an EJB method were to return a reference interface to another EJB that will not work at the moment.
* Only EJBs exposing interfaces are supported, in other words the no-interface views are not handled.
* For stateful session beans you need to put the @Remove annotation on the interface method as well as the bean class method.
* Asynchronous invocations are not handled
* I think the MBean needs to be deployed as part of the EAR containing the EJBs. Making it possible to load things from other deployments should be simple if someone wants that.
* No attempt is made to propagate security and transactional context from the client to the server
* Probably a load of other stuff I haven't thought of :-)
I obviously have all the AS 7 stuff in my local maven repository so if someone is having problems building it due to missing maven artifacts please let me know and I'll fix. Also, the test included relies on a AS 7 CR 1 instance being up and running.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16994]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 10 months
[JBoss AS7 Development] - AS 7 startup time showdown
by Dan Allen
Dan Allen [http://community.jboss.org/people/dan.j.allen] modified the document:
"AS 7 startup time showdown"
To view the document, visit: http://community.jboss.org/docs/DOC-16971
--------------------------------------------------------------
How fast does AS 7 start on your computer? This page is a crowdsourced benchmark to see what type of times people are getting. It could also give you an idea if it's time to upgrade your computer to more cores.
Start-up times may vary sligtly between different runs, due to system load, filesystem caching etc. We are interested in your best times :)
On with the showdown! Start JBoss AS 7 in standalone mode and add your results to this page. We are mostly interested in *stock JVM settings*, just to even the playing field. If you add flags, please note that in the JVM column.
h3. AS 7 (Web Profile)
|| *Username* || *Processor / Chipset* || *RAM* || *HardDrive Speed* || *Operating System* || *JVM* || *Startup Time* ||
| dan.j.allen | Intel Core 2 Duo E8400 3.00 GHz 32-bit (http://ark.intel.com/Product.aspx?id=33910) | 4GB 800MHz | 7200 RPM | Ubuntu 11.04 i686 2.6.38-8 (pae) | OpenJDK 1.6.0_22 32-bit (stock settings) | 1726ms |
| dan.j.allen | Intel Core 2 Duo E8400 3.00 GHz 32-bit (http://ark.intel.com/Product.aspx?id=33910) | 4GB 800MHz | 7200 RPM | Ubuntu 11.04 i686 2.6.38-8 (pae) | OpenJDK 1.6.0_22 32-bit (JVM flags Group A) | 970ms |
| dan.j.allen | Intel 2 Core i7-2620M 2.70GHz 64-bit (http://ark.intel.com/Product.aspx?id=52231) | 8GB 1333MHz | 7200 RPM | Ubuntu 11.04 x86_64 2.6.38-8 | OpenJDK 1.6.0_22 64-Bit (stock settings) | 1590ms |
| dan.j.allen | Intel 2 Core i7-2620M 2.70GHz 64-bit (http://ark.intel.com/Product.aspx?id=52231) | 8GB 1333MHz | 7200 RPM | Ubuntu 11.04 x86_64 2.6.38-8 | OpenJDK 1.6.0_22 64-Bit (JVM flags Group A) | 1293ms |
| dan.j.allen | Intel Core 2 Duo T7500 2.20 GHz 32-bit (http://ark.intel.com/Product.aspx?id=29761) | 4GB 667MHz | 5200 RPM | Ubuntu 10.10 i686 2.6.35-28 (pae) | Java(TM) SE HotSpot Server VM 1.6.0_24-b07 | 2822ms |
| dan.j.allen | Intel Core 2 Duo T7500 2.20 GHz 32-bit (http://ark.intel.com/Product.aspx?id=29761) | 4GB 667MHz | 5200 RPM | Ubuntu 10.10 i686 2.6.35-28 (pae) | Java(TM) SE HotSpot Server VM 1.6.0_24-b07 (JVM flags Group A) | 1589ms |
| david bosschaert | Intel 2 Core i7 2.2GHz 64-bit | 8G 1333MHz | 7200 RPM | Mac OS X 10.6.8 Darwin 10.8.0 x86_64 | Apple Java 1.6.0_26 | 1479ms |
| david bosschaert | Intel 2 Core i7 2.2GHz 64-bit | 8G 1333MHz | 7200 RPM | Mac OS X 10.6.8 Darwin 10.8.0 x86_64 | Apple Java 1.6.0_26 (JVM flags Group A) | 1189ms |
| ssilvert | Intel ® Core™ 2 Duo i7-620M -i7
(2.66GHz, 4MB L3, 1066MHz FSB, 35W) | 8GB 1333MHz | 7200 RPM | Windows 7 Enterprise SP1 | Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) | 1813ms |
| tkimura | Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz | 8GB 1333MHz | 7200 RPM | Fedora 15
2.6.38.8-32.fc15.x86_64 | OpenJDK 1.6.0_22
fedora-58.1.10.2.fc15-x86_64
(stock settings) | 1450ms |
| tkimura | Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz | 8GB 1333MHz | 7200 RPM | Fedora 15
2.6.38.8-32.fc15.x86_64 | OpenJDK 1.6.0_22
fedora-58.1.10.2.fc15-x86_64
(JVM flags Group B) | 1012ms |
| tkimura | Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz | 8GB 1333MHz | 7200 RPM | KVM Image Fedora 15
2.6.38.8-32.fc15.i686
on Fedora 15 x86_64 | OpenJDK 1.6.0_22
fedora-58.1.10.2.fc15-i686
(JVM flags Group A) | 1007ms |
| jason.greene | i7 Dual Core @ 2.66 GHz | 8GB 1067MHZ | 7200 RPM | Mac OS X 10.6.8 (forced 64 bit kernel) | Apple Java 1.6.0_26 (-d32 bit mode) | 1486ms |
| jason.greene | i7 Dual Core @ 2.66 GHz | 8GB 1067MHZ | 7200 RPM | Mac OS X 10.6.8 (forced 64 bit kernel) | Apple Java 1.6.0_26 (stock settings) | 2041ms |
| goldmann | Intel Core i5 2.4 Ghz | 8GB 1067MHZ | 7200 RPM | Mac OS X 10.6.7 | Apple Java 1.6.0_26 (stock settings) | 2476ms |
| wolfc | Intel Core i7 860 2.80 Ghz | 6GB 1333Mhz | RAID0 2x7200 RPM | Ubuntu 11.04 x86_64 2.6.38-8 | OpenJDK 1.6.0_22 64-bit | 1287ms (w. patch) |
| mike.pellegrini | Intel Core i5 560 2.66 GHz | 4GB
1067MHz | 7200 RPM | Fedora Core 15 2.6.38.8-32.fc15.x86_64 | Java(TM) SE Runtime Environment (build 1.6.0_26-b03) | 1930ms |
| tommysdk | Intel ® Core™ i5 CPU M560 @ 2.70 GHz 64-bit | 4GB 1333 MHz | 7200 RPM | Windows 7 Professional | Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) (JVM flags Group A tweaked) | 1877 ms |
| sannegrinovero | i7 Dual Core @ 2.66 GHz | 8GB 1067MHZ | SSD Intel G2 | Fedora Core 15/64bit
custom kernel 2.6.39.2 | Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Options Group B | 1232ms |
| kevin.sapper | Intel ® Core™ i7 CPU Q720 @ 1.60 GHz | 6GB 1333 MHz | 5600 RPM | Windows 7 Home | Java(TM) SE Runtime 64-Bit Environment (build 1.6.0_26-b03)
Options Group A | 2098ms |
| kevin.sapper | Intel ® Core™ i7 CPU Q720 @ 1.60 GHz | 6GB 1333 MHz | 5600 RPM | Windows 7 Home | Java(TM) SE Runtime 64-Bit Environment (build 1.6.0_26-b03)
Options Group B | 1771ms |
| dimitris | Intel Core i7 CPU Q740 @ 1.73GHz | 4G | SSD Samsung PM800 | Windows 7 Prol SP1 | java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing) | 1649ms |
| mmiura | Six-Core AMD Opteron Processor 2435 @ 2.60GHz x2 | 24G | SSD
Intel X25-M 80G | Fedora 14
2.6.35.13-92.fc14.x86_64 | java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.8) (fedora-53.1.9.8.fc14-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) | 1507ms |
| pgier | Intel® CoreTM 2 Duo i7-620M -i7 @ 2.66GHz | 4G | 7200 RPM | Fedora 13
2.6.34.8-68.fc13.i686 | Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode) | 1969ms |
| tkonishi | Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz | 16G | SSD
Crucial C300 128GB | Fedora 15
2.6.38.8-32.fc15.x86_64 | java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.2) (fedora-58.1.10.2.fc15-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)(JVM flags Group A) | 866ms |
| tkonishi | Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz | 16G | SSD
Crucial C300 128GB | Fedora 15
2.6.38.8-32.fc15.x86_64 | java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.2) (fedora-58.1.10.2.fc15-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
(JVM flags Group B) | 706ms |
| tkonishi | Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz | 16G | SSD
Crucial C300 128GB | Fedora 15
2.6.38.8-32.fc15.x86_64 | java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.2) (fedora-58.1.10.2.fc15-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
(stock settings) | 1039ms |
h3. Older AS Versions
|| *Username* || *Processor / Chipset* || *RAM* || *HardDrive Speed* || *Operating System* || *JVM* || *AS Version* || *Startup Time* ||
| dan.j.allen | 2x Intel Core 2 Duo E8400 3.00 GHz 32-bit | 4GB 800MHz | 7200 RPM | Ubuntu 10.10 i686 2.6.35-28 (pae) | OpenJDK 1.6.0_22 32-Bit (stock settings) | 6.0.0.Final | 14.5s |
| dan.j.allen | Quad i7-2620M 2.70GHz 64-bit | 8GB 1333MHz | 7200 RPM | Ubuntu 11.04 x86_64 2.6.38-8 | OpenJDK 1.6.0_22 64-Bit (stock settings) | 6.0.0.Final | 13s |
| dan.j.allen | 2x Intel Core 2 Duo T7500 2.20 GHz 32-bit | 4GB 667MHz | 5200 RPM | Ubuntu 10.10 i686 2.6.35-28 (pae) | Java(TM) SE HotSpot Server VM 1.6.0_24-b07 | 6.0.0.Final | 21.88s |
| tkimura | Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz | 8GB
1333MHz | 7200 RPM | Fedora 15
2.6.38.8-32.fc15.x86_64 | OpenJDK 1.6.0_22
fedora-58.1.10.2.fc15-x86_64
(stock settings) | 6.0.0.Final | 12.0s |
| tkimura | Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz | 8GB
1333MHz | 7200 RPM | Fedora 15
2.6.38.8-32.fc15.x86_64 | OpenJDK 1.6.0_22
fedora-58.1.10.2.fc15-x86_64
(stock settings) | 5.1.0.GA | 19.0s |
| tkimura | Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz | 8GB
1333MHz | 7200 RPM | Fedora 15
2.6.38.8-32.fc15.x86_64 | OpenJDK 1.6.0_22
fedora-58.1.10.2.fc15-x86_64
(stock settings) | 4.2.3.GA | 6.2s |
| mike.pellegrini | Intel Core i5 560 2.66 GHz | 4GB
1067MHz | 7200 RPM | Fedora Core 15 2.6.38.8-32.fc15.x86_64 | Java(TM) SE Runtime Environment (build 1.6.0_26-b03) | 5.1.0 | 23s. |
h3. JVM flag legend (for table above)
* *Group A*: -Xms64m -Xmx512m -XX:MaxPermSize=256m -client -Xverify:none -XX:+UseFastAccessorMethods -XX:+DisableExplicitGC -XX:+UseCompressedOops
* *Group B*: -server -Xms128m -Xmx128m -XX:MaxPermSize=128m -Djava.net.preferIPv4Stack=true -XX:+UseFastAccessorMethods -XX:+TieredCompilation -Xverify:none
h3. Optimizations
You get better startup times with 32 bit over 64 bit, because of the smaller integer size. If you are on a 64 bit machine, you can do one of two things to get 32 bit performance:
* Run in 32 bit mode using the JVM flag: -d32 (Mac and Windows)
* Use the JVM compression flag: -XX:+UseCompressedOops (option not valid on a 32 bit JVM)
There are also some other JVM flags that will speed things up:
* -noverify
* -XX:+DisableExplicitGC
* -client (32 bit JVM only. You have to edit standalone.sh to use -client instead of -server)
You can squeeze out a few fractions of a second by disabling the console logging (or directing it to /dev/null):
./standalone.sh > /dev/null
You can still view the log output by tailing the server log.
See comments for other suggestions.
Let the best machine win!
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16971]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 10 months