hprange / woinject Goto Github PK

It would be appreciated if the InjectableApplication class code be placed into a separate service class, so that the developer doesn't have to extend InjectableApplication. This is because it is likely that the Application class is already extending a custom Application class.

Cheers,
Matt

I didn't even realise Wonder had this feature until a couple of days ago: if you're in development mode, launch an app instance on a fixed port, and then later launch another app instance on the same port, Wonder's default behaviour is for the second instance to stop the first (via the stop direct action) and then carry on launching. I had never seen this behaviour before (I regularly see "Address already in use"), and I set out to investigate why.

It seems to be the case that adding WOInject to a Wonder project prevents the catch block here from ever executing:

@Override
public WOAdaptor adaptorWithName(String aClassName, NSDictionary<String, Object> anArgsDictionary) {
	try {
		return super.adaptorWithName(aClassName, anArgsDictionary);
	} catch (NSForwardException e) {
		Throwable rootCause = ERXExceptionUtilities.getMeaningfulThrowable(e);
		if ((rootCause instanceof BindException) && stopPreviousDevInstance()) {
			return super.adaptorWithName(aClassName, anArgsDictionary);
		}
		throw e;
	}
}

Instead of calling stopPreviousDevInstance(), an InjectableApplication logs the exception and then terminates. To reproduce:

1. Create a test app from the ERXApplication archetype.
2. Launch first and second instances to a fixed port, confirming that second stops first.
3. Convert to InjectableApplication and add ApplicationRunner.
4. Launch first and second instances to a fixed port, confirming that second dies with BindException.

I can't quite see where the exception is being swallowed, and why we don't make it back to the catch block in adaptorWithName().

See Joseph's proposal:

https://github.com/cluelessjoe/woinjectproposal

See Joseph proposal:

https://github.com/cluelessjoe/woinjectproposal

The Javassist loader delegates system classes loading to the parent ClassLoader. However, classes from Apple JDK are not included in the delegation list.

The Byte Buddy library is more efficient than Javassist regarding CPU and memory usage.

The Injector initialization can search for modules declared via Wonder's framework principal mechanism.

The documentation front page has a couple of tiny typos in the dependency declaration:

<dependency>
    <groupid>com.woinject</groupid>
    <artifactid>woinject</artifactid>
    <version>1.2</version>
</dependency>

Obviously those elements should be groupId and artifactId. Easily corrected, but it does prevent copy & paste!

Initializing WOInject when the servlet context is initialized makes more sense than creating a servlet.

Hi Henrique,

It seems like there is an issue with woinject on Java 8. We upgraded our server to Java 8 this weekend and my only app using wounit doesn't want to start. Are you aware of this problem?

Thanks a lot!

Martin

Exception in thread "main" java.lang.Error: Cannot initialize the application to take advantage of WOInject features.
at com.woinject.WOInject.init(WOInject.java:89)
at com.app.AppRunner.main(AppRunner.java:8)
Caused by: java.lang.RuntimeException: java.io.IOException: invalid constant type: 18 at 15
at javassist.CtClassType.getClassFile2(CtClassType.java:204)
at javassist.CtClassType.subtypeOf(CtClassType.java:304)
at javassist.CtClassType.subtypeOf(CtClassType.java:319)
at javassist.CtClassType.subtypeOf(CtClassType.java:315)
at javassist.CtClassType.subtypeOf(CtClassType.java:315)
at javassist.compiler.MemberResolver.compareSignature(MemberResolver.java:235)
at javassist.compiler.MemberResolver.lookupMethod(MemberResolver.java:107)
at javassist.compiler.MemberResolver.lookupMethod(MemberResolver.java:84)
at javassist.compiler.TypeChecker.atMethodCallCore(TypeChecker.java:711)
at javassist.compiler.TypeChecker.atCallExpr(TypeChecker.java:688)
at javassist.compiler.JvstTypeChecker.atCallExpr(JvstTypeChecker.java:157)
at javassist.compiler.ast.CallExpr.accept(CallExpr.java:46)
at javassist.compiler.CodeGen.doTypeCheck(CodeGen.java:242)
at javassist.compiler.CodeGen.compileExpr(CodeGen.java:229)
at javassist.compiler.CodeGen.atReturnStmnt2(CodeGen.java:598)
at javassist.compiler.JvstCodeGen.atReturnStmnt(JvstCodeGen.java:425)
at javassist.compiler.CodeGen.atStmnt(CodeGen.java:363)
at javassist.compiler.ast.Stmnt.accept(Stmnt.java:50)
at javassist.compiler.CodeGen.atStmnt(CodeGen.java:351)
at javassist.compiler.ast.Stmnt.accept(Stmnt.java:50)
at javassist.compiler.Javac.compileStmnt(Javac.java:569)
at javassist.CtBehavior.insertBefore(CtBehavior.java:721)
at javassist.CtBehavior.insertBefore(CtBehavior.java:701)
at com.woinject.WOInject.init(WOInject.java:73)
... 1 more
Caused by: java.io.IOException: invalid constant type: 18 at 15
at javassist.bytecode.ConstPool.readOne(ConstPool.java:1044)
at javassist.bytecode.ConstPool.read(ConstPool.java:984)
at javassist.bytecode.ConstPool.(ConstPool.java:125)
at javassist.bytecode.ClassFile.read(ClassFile.java:770)
at javassist.bytecode.ClassFile.(ClassFile.java:114)
at javassist.CtClassType.getClassFile2(CtClassType.java:191)
... 24 more

When building a woa with wobootstrap.jar embedded, we get the following exception :

Caused by: javassist.NotFoundException: com.webobjects.foundation._NSUtilities
at javassist.ClassPool.get(ClassPool.java:450)
at com.woinject.WOInject.init(WOInject.java:66)
... 6 more

The current workaround is to build without wobootstrap.jar, but the launching generates a huge command line with the whole classpath appended

The WOSession scope gets the current Session object through the ERXSession.session() method. This method may return null if the existing session hasn't been restored yet.

In this case, the session should be restored by the WOSession scope itself.

The WOInject custom ClassLoader causes security exception and class loading problems. Example:

The encryption error:
java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(DashoA13_..)
at org.bouncycastle.openpgp.PGPEncryptedDataGenerator$PubMethod.addSessionInfo(Unknown
Source)
at org.bouncycastle.openpgp.PGPEncryptedDataGenerator.open(Unknown Source)
at org.bouncycastle.openpgp.PGPEncryptedDataGenerator.open(Unknown Source)
at com.resurgences.xdi.invs.INVSService.encryptFile(INVSService.java:1571)
(...)
Caused by: java.util.jar.JarException: Class is on the bootclasspath
at javax.crypto.SunJCE_c.a(DashoA13_..)
at javax.crypto.SunJCE_b.b(DashoA13_..)
at javax.crypto.SunJCE_b.a(DashoA13_..)