We are working with WSO2 IS, v5.1.0.
When testing, we got the following results:
When running one suite of tests, all works ok.
When running concurrent tests, meaning - concurrent requests are being sent, we got NPE. Moreover, We got "200" on adding two users, for example, but then when trying to query and get both of them, we got a message that 2 values were expected but only 1 is returned.
Any idea how can I solve this issue? what is causing it?
Let me know if any further info is required.
Thanks!
Now I see..
there are two issues in the WSO2 IS 5.1.0 you can / have to fix.
Use of the embedded JSP pages
First - see there's a difference in the parameters of the wso2server.bat/.sh and the bin/yajsw/wrapper.conf. In the wrapper.conf add:
wrapper.java.additional.27 = -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
please change the parameter order to fit your parameter list
StringUtil bundle dependency
Here comes the NPE stacktrace in play and without it, you cannot pinpoint the exact problem. Apparently the some UI bundles are having invalid dependencies specified, particularly there's no dependency specified to the Commons-Lang StringUtil package which is used.
We have solved it by following actions:
download and copy commons-lang-2.6.jar into the repository/components/dropins
create a new OSGi bundle (assuming you know Java and how to create OSGi bundle fragments) which imports org.apache.commons.lang;version="[2.6,3)" and is a fragment to the org.wso2.carbon.identity.mgt.ui bundle. Copy this bundle to the dropins folder.
create a new OSGi bundle which imports org.apache.commons.lang;version="[2.6,3)" and is a fragment to the org.wso2.carbon.identity.application.mgt.ui bundle. Copy this bundle to the dropins folder.
Edit:
part of the maven plugin to generate the bundles
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Fragment-Host>org.wso2.carbon.identity.application.mgt.ui</Fragment-Host>
<Import-Package>org.apache.commons.lang.*</Import-Package>
<!--
<Export-Package>org.apache.commons.lang.*</Export-Package>
<Embed-Dependency>commons-lang</Embed-Dependency>
-->
</instructions>
</configuration>
</plugin>
There are multiple bundles having this issue, but to get the IS 5.1.0 usable, at least these bundles were necessary to fix.
In all cases, this answer is still based on assumptions and our experience rather than evidence (the stacktrace).
g
Related
I am trying to train a DQN agent in an environment coded in JAX, but the initialization of the trainer fails when it first tries to reset the environment (with a not-valid JAX type error). Before getting into the debugging process, I thought of looking for example projects but I cannot find anything so i am wondering whether interfacing them is not possible.
Currently there is no example in RLlib right out of the box that supports jax envs. I think the main functionalities should be there, it was just never tested with Jax envs to figure out the feature requirements and the missing parts. I encourage you to give it a try and create a feature request for it on ray's issue tracker on github and if you have bandwidth give it a try and make a contribution. You can also let the RL team know about the missing features for enabling RLlib to work on JAX envs.
I’m working with a small expo project setup where I develop for both iOS/Android and Web. I recently wanted to add styled-components to the project and got everything up and running for Web and Mobile until I started working with a Theme Provider and the theme prop. I am 99% certain that I should have done everything correctly because it works for mobile but I get a JS exception in the web version.
I’ve created a type for the theme and I know it works because my IDE tells me when I try to add something wrong to the theme.
I’ve created a theme.ts and import it in the component where I’ve implemented the ThemeProvider. I know this works because when accessing prop.theme I get auto-completion and as I said it works on mobile.
const Container = styled.View`
background-color: ${props => props.theme.color.primary};
`
This is the error I get:
TypeError: Cannot read property ‘primary’ of undefined
I suspect it might have something to do with expo’s bundler and missing loaders or something? I don’t know. To my knowledge, I did everything as in the docs and suspect it is an issue with Expo Web and the ThemeProvider.
Those are the relevant packages I'm using:
"expo": "~39.0.2"
"styled-components": "^5.2.1"
"#babel/core": "~7.9.0"
I'm blocked by this because I need to decide whether to proceed with styled components or without them.
It turns out that when you import the ThemeProvider from "styled-components" and then work with "styled-components/native" that iOS and Android builds still work but web breaks...
This was my error. Use "styled-components/native" everywhere!
Stupid me
lol... same. One thing I recommend is creating a lint rule for proper import for anyone who wants to avoid repeating this issue
I need to start a Embedded cassandra instance to perform some operations on a Cassandra keyspace via Unit tests. Programming Language is Java. What are the options to start an embedded cassandra?
I used the mojo maven plugin, however after starting the instance using following command, I do not see the cassandra instance started at default port 9042 on localhost.
Plugin:http://www.mojohaus.org/cassandra-maven-plugin/usage.html
Command to start: mvn cassandra:run -Dcassandra.nativeTransportPort=9042
Is there something missing in terms of usage or do I need to use something different?
Thanks
Jyothi
It depends on what you are trying to test. Cassandra Maven Plugin (of which I was one of the original authors) and Cassandra Unit both do something very similar in that they start an in-JVM instance of Cassandra.
This works great if you just want to do some CRUD stuff in you integration tests, but really does not help if you want to test scenarios like consistency level failures and retries in the face of various failure cases, particularly for multiple datacenters. And Cassandra is just a beast at this point so it means you need a lot of memory for you tests to run.
To really verify things like the above, I recommend using Simulacron:
https://github.com/datastax/simulacron/blob/master/doc/java_api/README.md
And an example integration:
https://github.com/datastax/java-driver/blob/9f0d89799a8a1e4cd1022dd7c43333924c36a648/integration-tests/src/test/java/com/datastax/oss/driver/api/core/ProtocolVersionMixedClusterIT.java
This is what the driver teams use to test behavior scenarios, though they still rely on a CCM test bridge (also an option) for a lot of block and tackle stuff. For both, the way it's plumbed into maven in that project should be used as an example of best practices:
https://github.com/datastax/java-driver/blob/3.x/pom.xml#L749-L816
And profile switching for such:
https://github.com/datastax/java-driver/blob/3.x/pom.xml#L925-L947
And using the profiles:
https://github.com/datastax/java-driver/blob/3.x/driver-core/src/test/java/com/datastax/driver/core/PreparedStatementTest.java#L146
To really get your head around it, I recommend pulling down the driver project and picking it apart to see how this is all put together. Probably the biggest win is that this whole project does not have any dependency on Cassandra code.
We use Cassandra unit for unit tests. This library provides useful helpers and allows to start Embedded Cassandra from code very easy
EmbeddedCassandraServerHelper.startEmbeddedCassandra();
You can also take a look at https://github.com/nosan/embedded-cassandra/wiki
e.g. If you want to start Cassandra using JUnit4 you can do this in one line:
public class CassandraRuleTests {
#ClassRule
public static final CassandraRule cassandra = new CassandraRule(CqlScript.classpath("init.cql"));
#Test
public void testMe() {
}
}
Cassandra will be forked as a separate process. You can also set path to JAVA_HOME 8 via javaHome property in case if you use java 9 and higher.
You will need to provide the below configuration to cassandra-maven-plugin to start native transport port (9042)
<startNativeTransport>true</startNativeTransport>
So your plugin will looke like
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cassandra-maven-plugin</artifactId>
<version>3.6</version>
<configuration>
<startNativeTransport>true</startNativeTransport>
</configuration>
</plugin>
I am cleaning up a build system for a product that uses Jetty. Currently the project has
javax.servlet.jsp:jsp-api:2.1
as a dependency. Given that I am using Jetty for my project I suspect using
org.mortbay.jetty:jsp-api-2.1:6.1.5
would be the better option. Am I right/wrong? Can they be used interchangeably? Does jsp-api-2.1 leverage a different implementation? Or is it simply a repackage if jsp-api to assert compatibility with Jetty?
I've been trying to find information about this on the web, so far nothing has come up.
Update: Seems like org.mortbay.jetty:servlet-api-2.5:6.1.5 and javax.servlet.jsp:servlet-api:2.1 have the same relationship.
Jetty has a long and colorful history with jsp, having no jsp implementation of our own we have leveraged other implementations often, judging by the version numbers your looking at those are very old versions where we were maintaining patches on top of the glassfish jsp implementation. I think it was a patch for supporting logging in jetty and then a bug fix or three.
Now a days we have been using the jsp artifacts from the java.net project which was spun out from glassfish a while back. However that doesn't seem to be tracking bug fixes very regularly either so we are kicking around trying the jasper implementation in tomcat.
Back on your question, the jsp-api artifacts are typically just repackaged artifacts since the api doesn't change frequently. We historically rebundled them to keep them paired with the patched implementation.
Now, you are obviously using a jetty-6 setup since your still using org.mortbay packaging but jetty6 and jetty7 are both servlet-api 2.5 so you might be able to get away with using the jetty7 jsp setup, we have a handy pom that declares these artifacts here:
http://central.maven.org/maven2/org/eclipse/jetty/jetty-jsp/7.6.5.v20120716/jetty-jsp-7.6.5.v20120716.pom
These are glassfish bundles as well, repackaged and made into osgi bundles in the process so they can be used with jetty in osgi environments....they ought to work normally though, we package them in our jetty7 distributions.
I'd just easy_install'd django-sentry and added it to my project, but when I run the tests with ./manage.py test sentry, I get 4 failures and 11 errors.
I've added, indexer, paging, sentry, sentry.client, and south to my INSTALLED_APPS, and I can get to http://localhost:8000/sentry/ in a browser (and all seems to be working). Is there more that needs to be done in order have Sentry properly configured?
I have a lot of errors too.
According to the developer:
The problem is simply that we don't
require certain dependencies as part
of the core INSTALLED_APPS.
We'll need to document the
requirements for getting tests to
pass, as well as make certain tests
only run if conditions are met (e.g.
haystack [fork], and celery tests
should check for their libraries)