Stephan van Hulst

Another avenue of failure is modifying the tree from a background thread. But yeah, without an SSCCE it's all grasping at straws.

You perpetually seem to confuse methods with types, at least, going by your wording.

You can't instantiate any method. A method is not a type. Only types can be instantiated.

Jhonson Fernando wrote:It also prevents the method from being accidentally or intentionally overridden in a subclass, which could potentially break the functionality of the interface.

I agree with most of what you said, except this last part.

Static methods can never be overridden, private or not.

I'm sorry. I can't help you anymore. I'm tired of repeatedly having to ask you for more info.

We are not clairvoyants. We can not see what actions your are performing on your machine. We can't see what files you're trying to access and how you're accessing them. This should be obvious to you, and you should lead with this info without us prompting for it.

TellTheDetails.

Good luck with your problem.

The solution that Tim hints at is not to use java.sql.Date at all, but rather java.sql.Timestamp, and then call setTimestamp() on the prepared statement. This should work just fine with datetime columns.

[edit]

Phillip, you should try this instead:
var creationDate = LocalDateTime.now(); ... statement.setTimestamp(Timestamp.valueOf(creationDate));

Your explanation is not entirely correct.

The ONLY reason your can write MockSongs.getSongStrings() instead of objectReference.getSongStrings() is because the getSongStrings() method is declared static. Whether the class has instance fields doesn't matter. You would still be able to call MockSongs.getSongStrings() if the class did have instance fields, simply by virtue of the method being declared static.

The purpose of the comment is to hint why the method was declared static.

A static method is a method that can do its job without having to access any instance fields. Since MockSongs doesn't have any instance fields in the first place, it follows logically that its methods can all be static.

Now, at the risk of confusing you again, I'm going to say that there are more important factors to consider when deciding whether to make a method static. However, the presence or absence of instance fields is still a useful hint.

This appears to be a bug in NetBeans. I'm sorry, there doesn't appear to be a workaround.

Very nicely done.

Welcome to CodeRanch!

Can you show us the source code?

It's a pity you took the Ant approach. Ant is on its way out, and it will become harder and harder for you to find online help for your projects if you stick with it. I strongly suggest that at some point, you invest some time in learning Maven. That "dopey" pom.xml file is a lot less dopey than the mess one can create for themselves with Ant build definitions.

Anyway, in order to get help with your new problem, show us the code you use to retrieve the file from the database.

It shouldn't matter. While it's odd and worrying, the XSDs are not part of your build artifact, so it shouldn't affect how the application functions.

I want you to deploy the WAR file that Maven builds into Wildfly manually. If you don't know how to do that, consult the Wildfly user manual.

If after deployment, the application still doesn't work, I want you to unpack the WAR file, and write down the directory structure for us.

Relative to what is that file path? Your project directory?

Obviously, we can't help you if you don't tell us the location of the file you created, the content of the file, and what URL you used.

Also note that I'm not going to repeat my questions this time. If you don't supply us with all the info we need, then I'm not replying.

wildfly context path