OOOHHH, now that's enterprisey

tarunik

That being said, NOT_A_WTF

Actually, hitting localhost gratuitously has been known to be a WTF in the past -- some "firewalls" get twitchy about it....

Yamikuronue

I like Java.

Beans are retarded.

Also apparently someone tried to do Beans in coldfusion at one point. We have a few SomethingSomethingBean classes floating around that survived the Bean Genocide when someone realized the amount of overhead instantiating an object in Coldfusion causes.

RaceProUK

@Yamikuronue said:

I like Java

It has a certain charm, but I much prefer C#
@Yamikuronue said:

Beans are retarded

Agreed; as far as I can tell, they're just objects with a fancy name.

"A Rose by any other name would still smash robots with her Piko Hammer"

Yamikuronue

I like C# too. I don't like Visual Studio Kiddies who can't write anything without a Design View to hold their hand, tho, so I rarely admit liking C# in case I get saddled with a bunch of them.

Sometimes I wonder if most of the people who claim to hate Java and like C# aren't really just hating J2EE the way I hate Visual Studio's wizards.

Magus

@Yamikuronue said:

Design View

*shudder* I like XAML, so I naturally distrust the designer.

Onyx

I'm fond of QML myself (though I didn't have a chance to use it much yet). I find it more readable than XML of any kind.

Random piece of code grabbed from a tutorial:

qt-signal-slot/main.qml at master · wisoltech/qt-signal-slot

Connect QML to C++ with signals and slots. Contribute to wisoltech/qt-signal-slot development by creating an account on GitHub.

RaceProUK

@Magus said:

*shudder* I like XAML, so I naturally distrust the designer.

Blend is a much better designer anyway

FrostCat

@powerlord said:

You realize that we're not just talking about separating the front-end and back-end code into separate projects?

I am impressed. I thought the situation I was in recently where I eventually wrote a limited-functionality reverse proxy to pass information out of a WAR in Tomcat into an application in IIS was fucked. There was at least a half-assed reason for that.

FrostCat

@Maciejasjmj said:

And probably cross-origin-problematic. I've seen worse, though...

They're probably located in the same web server (by which I mean e.g., Tomcat, not a VM), so cross-origin shouldn't be an issue. If it is, there's ways around it, as I discovered, with the reverse proxy I mentioned a post up, and one of them is "cheat, and don't use AJAX, but HttpURLConnections".

FrostCat

@blakeyrat said:

Would I get the WTF if I knew what a WAR was?

A war is a jar file you use to deploy a servlet/JSP application into a server like Tomcat. The web server automatically unpacks it, which seems a bit overengineered to me, from my limited experience.

FrostCat

@blakeyrat said:

I honestly don't get the WTF here.

As I said, talking about something slightly different, it just seems like it's over-engineered.

FrostCat

@blakeyrat said:

Right; I just don't get why that thing has a name.

Because they came out about the same time as ActiveX controls, and were sort of competitiion for them, before everyone decided they didn't like ActiveX.

FrostCat

@boomzilla said:

I send my calling card with the servant, you savage.

I believe you.

FrostCat

@Captain said:

But a text message could be sensible.

Don't tell @boomzilla, because he left his phone in the other room, because he needed that hand to hold his onion.

dkf

@RaceProUK said:

Agreed; as far as I can tell, they're just objects with a fancy name.

And some conventions on some method names. That's all. (Well, unless you choose to get fancy-pants and write lots of descriptors and shit, but that's totally not necessary.)

EJBs are something else. They're server-side only objects that basically represent business concepts (often but not always mapping to database tables) and they've got a whole load of stuff wrapped around them to handle all the transactions, parallelisation, message handling, etc. The idea is that almost of that stuff is best not written by an ordinary programmer (e.g., transaction handling is fairly tricky) so the container framework deals with it correctly for them. Sometimes it even works first time.

The whole EJB ecosystem is at the core of why Java isn't going away any time soon. It's huge and bureaucratic and complicated, but it deals with such a lot of the irritating details of building an app server that replacing it with something else is hard, and starting from scratch using something else often a very questionable decision. Front-end code might be done with something else — there's loads of choices there because hipsters seem to love writing front-end code systems — but the back-end stuff is really constrained in what you might choose.

Thinking enterprisey? Think EJB!

RaceProUK

@dkf said:

EJBs are something else. They're server-side only objects that basically represent business concepts (often but not always mapping to database tables) and they've got a whole load of stuff wrapped around them to handle all the transactions, parallelisation, message handling, etc. The idea is that almost of that stuff is best not written by an ordinary programmer (e.g., transaction handling is fairly tricky) so the container framework deals with it correctly for them. Sometimes it even works first time.

So… basically like NHibernate or Entity Framework then

dkf

@RaceProUK said:

So… basically like NHibernate or Entity Framework then

Those only address part of what EJB does, which is much more focussed on things like transaction management. EJB's really an entire technology stack (well, a specification of one; implementations are things like Weblogic, and there's quite a few of them, mostly commercial).

Eldelshell

TRWTF is people still using the term J2EE after ten years or so since it was deprecated.

Anyway, this is pretty normal stuff. A WAR for the API (I bet it's using Jersey or CXF) and the other one with the JSP (or whatever that you render HTML with).

Is this the best design? Depends on the application and the requirements, but it usually does, as the architect suggested, in case you want to use a mobile app in the future or move all the UI code to a SPA.

Now, if you're going to use the Java everywhere and render the HTML server side & want a separate API a good design would be:

web.war ----|---- common.jar
api.war-----|

Where api.war should only be a webservice wrapper and your controllers/models living in common.war

boomzilla

@FrostCat said:

because he needed that hand to hold his onion.

blakeyrat

@dkf said:

Those only address part of what EJB does, which is much more focussed on things like transaction management.

I don't understand why transactions need to be "managed." You open it. You do your shit. You either commit it at the end, or roll it back.

sloosecannon

@Eldelshell said:

use a mobile app in the future

So, I don't really get how this would help you make a mobile app... It's not like you can deploy a .wawwr file to a phone, so you're probably doing something native-ish... meaning you basically need to rewrite everything anyways.

And apparently my keyboard felt like inserting two extra ws.. Left in for comedic effect...

dkf

@blakeyrat said:

I don't understand why transactions need to be "managed." You open it. You do your shit. You either commit it at the end, or roll it back.

You've then got to write the code to do the opening, committing and rolling back. Each blasted time, and a substantial business application can have hundreds of the silly things. So you think “there's gotta be a better way” and there is: transaction management. The container/framework handles the transactions for you, you just need to annotate the methods with enough info for it to figure out what to do (there are actually quite a few options, most of which you don't usually need to think about). At that point, your code just needs to say “do this method in a transaction” and all that stuff will get handled for you; committing is just a normal return, and rolling back is just throwing an exception out (the cost of an exception is much less than the cost of the network traffic) because that's the only sane way to tell the caller than their request really broke.

Which isn't to say that you can't write it by hand. You can. It's just belgiuming annoying to have to do it.

(The complicated cases have to do with library code that is sometimes called from in an transaction and which is sometimes called direct. Conditional transactions exist to make your head ache when scaled up to a whole application…)

blakeyrat

@dkf said:

You've then got to write the code to do the opening, committing and rolling back.

No; the guys on the SQL Server team already did that.

Anything inside the transaction that doesn't alter the database doesn't matter one whit.

Your description makes it sound like a great way to stupidly over-complicate code for no practical reason, though.

boomzilla

@blakeyrat said:

No; the guys on the SQL Server team already did that.

The guys on the SQL server team didn't come and put lots of "start transaction" "rollback" and "commit" stuff in your application, and I don't think the DB knows when your application wants to do all of that. The framework does all that for you so you never have to worry about it. It just happens.

Filed Under: INB4 YOU CAN'T ANTHROPOMORPHIZE MY PROGRAM

dkf

Please try not to demonstrate so firmly that you don't know what you're talking about. ;-)

The database engine understands transactions, but it doesn't understand the points where the transaction boundaries have to be placed, and can't; that's the job of the application. It's possible to tell the database engine enough to let it figure those things out (e.g., by strictly using stored procedures) but that's got its own problems as it is moving more of the application logic into the DB engine.

It also doesn't work if you've got to get two databases in use in the same transaction. (I don't do that myself, but I know people who do.)

Getting stuff like this right is why people write application servers in the first place. There's a lot more to this stuff than just setting a few a few fields in a database table someplace; that's just the most trivial thing you could be doing with it…

RaceProUK

@dkf said:

You've then got to write the code to do the opening, committing and rolling back. Each blasted time, and a substantial business application can have hundreds of the silly things.

In my experience, with the .NET stuff I've used, that's really very little code:

using (var tran = Session.BeginTransaction()) {
    //Do stuff
    tran.Commit();
}

Rollbacks are handled by the act of disposing the transaction.

dkf

@RaceProUK said:

In my experience, with the .NET stuff I've used, that's really very little code:

That's still more than you need to actually do when using the EJB transaction manager stuff, which in practice is usually just slapping a @Transactional on a method's signature. Supremely easy.

tarunik

@dkf said:

You've then got to write the code to do the opening, committing and rolling back. Each blasted time, and a substantial business application can have hundreds of the silly things. So you think “there's gotta be a better way” and there is: transaction management. The container/framework handles the transactions for you, you just need to annotate the methods with enough info for it to figure out what to do (there are actually quite a few options, most of which you don't usually need to think about). At that point, your code just needs to say “do this method in a transaction” and all that stuff will get handled for you; committing is just a normal return, and rolling back is just throwing an exception out (the cost of an exception is much less than the cost of the network traffic) because that's the only sane way to tell the caller than their request really broke.

Which isn't to say that you can't write it by hand. You can. It's just ■■■■■■■ing annoying to have to do it.

Which is all fine and great, but can be handled by an @run_in_transaction decorator without the need for an entire belgium-ing framework! Of course, the RAII-type approach @aliceif mentioned also works -- I've done that in C++/MFC/ODBC and it's really not much code at all, albeit slightly more than the decorator approach. (The RAII approach is a bit more flexible WRT code structure, though...)

Filed under: Java philosophy: "we have a problem" "oh, let's make a gigantic framework for that!"

aliceif

@tarunik said:

Of course, the RAII-type approach @aliceif mentioned also works

I think you confused me with someone else.

blakeyrat

@boomzilla said:

The guys on the SQL server team didn't come and put lots of "start transaction" "rollback" and "commit" stuff in your application, and I don't think the DB knows when your application wants to do all of that.

Right; but I don't need a "framework" because each of those things is literally one line of code. I don't need a "framework" to replace 3 lines of code.

@boomzilla said:

The framework does all that for you so you never have to worry about it. It just happens.

I'm guessing you still have to worry about it.

@dkf said:

The database engine understands transactions, but it doesn't understand the points where the transaction boundaries have to be placed, and can't; that's the job of the application.

It's a REST API. I open the transaction when the REST call comes in; close it when the call finishes; rollback if there's an exception.

@dkf said:

It also doesn't work if you've got to get two databases in use in the same transaction. (I don't do that myself, but I know people who do.)

You could just NOT over-complicate your shit and use a single database.

@dkf said:

Getting stuff like this right is why people write application servers in the first place. There's a lot more to this stuff than just setting a few a few fields in a database table someplace; that's just the most trivial thing you could be doing with it…

I think it's great for people who like to write 57 lines of code where 1 would do.

boomzilla

@blakeyrat said:

Right; but I don't need a "framework" because each of those things is literally one line of code. I don't need a "framework" to replace 3 lines of code.

In various places. I never want to hear you bitch about having to repeat code or boilerplate stuff. I know that's a pipe dream.

@blakeyrat said:

I'm guessing you still have to worry about it.

You're a terrible guesser. I never have to call "commit" or "rollback" to my DB.

blakeyrat

@boomzilla said:

In various places.

Nope.

@boomzilla said:

You're a terrible guesser. I never have to call "commit" or "rollback" to my DB.

Well with those two lines of code you saved, that must add up to, wow, minutes of savings a year! Maybe for your next feat of time-saving, you can stop using the restroom and just wear diapers.

Look, the time I'd save with something like this would be eaten up by a single boring training meeting. And we get those about once a month or so.

I'd be adding hundreds or thousands of lines of somebody else's code to my project, in a way that makes it virtually impossible to debug.

I'd remove the ability to do useful things-- for example, mock-up my data-changing functions and ensure they're 100% correct before I add/uncomment the .Commit() line. So I don't need to restore my test data 47 times a day.

It sounds like a really dumb idea.

boomzilla

@blakeyrat said:

It sounds like a really dumb idea.

Ideas you don't understand usually do.

boomzilla

@blakeyrat said:

It's a REST API. I open the transaction when the REST call comes in; close it when the call finishes; rollback if there's an exception.

So everything that happens goes through a single method in your code?

blakeyrat

Nope.

EDIT: well yeah, I guess, if you count the WebAPI router. But it doesn't do database transactions.

boomzilla

@blakeyrat said:

EDIT: well yeah, I guess, if you count the WebAPI router. But it doesn't do database transactions.

I was thinking about your code. I don't know what a WebAPI router is, but that sounds like a framework sort of thing.

So how does it work that you have a single place in your code that deals with starting, rolling back or committing all of your transactions?

blakeyrat

@boomzilla said:

I was thinking about your code. I don't know what a WebAPI router is, but that sounds like a framework sort of thing.

I wouldn't be using it, either. Since it's more pointless framework code that replaces like... maybe 500 lines, max, of actual useful code.

@boomzilla said:

So how does it work that you have a single place in your code that deals with starting, rolling back or committing all of your transactions?

Magical faeries.

We don't. Not all of the REST calls dig into the database. The ones that do have this HORRIBLE AWFUL REDUNDANT OMG LOOK AT ALL THE WASTED EFFORT line of code: using( var t = CompanyTransaction.Create() );

LOOK AT ALL THE WASTED CHARACTERS OMG OMG OMGO MGOSDGMSID frujhuw

boomzilla

@blakeyrat said:

We don't. Not all of the REST calls dig into the database.

So...you were lying when you said you didn't have to manually put in commits and stuff wherever you needed them?

blakeyrat

@boomzilla said:

So...you were lying when you said you didn't have to manually put in commits and stuff wherever you needed them?

If I had said that, in that wacky hypothetical world where white is black and up is down, I would be a liar. Yes.

I don't see how that relates to this reality, since I never said that.

rad131304

@boomzilla said:

So how does it work that you have a single place in your code that deals with starting, rolling back or committing all of your transactions?

If he's using Entity Framework, EF does those automatically for any simple transaction. Basically anytime you might add/edit/delete a POCO (aka bean) in storage.

It might make sense to write an attribute (method decoration) to prevent some of the simple race conditions, but it would depend on your application and how you connect to your data layer.

source

boomzilla

@blakeyrat said:

I don't see how that relates to this reality, since I never said that.

Scroll up a bit, where you said:

@blakeyrat said:

Right; but I don't need a "framework" because each of those things is literally one line of code. I don't need a "framework" to replace 3 lines of code.

I'm trying to think of an infiniscroll vs paging alternate reality joke, but it just doesn't seem worth it here.

boomzilla

@rad131304 said:

If he's using Entity Framework, EF does those automatically for any simple transaction.

Right, but he's pretty indignant about someone thinking he doesn't write his own transactions. And we haven't had an EF COMPLAIN in a while, so I think it's a save assumption that that isn't what's going on here.

FrostCat

@boomzilla said:

The guys on the SQL server team didn't come and put lots of "start transaction" "rollback" and "commit" stuff in your application, and I don't think the DB knows when your application wants to do all of that. The framework does all that for you so you never have to worry about it. It just happens.

In a Progress database, the first time you update a record, you begin a transaction automatically. You control the end of it with, essentially, lexical scope, not unlike a C# using block: when you hit the end of the block that encloses the transaction, the whole thing is automatically committed. In fact, there's not even a "commit" command per se. There's almost no mucking about with the stuff you see in SQL code.

belgariontheking

Java coders: Here's what EJBs are. EJB is a framework that does all this stuff for me.

Blakey: That sounds retarded now let me tell you about the framework I use that has no demonstrable difference.

powerlord

I should probably point out that as an application writer, I don't have to use the entire EJB3 stack if I don't need it.

It's split into a large number of child specifications. For example, the data storage part (JPA) is separate. The transaction part (JTA) is separate... oh and by the way, JPA does DB transactions even if JTA isn't loaded... JTA applies to entire methods instead.

Heck, I don't even have to use the EJB3 core. It's actually pretty common for simple webapps to just use a JPA implementation like Hibernate and use it with a web framework like Spring MVC.

Before someone asks why I'd want to add another framework, I'm going to point out that if you're not reading environment variables and using STDIN/STDOUT¹, you're already using a web framework of some sort. I actually did that back in my Perl days and I'd rather not go back to those days.

¹This is how web servers communicate with web applications as per the CGI specification.

blakeyrat

Obviously I meant exactly 3 lines of code ever for all time. You got me.

Eldelshell

@sloosecannon said:

So, I don't really get how this would help you make a mobile app

In my example api.war is a REST API used by the web client and by the mobile clients.

@sloosecannon said:

It's not like you can deploy a .war file to a phone

No kidding.

blakeyrat

I don't use WebAPI by choice. That is what this company chose to go with. I think it was a dumb idea.

boomzilla

@blakeyrat said:

Obviously I meant exactly 3 lines of code ever for all time. You got me.

That was the only way stuff you said made sense. If it was literally 3 lines in a single app, then maybe you have a point. But you didn't so you don't. Which was my point.

sloosecannon

@Eldelshell said:

In my example api.war is a REST API used by the web client and by the mobile clients.

Well yeah, but you can put the API and the web frontend in the same warfile, giving you the API for mobile/smart toaster use and the frontend for web-based stuff