Update Weld version in Apache jetty - jetty

I am using Apache Jetty 9.2.10 which uses weld weld-servlet-2.2.5.Final.jar.
Is it possible to update weld version to the last release? I did not find a procedure to update jetty modules in its documentation.

Firstly you need to decide whether you bundle these implementations in your application or whether you want to use the module system in Jetty.
From your question I would guess it is the module way.
Then it should be very straightforward.
get weld-servler.jar and weld-servlet-core.jar in your desired version
in ${jetty_dir}/lib create a folder weld and put the above jars into it
in ${jetty_dir}/modules create weld.mod file:
and type in the following:
[depend]
jndi
annotations
plus
[lib]
lib/weld/*.jar
as a last step, edit ${jetty_dir}/start.ini and add a sinle line containing --module=weld
Now you should be able to start server and deploy an app using CDI/Weld.
Here is a link to external information about this.

Related

Disable Liquibase execution at startup using Jetty + Spring (not Spring boot!)

I'm working in an application developed with Spring5 (not Spring boot!) that runs on Jetty. This application has module that uses the plugin liquibase-maven-plugin.
We generate a image from a dockerfile (base image jetty:9-jre8), where we add the application (war file) in the jetty application directory.
In some specific environments, where I deploy the application, I want to be able to disable that execution.
Is it possible to do so?
I've seen on spring boot documentation, that it's possible to do so by defining the property spring.liquibase.enabled (or liquibase.enabled on Spring4) to false, but that seems that doesn't work:
I've tried to define them at the properties file, define them as env properties and also as java options (-Dspring.liquibase.enabled=false).
This has the same behavior when I deploy the container, or when I execute locally the maven command: mvn jetty:run
Do you have any ideas or hints how to do this?
Thank you in advance
Well I just discovered that it's possible to disable the execution of liquibase by adding the JAVA_OPTION
-Dliquibase.shouldRun=false
For more details see here
I will keep this quesion anyway, in case someone has the same problem I did.

how i can find com.ibm.ws.exception.wsexception jar file?

i added the admin.jar file correctly to the classpath and to my java application, but these errors still appear 1- The project was not built since its build path is incomplete. Cannot find the class file for com.ibm.ws.exception.WsException. Fix the build path then try building this project.
2- The type com.ibm.ws.exception.WsException cannot be resolved. It is indirectly referenced from required, i understand that there is a helper jar file should be added to my app, but unfortunetely i could not find it.
Two things here:
1) You need WebSphere classes in your build path. The server provides an API/SPI jar specifically for this purpose: WAS_HOME/dev/was_public.jar. It contains WsException, among other classes.
2) You mentioned having "admin.jar" in your class path and Java application. If that means that you're packaging a WebSphere server jar in your Java EE application... don't do that. The server jars are not designed to be packaged within apps, and you run a very high risk of unexpected linkages and class loader hierarchy issues if you try it.
If this is a standalone Java client, not a Java EE application installed on the server, there are thin client jars in WAS_HOME/runtimes that are designed to be used in client application class paths; the server jars in the plugins directory are not designed to be used outside the context of the application server itself.
I agree with Jarid that the proper way is by using the client but if you still need it, then you can download it from https://github.com/NURGALIYESMUKHAMEDOV/Utils/blob/master/CaseSchedule/src/main/resources/wsexception.jar where I found it and used it in my library too.

How do I use additional rubygems inside a custom Cloud Foundry buildpack?

I'm writing a customized java-buildpack, and I'd like the ability to edit the web.xml file to add some required configuration. However, I seem to be limited to only the rubygems that are present on the instance node, which does not include any XML parsing libraries.
How can I have the buildpack specify that it needs an additional gem to execute? Adding gems to the Gemfile in the buildpack itself doesn't seem to have any effect when staging an app.
Alternatively, how can I modify an existing XML file with only the stock facilities available in CF? I wanted to avoid a regex, but that may be a last resort.
However, I seem to be limited to only the rubygems that are present on the instance node, which does not include any XML parsing libraries.
Correct. When your build pack runs in the staging container, it's going to use the version of Ruby provided by the container. This means that you are locked into a specific version of Ruby and the set of gems provided by the container.
The only way around this would be to have a bootstrap shell script that downloads Ruby, installs your Gems, and then runs the actual build pack Ruby scripts. It's a lot of extra work and overhead though, so probably not a good option if you can avoid it.
How can I have the buildpack specify that it needs an additional gem to execute? Adding gems to the Gemfile in the buildpack itself doesn't seem to have any effect when staging an app.
I don't think that this is possible. You can't gem install something because it would require root access, and you won't have that.
What you could do instead is to include the dependencies that you need in the build pack. We did that with a YAML dependency for the PHP build pack. If your dependency is all Ruby code (i.e. no native code), this should work OK.
Alternatively, how can I modify an existing XML file with only the stock facilities available in CF? I wanted to avoid a regex, but that may be a last resort.
It depends on what you're doing and what you need to change.
Regex search and replace is an option.
Basic string search and replace is another.
You could shell out to a tool that's installed in the environment and is capable of parsing / editing the XML
If it happens later in the install after Java has been installed, you could run some Java code.
I would not recommend creating a custom stack. It's incredibly invasive, means you then need to provide all updates going forward (not a small task), and it's not something that will work if you're going to use a public cloud provider, since no one is going to allow you to install your custom stack in their public cloud.
Hope that helps!
You can create a custom stack (container root fs) with all required libraries for this purpose.
https://docs.cloudfoundry.org/devguide/deploy-apps/stacks.html
https://docs.cloudfoundry.org/adminguide/custom-stack.html

wso2 identity server remote debug source-binary mismatch

I am trying to put together an Eclipse project for remote debugging a standard wso2-identity server. I have created a user library consisting of the dozens of wso2 jar files and tried to manually identify, download and attach the appropriate source files from SVN based on the platform-chunk-patch versioning scheme. The problem is that there is one class (and possibly others) where the source-binary mapping is not in sync making debugging impossible.
An example:
https://svn.wso2.org/repos/wso2/carbon/kernel/tags/4.2.0/core/org.wso2.carbon.user.core/4.2.0/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.java
The HEAD version of this java file in SVN does not match up with the level 4 patched class binary:
./wso2is-4.6.0/repository/components/patches/patch0004/org.wso2.carbon.user.core_4.2.0.jar#uzip/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.class
I do not want to build wso2 so the nicest solution would be if someone could point me to a wso2-is-4.6.0 patch level 04 repository of binary-source bundles, either in the form of composite jars with classes+sources or maven source artifacts.
Alternatively a URL and a revision number in SVN pointing to the correct source of JDBCUserStoreManager would suffice.
You can find the required source of JDBCUserStoreManager from here. You can find the sources of all patches for kernel here.

How to test Entity classes from another Eclipse project in a Stateless Session Bean within a JUnit Test

So here's what I'm trying to do and stuck at:
I have a shared Eclipse Java project with #Entity (EJB 3.1) classes that is used by a couple of other Eclipse WebApp projects. This project itself has no persistence.xml! The other WebApp projects that use this project declare their own persistence.xml under WebContent/META-INF and refer to the JAR of this project in their persistence.xml using the jar-file tag. Of course the shared project's JAR is added as a deployment dependency in these WebApp projects and is placed under WEB-INF/lib.
Now I am creating JUnit4 Testcases to test Stateless session beans in these WebApp projects. I'm using Apache TomEE 1.5.0 Plus and in the testcase I use a #Before method to start the OpenEJB container in Embedded mode using EJBContainer.createEJBContainer() method. For this to work properly, I have created an alternate test.persistence.xml (that uses a different datasource to an HSQL memory db and creates the tables using forward mapping). I have placed this in META-INF of the src folder and in the #Before method, I set the "openejb.altdd.prefix" to "test" so that the alternate test.persistence.xml is read. All this setup is working.
The trouble is that as soon as OpenJPA 2.2.0 starts, it complains that there are no persistent classes from the shared project! This is because, the jar-file tag in test.persistence.xml refers to a jar that doesn't exist! When Eclipse deploys the other WebApp projects, it creates the JAR under WEB-INF/lib and the actual persistence.xml refers to the jar under that path! However, I do not find any such JAR when running a JUnit testcase.
So how do I refer to this JAR or the classes in the shared project in the test.persistence.xml without making the testcase itself overly dependent on deployment structure or any specific hard-coded path! This testcase will eventually be committed to the repository and hence must be such that any dev checking it out can simply run it.
Any pointers in the right direction would be greatly appreciated!
IMO the easiest and better way to do that is to use Arquillian.
It's far more easier to control the packaging, the life cycle of the container, etc
TomEE also provides a great integration (adapter) with Arquillian you can use.
Check the documentation page http://tomee.apache.org/documentation.html
There is an arquillian section.
You can also check TomEE examples page where you can find a huge amount of small samples including arquillian.
Hope it helps
Jean-Louis