I have a jar file .I want to include it into BE and want the output to be same as in eclipse.
How do I add this file and use the methods of it.
I tried adding it into the build path of the project folder but the methods are not coming under CUstom Functions.I am not sure if this is the correct way or not
How do i go about it.?
Help required.
Your jar file needs to contain a file called "functions.catalog" that describes the static methods of your classes that are exposed to BE as custom functions. The XML format for functions.catalog is described in the dev guide (Chapter 18 in BE 5.1.1's Developer's Guide).
Note that you can only expose static methods to BE. So a "classical" library will require you to write static wrapper methods around everything that is non-static.
Related
I need to read properties file located inside resources folder of buildSrc special module to create kotlin object which will be accessible by other project modules.
I tried to put this properties file
in the root project folder(this case sometimes works sometimes not, so I look for more reliable case)
inside of buildSrc folder directly
and now trying by putting inside "conventional" resources folder inside buildSrc which even highlighted by ide as recognized resources folder
But during assembling of modules I get Exception file not found on the line load()
So 2 questions:
where properties file should be located
how to read it from kotlin inside buildSrc module.
Gradle has a somewhat complex class-loading hierarchy, and I don't know enough of it to be able to explain what is going on under the hood. However, I can give you some hints.
First of all, the methods getResource and getResourceAsStream is present in both a Class and a ClassLoader, and they behave differently.
On a Class, if you don't prefix it with a slash, it will look for resources relative to the package of the class. With a slash, it looks at the root of the hierarchy. As you don't know the package of the compiled script as done by Gradle, the correct way to reference the file is javaClass.getResourceAsStream("/file.properties") (notice the slash).
If you use the methods from a ClassLoader instead, a leading slash is meaningless. So here, Thread.currentThread().contextClassLoader.getResource("file.properties")) is correct.
The last thing to consider is when you can use the methods from the class and when you have to use a ClassLoader. From what I can tell, you can use the class method when in the same project (or plugin). So this should work from within buildSrc. But if you want to get the resource outside buildSrc, I believe you need to go through the context classloader.
After trying different variants I have found 100% stable and working variant - instead of reading a properties file, parsing it and validating input - just use kotlin objects as ready to use configuration! With this approach the problem of a current folder and accessibility of resources is gone which is what I needed.
I am new to Spring framework . I am trying to extend any one of the current viewResolver and trying to override the buildView() method to have a custom logic of my own to read a file from file system (on the server) and display it .
This is a prototype and is investigating on how can i implement it with spring .
Problem i am facing is that i am not able to convert the File to an AbstractView to be returned from buildView .
Any ideas ?
Not really an answer, but it does give hints and is too long for a comment.
The problem here is that a JSP needs to be compiled to java file then to a class file to be executed. This is normally done by the servlet container for files located in the war (exploded or not). I do not know a public API to do that conversion outside of the web application folder.
Possible hints:
tie the application to a specific servlet containers and use explicitely methods or tools of that servlet container. I think Tomcat's JSP compiler is documented, and at least as it is free software you can look in the source how to use it.
forget JSP and use a template solution such as Thymeleaf, Freemarker or Velocity. As there is no compilation phase, it will be much easier and portable. At least Velocity includes a loader that loads files from an absolute folder in file system.
I'm having a problem I simply can't get my head around.
I'm creating a jsf application where I (as administrator) can upload a jar file, and that way around update the application.
Through this tutorial: http://docs.oracle.com/javase/tutorial/deployment/jar/jarclassloader.html I have managed to classload the jar file. The first issue is that I can only class load as "Object" and not cast to an other class type. I get a ClassCastException.
JarClassLoader jcl=new JarClassLoader(url);
Class cl= jcl.retreiveClass(jcl.getMainClassName());
Object ob=cl.newInstance(); //I would like to make this a RouteBuilder object instead of Object
Concretely I'm using Apache Camel, where I can add routes to an existing "core" (CamelContext). What's happening is that I have the core of apache camel running in my web app, and I can then add routes runtime. It's a route I want to package as a jar and load into the app runtime (I want to develop and test the route in my local environment, and then afterwords upload it to the production application). A concrete route is just a simple java class that extends RouteBuilder. I want to upload the jar, classLoad (URLClassLoader) the main class (maybe the whole jar? - does that make sense?), and convert it to a RouteBuilder. This seems to be impossible. I have chosen to upload the jar file to a folder outside my war, so that the routes do not get erased when I restart the webapp (is this smart or should this be done in an other way?). Is that a problem regarding name spaces? Furthermore, I haven't been able to find out whether I need to traverse my entire jar file and classload ever single class inside. Any comments on that?
To me it seems like I have some fundamental misconceptions on how extending / updating a java application is done. I simply can't find any good examples/explanations on how to solve my problem and therefore I conclude that I don't get this on a conceptual level.
Could someone elaborate on how to extend a running jsf application (I guess the same issues are relevant in native java apps), explain how to upload and class load a jar at runtime, and how to cast loaded classes to other class types than Object?
Thanks
Lasse
If you are interested in loading Routes without stopping your application you could consider using an OSGi container like Karaf. Karaf provides support for Apache Camel routes out-of-the-box: http://camel.apache.org/karaf.html
All class loading is managed by the OSGi container and you just need to run some commands to update things. I am not sure if this could work with your JSF application but it worths to take a look.
Can i use a service in the class file which is generated using javaassist. how can i achieve that?? and as this class is created dynamically how can i register that this class is using the provided service of another class?
I've asked a similar question here.
The smallest unit of 'installation' would be a bundle. You could generate a sort of 'virtual bundle' around your class file, including a OSGI-INF/componentX.xml descriptor, and install that into OSGi.
If it changes, regenerate the bundle and update OSGi.
I didn't go down this path as I have a lot of generated code (about 4500 different scripts that all have dependencies) and I fear that I'd get into problems if I'd generate that many bundles.
I also got a tip about the Felix Dependency manager, but I haven't thoroughly checked that out yet, it might do the things we need.
Right now in our project, we have below mentioned structure. Our project is mainly using GWT & Spring framework.
com.customername.projectname.client.module name
com.customername.projectname.client.rpc.module name
com.customername.projectname.shared.validator.module name
com.customername.projectname.server.module name
com.customername.projectname.spring.dao.module name
com.customername.projectname.spring.service.module name
Our application.gwt.xml contains below entry for source which needs to be coverted in to java script.
source path='client'
source path='shared'
As we are using spring at the server side, we are using spring annotation to mark the services and DAO and then in applicationContext.xml we are using below configuration to scan the DAO and Service Layer.
<context:annotation-config/>
<context:component-scan base-package>
Now our client wants to go with below mentioned structure. Grouping everything by module. Also in our case module is not GWT module. It is just like diff. parts of the application.
com.customername.projectname.modulename.client
com.customername.projectname.modulename.rpc
com.customername.projectname.Modulename.validator
com.customername.projectname.Modulename.server
com.customername.projectname.Modulename.spring.dao
com.customername.projectname.Modulename.spring.Service
My question is:
Is the upper approach is recommended considering it is very large application?
If the above approach is to be implemented , how to go about setting up the packages/source files which needs to be converted by gwt compiler from java to java script. Should I mention each module name in application.gwt.xml?
Question 1) I agree with edwardTheGreat, your initial package structure sounds perfectly reasonable. You will only have to list the client and shared packages (the ones that need compiled into javascript) in your gwt.xml file.
Question 2) If you do change the package structure, like you've mentioned, you will have to list every module's client and shared directories in your gwt.xml file. As Daniel said, you could break each module out into it's own "GWT module," and then inherit the GWT modules you need in each application module.
To achieve this, you would have to make each inherited GWT module's source available to the inheriting module. Whether you do this through Maven, Ant, etc., doesn't matter. But the top-level GWT module must have compile-time access to the source for all inherited GWT modules. For example:
<module rename-to='A'>
<inherits name='org.example.B' />
... other inherits, entry-point, etc. ...
<source path='client' />
<source path='shared' />
</module>
With this structure, module 'A' must have access to the source of module 'B'. Module 'B' can be built as you normally would a GWT module, but then, at compile-time, module 'A' must have B's source on the classpath.
To answer the second question, you should have one .gwt.xml file for each module, pointing out the client (and shared) directories in that module. For the GWT modules that use other GWT modules, you should use "inherit" in the .gwt.xml file to refer to them.
This page describes some of these concepts quite well:
http://code.google.com/webtoolkit/doc/latest/DevGuideOrganizingProjects.html
Question 1)
If it makes sense to you, and other developers it sounds like a fairly decent project structure. (Taken from Here)
You should bundle these classes and
the interface in a package for several
reasons, including the following:
You and other programmers can easily determine that these types are
related.
You and other programmers know where to find types that can provide
graphics-related functions.
The names of your types won't conflict with the type names in other
packages because the package creates a
new namespace.
You can allow types within the package to have unrestricted access to
one another yet still restrict access
for types outside the package.
Question 2)
Let me just clarify, in Regards to:
Should I mention each module name in application.gwt.xml?
you mean packages right?
...
<entry-point class='com.customername.projectname.AppEntryPoint'/>
<source path="modulename.client"/>
<source path="modulename.anotherpackage"/>
</module>
Any package (starting from the package that the .gwt.xml is in) in the GWT Module, should be referenced in the .gwt.xml if it is to be compiled by the GWT Compiler, any sub-packages of the referenced packages will automatically be compiled by the GWT Compiler.
Not Sure what your question is in regard to the Spring Configuration.
Hope that Helps.