Perry Terrance

Stephan van Hulst wrote:Can you show us the requests and responses that the network analyzer displays when you send those requests?

This is what FIREFOX is showing in the NETWORK tab:

XHR OPTIONS https://12.345.678.90:8081/myAPI/test


HEADERS
Accept
*/*
Accept-Encoding
gzip, deflate, br
Accept-Language
en-US,en;q=0.5
Access-Control-Request-Headers
role
Access-Control-Request-Method
GET
Connection
keep-alive
DNT
1
Host
12.345.678.90:8081
Origin
https://12.345.678.90:8080
Referer
https://12.345.678.90:8080/
User-Agent
Mozilla/5.0 Gecko Firefox/87.0

No RESPONSE whatsoever

Security does show a:
An error occurred: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

Not sure if this is relevant since I'm testing my own SSL implementation here as well...

From what I understand the CORS config I did here should ALLOW just about EVERYTHING to go through - GET/POST/OPTION - any ORIGIN - any PORTS - etc...

As you are probably aware looking at this - my webpage is hosted on the 8080 PORT and my Spring Boot API is on the 8081 PORT of the same IP...

Stephan van Hulst wrote:I think what you wrote should work.

How do you know that it doesn't? How are you sending the request? What error message are you getting?

For example in my FIREFOX console - if I put the following:

await fetch("https://12.345.678.90:8081/myAPI/test", {    "credentials": "omit",    "referrer": "https://12.345.678.90:8080/",    "method": "GET",    "mode": "cors" });

I get the following:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://12.345.678.90:8081/myAPI/test. (Reason: CORS request did not succeed)



Here's something very strange though - I do have a SWAGGER page setup at https://12.345.678.90:8081/myAPI/swagger-ui/.

If goto that page first - and then use the FIREFOX console fetch command once more - the GET request goes through the 2nd time...

I'm trying to get CORS working in a very simple SpringBootApplication, but I keep hitting the CORS issue - when calling the GET from the browser:

@SpringBootApplication public class SWApplication { public static void main(String[] args) { SpringApplication.run(TestApplication.class, args); } @Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurer() { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**"); } }; } }

From what I read - this is all I should need to open up CORS for everything... but it still doesn't work... Am I missing something?

Dave Tolls wrote:The fix options can be got using Alt-Return (at least on mine).
Yes, clicking on the red line on the right-side gutter just takes you to the error.

Whats the shortcut for Mac? Also does that mean there will not be any context menu popups from clicking on it?

Just switching to IntelliJ from a decade use of Eclipse.

Some newbie questions...

In Eclipse - if there is a line that has issues - I can click on the little red bracket line at the left line-number of my code - and it pops up with a menu with suggested auto-fixes.

In IntelliJ - I see this little red line bracket at the right-side but clicking on the line doesn't pop up any menu to do anything - just on-screen suggestions - with no immediate auto-fixes.

Why is that?

I'm using WebSphere Liberty in Eclipse NEON and I'm trying the hardest to get my server.xml to cooperate with me.

I am deploying an EAR that has a <classloader></classloader> config on it which I want to do the following:

<classloader apiTypeVisibility="api,ibm-api,spec,third-party"/>

However, everytime I clean or start the server - somehow Eclipse automatically reverts the server.xml setting so it only shows  <classloader apiTypeVisibility="api,ivm-api,spec"> without my "third-party".

I can't figure out why it keeps doing this. Does anyone know? I need the "third-party" API to be visible here...

I have never thought about this regarding multi-thread and the static elements until now, but here it is:

I know that Static Methods are on the Heap while Threads on are on the Stack...

However, if we have two threads running - all accessing the same Static Method. Can the Static Method be executed AT THE EXACT SAME TIME by both Threads or is there usually an order of it depends which Thread (say for example Thread 1) - reaches that Static Method first - and the other (say - Thread 2) - can only execute using that same Static Method only once Thread 1 finishes using it?

Thanks Jeanne for the response - let me try that and let you know.

One more thing, I found that when I ran Eclipse Kepler on the exact same workspace - it do not any Timestamps in the Deploy Path! Is there some different between Eclipse Luna and Kepler thats causing this - cause its all reading the same workspace (basically same MAVEN settings, POMs, etc)?

I use MAVEN SNAPSHOTS for my dependencies - which typically have a naming schema like "dependency-2.1.1.01-SNAPSHOT.jar"

However - every time I update my Maven Java project in my Eclipse Luna (with internal MAVEN 3.2.1) - it gives me the Ear Module Assembly as:

Source
/home/user/.m2/repository/com/dependency-2.1.1.01-SNAPSHOT.jar
Deploy Path
dependency-2.1.1.01-20150403.221111-1.jar

It seems to constantly append the Timestamp to the Deploy Path - when I want it to stay the same naming of "-SNAPSHOT".

Is there a MAVEN configuration in Eclipse (or outside) that I'm missing somewhere?

All I want is the following:

Source
/home/user/.m2/repository/com/dependency-2.1.1.01-SNAPSHOT.jar
Deploy Path
dependency-2.1.1.01-SNAPSHOT.jar

This is causing issues on my local JBoss test server - as it expects the naming of the JARs to be exactly using the "-SNAPSHOT.jar" naming schema when its Published.

Jaikiran Pai wrote:It's a natural and common thing with connections. They don't stay alive forever. The DB server terminates the connection that it has leased out after a period of inactivity.

Datasource pools which pool open connections allow configuring a "idle timeout" on connections. The idle timeout setting allows the pool to release back connections from the pool, back to the DB server, when a certain connection hasn't been in use for the specified period of time (i.e. idle timeout). That way, the pool doesn't end up holding on to a terminated/stale connection and subsequently handing it out to the caller applications. You just need to specify an idle timeout on your pool configuration. If you are using the admin console to configure that datasource, I think you'll see the setting there (or else there are other ways to go about configuring this).

Well currently - as shown in my Config - the "Idle Timeout Minutes" is set at 0 - doesn't that mean "indefinitely"? Or is it recommended I actually set a value there - like "60000 Minutes"?

I have a brand-new WildFly 8.2.0 and local MySQL setup.

The JDBC DataSource is WildFly-managed using the "mysql-connector-java-5.1.34-bin.jar_com.mysql.jdbc.Driver_5_1" JDBC driver. In terms of the WildFly DataSource settings - everything is at default and I haven't touched anything other setting up the initial connection.

What is annoying right now is that the JDBC connection would connect promptly to my local MySQL DB - but after a few hours - it would abruptly disconnect. And then I have to end up enabling and disabling the DataSource in WildFly for the connection to be re-established?

Why is it doing this - and why can't it just stay connected to my MySQL DB forever?

Here are my WildFly DataSource settings:

Name: myTestDB JNDI: java:jboss/datasources/myTestDB Is enabled?: true Statistics enabled?: false Datasource Class: Driver: mysql-connector-java-5.1.34-bin.jar_com.mysql.jdbc.Driver_5_1 Driver Class: com.mysql.jdbc.Driver Share Prepared Statements: false Statement Cache Size: 0 Connection URL: jdbc:mysql://localhost:3306/myTestDB New Connection Sql: Transaction Isolation: Use JTA?: true Use CCM?: true Connection URL: jdbc:mysql://localhost:3306/forum New Connection Sql: Transaction Isolation: Use JTA?: true Use CCM?: true Valid Connection Checker: Check Valid Sql: Validate On Match: false Background Validation: false Validation Millis: 0 Stale Connection Checker: Exception Sorter: Use tryLock(): 0 Blocking Timeout Millis: 0 Idle Timeout Minutes: 0 Set Tx Query Timeout: false Query Timeout: 0 Allocation Retry: 0 Allocation Retry Wait Millis: 0

Is there something I am not configuring right?

It's been a while since I had been in EJB land - and now I am using the latest and greatest EJB3.1.

So naturally I get stumped by some basic things (again):

My EJB3.1 setup is like so:

MyManagedBean.java which implements LocalInterface.java interface methods (with @Stateless Annotation)
LocalInterface.java with interface methods (with @Local Annotation)

Now this whole thing is packed in an EJB-JAR file along with a WAR which is then bundled inside an EAR and crammed into my JBoss server.

So the packaging is like so:
EAR PACKAGE ->
EJB-JAR PACKAGE
WAR PACKAGE

In the WAR package - I have a controller that is using InitialContext lookup to find the EJB bundled in the EAR (and thus use it - of course).

Imagine to my surprise that this doesn't actually work!

I am using a lookup with the name
"java:global/myproject-ear-0.0.1-SNAPSHOT/myproject-ejb-0.0.1-SNAPSHOT/MyManagedBean!com.myproject.bean.MyManagedBean"

The error would say:

javax.naming.NameNotFoundException: myproject-ear-0.0.1-SNAPSHOT/myproject-ejb-0.0.1-SNAPSHOT/MyManagedBean!com.myproject.bean.MyManagedBean -- service jboss.naming.context.java.global."myproject-ear-0.0.1-SNAPSHOT"."myproject-ejb-0.0.1-SNAPSHOT"."MyManagedBean!com.myproject.bean.MyManagedBean"

Now here's the kicker:

After tinkering around with it - I found that if I ONLY add the additional annotation of @LocalBean on the MyManagedBean.java class - and restart the JBoss server again - it would find the Name!

Yet according to my research - the whole @LocalBean annotation is redundant and unnecessary since I already am implementing a LocalInterface with @Local anyways.

So whats the deal here?

Jaikiran Pai wrote:Glad to know that you got it working.

It's interesting that you had to specify the username and password as part of the connection URL (and it indeed is what the documentation states here http://technet.microsoft.com/en-us/library/ms378526%28v=sql.110%29.aspx). To me, that defeats the purpose of having a (masked) password textbox/field on the UI, for this specific driver of course.

Yeah - I know right?!

I can't believe Microsoft's official JDBC Driver is kind of backwards in this regard - it should have clearly let me put in the credentials in the proper credential fields instead of this direct-method.

Jaikiran Pai wrote:Is there anything that you see in the server.log of the server, if you have access to it?

What a brilliant idea! I found from that log that my authentication was messed up - and I had to put the authentication right in the Connection URL itself instead of the separate username/password section of the Console - and it worked!

Jaikiran Pai wrote:How are you issuing that management operation? From some code? What does it look like? Or are you using the CLI to issue it? If so, how are you connecting to the CLI? Either way, the quickest way to test a connection in pool is to use the admin console to issue that request and let it manage what management operation needs to be invoked behind the scenes.

I am setting this up completely only using the WildFly DataSource Admin Console. The error I posted is what shows in the Admin Console messages when I click on the "Test Connection" button.

I had the JDBC driver, sqljdbc4-4.0.jar, put into the Deployments folder under my Wildfly Standalone folder - and rebooted Wildfly so the Admin Console could detect the driver.

I just goto the Datasource Page of the Admin Console and select "Add Datasource" and follow the step-by-step instructions displayed.