For my newest Project I’m using the Play!Framework in Version 2.3.
As I’m just starting out with Scala since a long abstinence, I choose to create a project where I could create controllers in either Java or Scala code.
To do this, I added the line
lazy val root = (project in file(".")).enablePlugins(PlayScala, PlayJava)
to my build.sbt file.
While developing Java Controllers and corresponding views works like a charm, I got an error like
[RuntimeException: There is no HTTP Context available from here.]
when I tried to use the same template also for a Scala Controller.
After some digging around, I found out that the reason for this is that for Java Controllers, a “Context-Object” is created which holds all the relevant stuff for rendering the view ( to be precise a play.mvc.Http.Context is created by the trait play.core.j.JavaAction which then provides everything the view could require as implicits through play.mvc.Http.Context.Implicit )
If you now create a normal Scala Action like this:
object EmailTesting extends Controller {
def index = Action {
Ok(views.html.testing.email.index.render())
}
}
The magic that’s happening for the Java Controllers is missing.. your template tries to access the context/request/session but can’t find it because you would need to add it as implicit parameter which you can’t do if you want to use it from a Java Controller…
So, the trick to make your templates/views work both with Scala and with Java Controllers is to generate the play.mvc.Http.Context explicitly for rendering the view. I created a little helper class to make it easier to use:
object JavaContext {
import play.mvc.Http
import play.core.j.JavaHelpers
def withContext[Status](block: => Status)(implicit header: RequestHeader): Status = {
try {
Http.Context.current.set(JavaHelpers.createJavaContext(header))
block
}
finally {
Http.Context.current.remove()
}
}
}
you can apply it then like this (note the requirement for the “implicit requestHeader : RequestHeader“):
object EmailTesting extends Controller {
def index = Action {
implicit requestHeader: RequestHeader =>
JavaContext.withContext {
Ok(views.html.testing.email.index.render())
}
}
}
Now you can use your templates from Java and Scala controllers! You can also use the JavaContext to store objects for usage in your Views without the need to add implicits all over the place.
Feel free to use this code under the Apache 2.0 License.
Update 2017:
For PlayFramework 2.6 you need to slightly adjust the code:
import play.api.mvc.RequestHeader /** * Taken from http://dominikdorn.com/2014/08/play-framework-java-scala-in-one-project-no-http-context-available/ */ object JavaContext { import play.mvc.Http import play.core.j.JavaHelpers def withContext[Status](block: => Status)(implicit header: RequestHeader): Status = { try { Http.Context.current.set(JavaHelpers.createJavaContext(header, JavaHelpers.createContextComponents())) block } finally { Http.Context.current.remove() } } }
Today I had a weird problem with one of my lxc-containers on a Ubuntu 14.04 Host.. for no reason, the container changed its IP address.. This lead to the other containers not finding the container in question under its IP anymore.
I then tried to manually set the IP of the container in /etc/network/interfaces like this
# auto eth0
# iface eth0 inet static
# address 192.168.0.42
# network 192.168.0.0
# netmask 255.255.255.0
# broadcast 192.168.0.255
# gateway 192.168.0.1
However, this was not a good idea.. the container failed to start and basically hung like this:
# lxc-start -n lyrix-prod
<4>init: plymouth-upstart-bridge main process (5) terminated with status 1
<4>init: plymouth-upstart-bridge main process ended, respawning
<4>init: hwclock main process (7) terminated with status 77
<4>init: plymouth-upstart-bridge main process (15) terminated with status 1
<4>init: plymouth-upstart-bridge main process ended, respawning
<4>init: ureadahead main process (8) terminated with status 5
<4>init: plymouth-upstart-bridge main process (19) terminated with status 1
<4>init: plymouth-upstart-bridge main process ended, respawning
* Starting Mount filesystems on boot ...done.
* Stopping Send an event to indicate plymouth is up ...done.
* Starting Signal sysvinit that the rootfs is mounted ...done.
* Stopping Read required files in advance (for other mountpoints) ...done.
* Starting Clean /tmp directory ...done.
* Stopping Clean /tmp directory ...done.
* Starting Populate and link to /run filesystem ...done.
* Stopping Populate and link to /run filesystem ...done.
* Starting Track if upstart is running in a container ...done.
* Starting load fallback graphics devices ...done.
* Starting workaround for missing events in container ...done.
<4>init: udev-fallback-graphics main process (101) terminated with status 1
* Starting load fallback graphics devices ...fail!
<4>init: console-font main process (119) terminated with status 1
* Stopping workaround for missing events in container ...done.
* Starting userspace bootsplash ...done.
* Starting Initialize or finalize resolvconf ...done.
<4>init: setvtrgb main process (133) terminated with status 1
* Starting Send an event to indicate plymouth is up ...done.
* Starting configure network device security ...done.
* Stopping userspace bootsplash ...done.
<4>init: console-setup main process (153) terminated with status 1
* Stopping Send an event to indicate plymouth is up ...done.
* Starting Signal sysvinit that virtual filesystems are mounted ...done.
* Starting Signal sysvinit that virtual filesystems are mounted ...done.
* Starting Bridge udev events into upstart ...done.
* Starting Mount network filesystems ...done.
* Starting Signal sysvinit that local filesystems are mounted ...done.
* Starting configure network device security ...done.
* Starting device node and kernel event manager ...done.
<30>systemd-udevd[202]: starting version 204
* Starting Signal sysvinit that remote filesystems are mounted ...done.
* Starting Failsafe Boot Delay ...done.
* Starting flush early job output to logs ...done.
* Starting load modules from /etc/modules ...done.
* Stopping Mount filesystems on boot ...done.
* Stopping load modules from /etc/modules ...done.
* Stopping flush early job output to logs ...done.
* Stopping Mount network filesystems ...done.
* Starting configure network device ...done.
* Starting configure virtual network devices ...done.
* Starting system logging daemon ...done.
* Starting Bridge socket events into upstart ...done.
* Starting Bridge file events into upstart ...done.
^C ---- container was stuck here....
I resolved it with this ServerFault answer .. now I always configure my containers IP in its container-config file and let the container use the IP it gets from “the BIOS”.
/var/lib/lxc/$containername/config
lxc.network.type=veth
lxc.network.link=lxcbr0
lxc.network.flags=up
lxc.network.ipv4 = 10.0.3.220/24
lxc.network.ipv4.gateway = auto
The containers /etc/network/interfaces now looks like this
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
Tada! My containers now always get the IPs I want them to get 🙂
I’m using PlayFramework 2.3 [1] on a new project of mine. Because I want the project to be safe by default, I enabled CSRF (Cross Site Request Forgery) Protection globally [2] [3].
In this project, I’m doing a pass-through of some legacy pages using a custom proxy I’ve built. These pages don’t know the concept of CSRF-Tokens and therefor need to be excluded from CSRF checking.
Unfortunately the PlayFrameworks CSRF-Filter currently only allows to either disable CSRF Protection globally and only enable it on certain actions or enable it globally and disable it nowhere… that’s not really what I want..
To accomplish my goal, I had to create a little hack.. thanks to the decorator pattern [4] it is only a few lines of code. It consists of 3 easy steps.
1. Adjust your Global.scala file like this
2. Adjust your routes file. Actions that should be excluded from the CSRF Check need a comment #NOCSRF above them like this
3. This is it basically. If you need your page to have a CSRF Token available (because it e.g. contains a login form), annotate or wrap your actions accordingly
For Scala:
Ärger mit dem “Gebühren Info Service” (GIS) des Österreichischen Rundfunks?
Dafür bietet die GIS eine Hotline… leider ist dies eine 0810 Nummer, welche trotz etwaiger Freiminunten in gängigen (Mobil)telefontarifen kostenpflichtig ist (10ct/Minute).
Abhilfe schafft hier ein kleiner Trick… man sieht sich dazu die aktuellen Nummern der GIS an:
Service Hotline
0810 00 10 80
Fax
05 0200 300
man nehme nun die Fax-Nummer und ersetze die 300 durch 100 und gelangt so zur “Telefonzentrale” des Gebühren Info Services. Von dort kann man sich bequem in die verschiedenen Abteilungen oder auch zur Hotline verbinden lassen.. ganz ohne Mehrkosten.
GIS Gratis Hotline “Telefonzentrale”:
05 0200 100
Hat das geholfen? Folge mir auf Twitter !
I recently ran across a problem with the Embedded Glassfish 4 maven problem.. as soon as I tried to activate any CDI specific stuff, I got the following exception:
Sep 08, 2013 11:05:37 PM org.glassfish.deployment.admin.DeployCommand execute
SEVERE: Exception while loading the app : CDI deployment failure:WELD-001524 Unable to load proxy class for bean Implicit Bean [javax.enterprise.inject.Instance] with qualifiers [@Default] with class interface javax.enterprise.inject.Instance using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
org.jboss.weld.exceptions.WeldException: WELD-001524 Unable to load proxy class for bean Implicit Bean [javax.enterprise.inject.Instance] with qualifiers [@Default] with class interface javax.enterprise.inject.Instance using classloader WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:306)
at org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:60)
at org.jboss.weld.bootstrap.BeanDeployer.doAfterBeanDiscovery(BeanDeployer.java:354)
at org.jboss.weld.bootstrap.BeanDeployment.afterBeanDiscovery(BeanDeployment.java:280)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:522)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:213)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.maven.PluginUtil.doDeploy(PluginUtil.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.maven.AbstractDeployMojo.doDeploy(AbstractDeployMojo.java:239)
at org.glassfish.maven.RunMojo.execute(RunMojo.java:68)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name "javax/enterprise/util/TypeLiteral"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
at java.lang.Class.privateGetPublicMethods(Class.java:2641)
at java.lang.Class.getMethods(Class.java:1457)
at org.jboss.weld.bean.proxy.ProxyFactory.addMethodsFromClass(ProxyFactory.java:513)
at org.jboss.weld.bean.proxy.ProxyFactory.addMethods(ProxyFactory.java:468)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:402)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:299)
... 50 more
Sep 08, 2013 11:05:37 PM PluginUtil doDeploy
INFO: Deployed null
As it turned out, this is a problem with Maven 3.1 which now bundles Plexus without correctly isolating the classpath.
If you have this problem as well, use Maven 3.0.5 instead.
This issue is reported on the Glassfish JIRA.
I’ve messed around a lot to get JRebel to work with the Embedded-Glassfish 4 maven plugin. Especially, as I thought maven would spawn an own JVM and I had to alter the domain.xml for it to work… I was soooo wrong.
Simply adding the JRebel Plugin to my pom.xml and adjusting my MAVEN_OPTS was enough.
Thats my pom.xml
and I simply start the app with
mvn clean package
MAVEN_OPTS="-noverify -javaagent:/home/domdorn/.jrebel/jrebel.jar" mvn embedded-glassfish:run
While JRebel is usually the tool of choice when it comes to fast redeploy cycles, its not always required to get your app redeployed really fast and keep development iterations short.
This example shows you how you can use the embedded-glassfish maven plugin to develop apps with Vaadin7 that redeploy in under a second.
The basic idea is to keep the generated war file respectively the exploded directory as small as possible.
We can achieve this by packaging all the required libraries with the application server itself and only including them as dependency with “provided” scope.
The only thing left is to fix some classloader issues that prevent loading of UIs and Themes.
So lets get started:
Here’s the pom.xml file:
Note that we’re declaring the vaadin dependencies in provided scoped and additionally as plugin-dependencies for the maven embedded-glassfish plugin.
Also note, that at the time of this post, there’s an version 4.0 of the embedded-glassfish maven plugin, but it was broken (at least on my computer) resulting in non working glassfish instances.
Next we’ll need to create a subclass of the Vaadin Servlet to prevent issues with the classloader not seeing classes of our webapp. Create one like this
Then register it in your web.xml:
That’s it!
Compile your app with
mvn clean package
, then start the server with
mvn embedded-glassfish:run
.
When changing classes, either recompile with
mvn compile package
or better configure your IDE to deploy classes to target/${project.artifactId}-${project.version}/WEB-INF/classes
.
Then simply press ENTER in the window where you started the embedded-glassfish instance.
This should get you redeploys in under one second. If you’re app grows large and deployment wait time rises, I highly recommend to use JRebel.
I also wrote a post on what to do if embedded glassfish is complaining about expired certificates. It might come handy.
Was this article useful? Do you have other tips to improve the developer productivity with Vaadin ? Share them in the comments below!
I’m messing around with the Embedded Glassfish 4 Maven plugin and came across this error:
Sep 07, 2013 10:40:11 PM com.sun.enterprise.security.ssl.impl.SecuritySupportImpl checkCertificateDates
SEVERE: SEC5054: Certificate has expired: [
[
Version: V3
Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 23741889829347261660812437366387754385443431973861114865490414153884050331745811968523116847625570146592736935209718565296053386842135985534863157983128812774162998053673746470782252407673402238146869994438729551246768368782318393878374421033907597162218758024581735139682087126982809511479059100617027892880227587855877479432885604404402435662802390484099065871430585284534529627347717530352189612077130606642676951640071336717026459037542552927905851171460589361570392199748753414855675665635003335769915908187224347232807336022456537328962095005323382940080676931822787496212635993279098588863972868266229522169377
public exponent: 65537
Validity: [From: Fri Aug 14 16:50:00 CEST 1998,
To: Thu Aug 15 01:59:00 CEST 2013]
Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
SerialNumber: [ 01b6]
Certificate Extensions: 4
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:5
]
[2]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [1.2.840.113763.1.2.1.3]
[] ]
]
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 76 0A 49 21 38 4C 9F DE F8 C4 49 C7 71 71 91 9D v.I!8L....I.qq..
]
]
]
Algorithm: [SHA1withRSA]
Signature:
0000: 41 3A D4 18 5B DA B8 DE 21 1C E1 8E 09 E5 F1 68 A:..[...!......h
0010: 34 FF DE 96 F4 07 F5 A7 3C F3 AC 4A B1 9B FA 92 4.......<..J....
0020: FA 9B ED E6 32 21 AA 4A 76 C5 DC 4F 38 E5 DF D5 ....2!.Jv..O8...
0030: 86 E4 D5 C8 76 7D 98 D7 B1 CD 8F 4D B5 91 23 6C ....v......M..#l
0040: 8B 8A EB EA 7C EF 14 94 C4 C6 F0 1F 4A 2D 32 71 ............J-2q
0050: 63 2B 63 91 26 02 09 B6 80 1D ED E2 CC B8 7F DB c+c.&...........
0060: 87 63 C8 E1 D0 6C 26 B1 35 1D 40 66 10 1B CD 95 .c...l&.5.@f....
0070: 54 18 33 61 EC 13 4F DA 13 F7 99 AF 3E D0 CF 8E T.3a..O.....>...
0080: A6 72 A2 B3 C3 05 9A C9 27 7D 92 CC 7E 52 8D B3 .r......'....R..
0090: AB 70 6D 9E 89 9F 4D EB 1A 75 C2 98 AA D5 02 16 .pm...M..u......
00A0: D7 0C 8A BF 25 E4 EB 2D BC 98 E9 58 38 19 7C B9 ....%..-...X8...
00B0: 37 FE DB E2 99 08 73 06 C7 97 83 6A 7D 10 01 2F 7.....s....j.../
00C0: 32 B9 17 05 4A 65 E6 2F CE BE 5E 53 A6 82 E9 9A 2...Je./..^S....
00D0: 53 0A 84 74 2D 83 CA C8 94 16 76 5F 94 61 28 F0 S..t-.....v_.a(.
00E0: 85 A7 39 BB D7 8B D9 A8 B2 13 1D 54 09 34 24 7D ..9........T.4$.
00F0: 20 81 7D 66 7E A2 90 74 5C 10 C6 BD EC AB 1B C2 ..f...t\.......
]
Sep 07, 2013 10:40:11 PM com.sun.enterprise.v3.server.AppServerStartup postStartupJob
INFO: Undefined Product Name - define product and version info in config/branding 0.0.0 (0) startup time : Embedded (1,472ms), startup services(1,467ms), total(2,939ms)
Sep 07, 2013 10:40:11 PM org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread run
INFO: JMXStartupService has disabled JMXConnector system
Sep 07, 2013 10:40:11 PM com.sun.enterprise.connectors.jms.util.JmsRaUtil getInstalledMqVersion
WARNING: RAR7000 : Check for a new version of MQ installation failed : /tmp/gfembed2546515913036538019tmp/lib/install/applications/jmsra/../imqjmsra.rar (No such file or directory):/tmp/gfembed2546515913036538019tmp/lib/install/applications/jmsra/imqjmsra.rar
Sep 07, 2013 10:40:12 PM PluginUtil startGlassFish
INFO: Started GlassFish ServerId = maven, GlassFish = com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime$1@4bdb635a, TimeTaken = 1,887 ms
A quick search revealed some hints on Stackoverflow. Unfortunately, they all refer to Glassfish running as standalone, not in an embedded fashion.
Long story short, you’ll have to update the jar file used by the glassfish-embedded maven plugin like this:
mkdir -p /tmp/gf
cd /tmp/gf
unzip /home/domdorn/.m2/repository/org/glassfish/main/extras/glassfish-embedded-all/4.0/glassfish-embedded-all-4.0.jar
chmod +rwx * -Rf
# default keystore password is "changeit"
keytool -delete -keystore config/cacerts.jks -alias gtecybertrust5ca
zip -r ../glassfish-embedded-all-4.0.jar .
mv /home/domdorn/.m2/repository/org/glassfish/main/extras/glassfish-embedded-all/4.0/glassfish-embedded-all-4.0.jar /home/domdorn/.m2/repository/org/glassfish/main/extras/glassfish-embedded-all/4.0/glassfish-embedded-all-4.0.jar_backup
cp ../glassfish-embedded-all-4.0.jar /home/domdorn/.m2/repository/org/glassfish/main/extras/glassfish-embedded-all/4.0/glassfish-embedded-all-4.0.jar
Of course, you’ll have to replace “/home/domdorn/.m2/repository” with the path to your local maven repository.
Recently I had to work with a Oracle instance and had to use a query that uses a subquery like (the IN … statement) this
SELECT * FROM table_a WHERE id IN (...)
The method I had to implement/fix takes an arbitrary number of ids as arguments.. if you get
more than 1000 ids, Oracle will spill a message like this into your fa.. aehm.. onto your console:
"ORA-01795 maximum number of expressions in a list is 1000"
To “fix” this problem, I wrote a small utility class that creates sub-collections of a specific maximum size out of a given collection.
Here it is:
As I keep finding myself searching for orm.xml templates as well as persistence.xml templates for JPA 1.0 and JPA 2.0, I decided to post them here for my own reference and others to find 😉
orm.xml template for JPA 1.0
persistence.xml template for JPA 1.0
orm.xml template for JPA 2.0
persistence.xml template for jpa 2.0
With these templates your favorite IDE should be able to autocomplete the allowed tags on its own.