I have a dashboard library that we use at our company. It has an Initializer. The wicket.properties file is stored in the same package as the rest of the code, not in a META-INF folder. After upgrading to Wicket 7 I started noticing the following warning:
/wicket.properties location is deprecated. Please move the file to /META-INF/wicket/ folder and give it a name that matches your packages' name, e.g. com.example.myapp.properties
So I thought, no problem, I'll just follow the instructions in the well written message and move the properties file and rename it. I renamed the file to com.redi.wicket.dashboard.properties and moved it to META-INF/wicket folder. Now I get the following warning:
/META-INF/wicket/*.properties doesn't work in OSGi and single-jar environments and is not supported anymore! Please see https://issues.apache.org/jira/browse/WICKET-5997 for more details and report an issue for the library that still uses it.
I looked at WICKET-5997, WICKET-6030 AND WICKET-5713 and tried to piece together what I was supposed to do.
I've noticed in the Application class there are deprecated methods regarding this and one, collectWicketProperties, that will be removed in 7.3.0. So I'd like to get this fixed while it is fresh on my mind and not have it bite me down the road when I upgrade.
So where do I put my initializer properties file and what do I name it?
Thanks
I figured it out by looking at the code for org.apache.wicket.Application. Here the developers mention that you should use the ServiceLoader class for Initializers. https://issues.apache.org/jira/browse/WICKET-5997. I noticed the Application.initInitializers method and saw the ServiceLoader class they were talking about.
So I read up on the java.util.ServiceLoader class and it states the following:
A service provider is identified by placing a provider-configuration file in the resource directory META-INF/services. The file's name is the fully-qualified binary name of the service's type. The file contains a list of fully-qualified binary names of concrete provider classes, one per line.
So I created a META-INF/services folder and put a text file named org.apache.wicket.IInitializer and inside the file I put the fully qualified class name of my IInitializer implementation.
The warning went away and my Initializer was called on application startup which is exactly what I wanted.
NOTE: If you are migrating from using wicket.properties make sure to take out the "initializer=" part of the file. The new way is not a properties file so it doesn't have key value pairs. It only has fully qualified class names separated by new lines. See the java.util.ServiceLocator documentation if you need more details.
Also if you are using maven, the META-INF/services folder will go in src/main/resources.
Related
I've got a project and want to share an API that can be used for building a plugin for my application.
Now I don't want to share the full source code but only class definitions and member declarations without their body.
I've seen dependencies before that without downloading the sources the IDE I'm using already knows the structure. That is what I'm going for.
A jar file already does most of what you want, as it does, if not obfuscated, contain all the class and method names in a format that will be understood by any Java IDE.
The rest can be done by preparing and delivering a javadoc jar.
In JDeveloper 12c, I have created a BPM application/project. Project SOA Settings are Composite With Business Rule.
The project has a Mediator and is exposed as a REST service. I am deploying using the IntegratedWebLogicServer
The XML Facts are rather generic including lists of fields, sub-lists, and sub-sub-lists, etc. This makes navigating the inputs more challenging.
I created a Java class with some static methods that more easily retrieve the data based on an expression. I created a jar with that class and then imported the class into the Java Facts. I then created rules that call the static methods on that Java Fact.
The rules validate just fine and I can now successfully run the rules from the "Test" tab of the rules. I get expected results. However, when I deploy the project it seems like the imported jar is not deployed along with it since I get the following exception:
oracle.rules.rl.exceptions.UndefinedException: The symbol "mypackage.MyUtil" is undefined.
at line 22 column 14 in /Ruleset(main)
I thought that importing the class in the Java Facts would cause my custom jar or at least the class that I imported to be deployed. But it seems that this may not be the case. Am I missing something? Is there somewhere in my project that I can place the jar to cause it to be deployed?
I tried adding the jar to the Libraries and Classpath entries of the project. I also tried adding it to a user library located in the project and adding that to the Libraries and Classpath list. But both had no effect.
I am new to JDeveloper and Oracle BPM, so I'm hoping there's something simple I'm missing here.
The solution was to add the jar to this directory:
MyBpmApplication\MyBpmProject\SOA\SCA-INF\lib
Today I started learning Java.
I saw that package automatic gets included in .Java file.
I was wondering if it always need to be included?
Consider specify a common package for all the types within a same project.
In Java is common to start a project with a specific package setting. A package creates a namespace to disambiguate the types that it includes, to play nicelly with other projects that may or may not be in the same classpath. Normally, the package is bound to a URL of the project.
Think of Java packages like C++ namespaces.
A huge project/product written in Java can depend on lots and lots of projects, each described in a different package.
Organizations like Apache have lots of projects, organized under a common package pattern: org.apache.<<name_of_the_project>>.
Consider starting your project with a package named: com.user3552670; or something like your personal site, so persons that will consume your project can relate to the creator.
Yes and no.
It's used to specify the package of the class, read more here.
You could create a class without a package, but your code will look bad..
They exists to avoid conflicts, example between your code and default java package.
If packages doesn't exists, you can't create a class named ArrayList because already exists in Java.
Some IDEs force the fact that, if your .java file is in com/a/b/c folder his package should be com/a/b/c (If i don't remember wrong, IntellIJ IDEA do that)
Yes and no.
It must be there, but the IDE takes care of it (I don't use Netbeans, but I'd bet that it can do it, too). When moving files between packages, it has to be updated, but again, the IDE does it all.
I'm having difficulty working out the correct properties for sonarQube for my project. The folder structure is as following:
mod/
framework/
Framework.java
rebuild2/
Rebuild2.java
sonar-project.properties
There isn't much yet in either java file but do have they do have package declarations (mod.framework and mod.rebuild2 respectively).
I've tried a variety of different ways to write the properties file but it always errors with "The source directory does not match the package declaration". It seems like it is expecting the folders to be mod.framework/ and mod.rebuild2/.
I've looked through the documentation on the main website but all their examples do not have package declarations. I've also searched through here but either the solutions do not work for this or they are maven/gradle configs.
Does anyone have any idea whether it is possible to set up the sonar-project.properties file for this situation?
# Required metadata
sonar.projectKey=mc:rebuild2
sonar.projectName=Rebuild 2
sonar.projectVersion=0.2
# The value of the property must be the key of the language.
sonar.language=java
# Encoding of the source code
sonar.sourceEncoding=UTF-8
sonar.modules=framework,rebuild2
framework.sonar.projectName=Framework
framework.sonar.projectBaseDir=mod
framework.sonar.sources=.
rebuild2.sonar.projectName=Rebuild 2
rebuild2.sonar.projectBaseDir=mod
rebuild2.sonar.sources=.
If Java file(say File.java) has package delacration like :
package com.abc.xyz;
for a file, It means that file should be inside folder structure like
com
abc
xyz
File.java
But in your case may be, this rule is voided. And your code should not compile too.
Please check, this may be the case.
There is something conceptually wrong in your configuration.
Either the 'Framework' and 'Rebuild 2' projects are separate modules (think sub-projects) that have separate source trees; or they are merely separate packages in the same source tree, in which case you can remove the lines below sonar.sourceEncoding=UTF-8.
Your configuration tries to define 2 modules in the same source tree, and I don't think this is supported by current analyzers, except using exclusions, e.g:
sonar.modules=framework,rebuild2
framework.sonar.projectName=Framework
framework.sonar.projectBaseDir=.
framework.sonar.sources=.
framework.sonar.inclusions=mod/framework/**
rebuild2.sonar.projectName=Rebuild 2
rebuild2.sonar.projectBaseDir=.
rebuild2.sonar.sources=.
rebuild2.sonar.inclusions=mod/rebuild2/**
See Multi-module Project configuration in the SonarQube documentation.
We are developing a fairly large project and have many dependencies. Recently, we ran into an issue with a conflict between two of them, agileAPI.jar and axis.jar. Both are 3rd party libraries.
The code in question depends directly on agileAPI.jar. If I build it with just that in the build path, everything that depends on it works correctly.
As soon as I add axis.jar to the build path (just adding it, not writing code that depends on it), everything goes wrong. Some of the code that depended on the first library is now throwing exceptions from the 2nd library. It is as if the first library is picking and choosing methods to call from the 2nd library, instead of whereever it was calling them from prior.
I have code in the project that needs axis.jar directly, so I can't just remove it from the build path. I need to find a way to have these two exist in the same build path, but ignore each other.
It should be noted that both libraries coexisted prior to a recent upgrade with agile. I have been working with Oracle's support team to try and resolve this. After two weeks, though, I am looking for other sources of help.
Our environment is Windows and Eclipse, although in testing this, it also occurs when running java from a command line. Our JDK is 1.5.0_22.
Any help would be appreciated.
Thank you,
David
EDIT:
As requested, here are the stack traces that we see. The first stack trace is printed in the code beyond my control:
java.lang.NoSuchMethodError: org.apache.axis.description.OperationDesc.setStyle(Lorg/apache/axis/constants/Style;)V
at com.agile.webfs.components.fileserver.client.FileServerSoapBindingStub._initOperationDesc1(FileServerSoapBindingStub.java:37)
at com.agile.webfs.components.fileserver.client.FileServerSoapBindingStub.<clinit>(FileServerSoapBindingStub.java:20)
at com.agile.webfs.components.fileserver.client.FileServerWSServiceLocator.getFileServer(FileServerWSServiceLocator.java:43)
at com.agile.webfs.client.IFSLocator.getRemoteFileServer(IFSLocator.java:128)
at com.agile.webfs.client.IFSLocator.getConnection(IFSLocator.java:101)
at com.agile.api.pc.EJBLookup.createFileSession(EJBLookup.java:444)
at com.agile.api.pc.EJBLookup.getFileSession(EJBLookup.java:432)
at com.agile.api.pc.attachment.IFSOutputStream.getFileSession(IFSOutputStream.java:133)
at com.agile.api.pc.attachment.IFSOutputStream.copyFrom(IFSOutputStream.java:87)
at com.agile.api.pc.attachment.IFSOutputStream.copyFrom(IFSOutputStream.java:115)
at com.agile.api.pc.TableAttachment.uploadFile(TableAttachment.java:886)
at com.agile.api.pc.TableAttachment$AddFiles2Action.doSdkAction(TableAttachment.java:724)
at com.agile.api.common.SDKAction.run(SDKAction.java:23)
at com.agile.api.common.OracleAuthenticator.doAs(OracleAuthenticator.java:131)
at com.agile.api.common.Security.doAs(Security.java:54)
at com.agile.api.common.Security.doAs(Security.java:109)
at com.agile.api.pc.TableAttachment.addFiles2(TableAttachment.java:483)
at com.agile.api.pc.TableAttachment.createNewBlob2(TableAttachment.java:459)
at com.agile.api.pc.TableAttachment.doCreateServerRowWithParam(TableAttachment.java:363)
at com.agile.api.pc.Table.createTableRow(Table.java:238)
at com.agile.api.pc.TableAttachment.createTableRow(TableAttachment.java:169)
at com.agile.api.pc.Table.createRow(Table.java:202)
at com.[snip].updateAttachments(VaultImportService.java:3068)
at com.[snip].processIncorporatedFile(VaultImportService.java:926)
at com.[snip].processPdxFile(VaultImportService.java:532)
at com.[snip].processPdxRequest(VaultImportService.java:388)
at com.[snip].<init>(VaultImportService.java:299)
at com.[snip].main(VaultImportService.java:3660)
After the exception bubbles up and we catch it, the stacktrace that we print looks like:
at com.agile.api.pc.Session.createError(Session.java:1772)
at com.agile.api.pc.EJBLookup.createFileSession(EJBLookup.java:454)
at com.agile.api.pc.EJBLookup.getFileSession(EJBLookup.java:432)
at com.agile.api.pc.attachment.IFSOutputStream.getFileSession(IFSOutputStream.java:133)
at com.agile.api.pc.attachment.IFSOutputStream.copyFrom(IFSOutputStream.java:87)
at com.agile.api.pc.attachment.IFSOutputStream.copyFrom(IFSOutputStream.java:115)
at com.agile.api.pc.TableAttachment.uploadFile(TableAttachment.java:886)
at com.agile.api.pc.TableAttachment$AddFiles2Action.doSdkAction(TableAttachment.java:724)
at com.agile.api.common.SDKAction.run(SDKAction.java:23)
at com.agile.api.common.OracleAuthenticator.doAs(OracleAuthenticator.java:131)
at com.agile.api.common.Security.doAs(Security.java:54)
at com.agile.api.common.Security.doAs(Security.java:109)
at com.agile.api.pc.TableAttachment.addFiles2(TableAttachment.java:483)
at com.agile.api.pc.TableAttachment.createNewBlob2(TableAttachment.java:459)
at com.agile.api.pc.TableAttachment.doCreateServerRowWithParam(TableAttachment.java:363)
at com.agile.api.pc.Table.createTableRow(Table.java:238)
at com.agile.api.pc.TableAttachment.createTableRow(TableAttachment.java:169)
at com.agile.api.pc.Table.createRow(Table.java:202)
at com.[snip].updateAttachments(VaultImportService.java:3068)
at com.[snip].processIncorporatedFile(VaultImportService.java:926)
at com.[snip].processPdxFile(VaultImportService.java:532)
at com.[snip].processPdxRequest(VaultImportService.java:388)
at com.[snip].<init>(VaultImportService.java:299)
at com.[snip].main(VaultImportService.java:3660)
In both cases, the line "at com.agile.api.pc.Table.createRow(Table.java:202)" is the agileAPI call that I am making. I have removed our package structure, as it identifies the company that I work for. They value privacy and security.
I'd advise you to check these two things first:
Open the axis.jar file with some zip utility, like 7-Zip or WinRar. See if there's a folder called "services" in the META-INF folder in the jar. If there is, it's possible that the axis.jar file specifies implementations for specific interfaces that somehow don't interoperate with agileAPI. Also do the same for agileAPI.jar, since it might itself declare an interface implementation that axis doesn't like.
Open both agileAPI.jar and axis.jar with a zip utility, then check if there's packages with the same name. If there's none, it won't be a naming conflict. If there's one or more, open the corresponding folders and do the same check recursively. If you end up with at least one class with the same name in the same package across the two jars, it's probably a naming conflict.
That should catch the most obvious issues. If none of this is the case, we'll need to look deeper.
A way to solve such classpath issues is to use a module system such as OSGi or the NetBeans Platform module system where each module has its own classloader.