| Time |
S |
Nick |
Message |
| 00:17 |
|
sfisque |
so general question. anyone know a good way to avoid the dreaded PermGen issue with constant re-deploys, specifacally with glassfish 3.x |
| 00:17 |
|
sfisque |
besides upping the PermGen space |
| 00:18 |
|
sfisque |
wish i knew what was causing the memory leak |
| 00:24 |
|
|
madair joined ##javaee |
| 01:13 |
|
pdurbin |
"hibernate and commons logging are the two biggest perpetrators in my many intense years of experience" (perpetrators of PermGen usage) according to _Tenchi_ when I asked about PermGen in #glassfish: http://www.evanchooly.com/logs/%23glassfish/2013-03-12 |
| 01:19 |
|
|
oO0Oo joined ##javaee |
| 02:20 |
|
|
SoniEx2|2 joined ##javaee |
| 02:21 |
|
|
madair joined ##javaee |
| 03:05 |
|
|
sfisque joined ##javaee |
| 03:05 |
|
|
sfisque1 joined ##javaee |
| 03:46 |
|
|
Naros joined ##javaee |
| 03:48 |
|
Naros |
I have a legacy codebase which has been packaged in the past based upon features, ie: "com.company.app.feature" where each feature has sub packages for stuff like services, model, dao, and web |
| 03:49 |
|
Naros |
The issue I often run into is that one feature's service may depend upon another feature's service, model, or dao. |
| 03:50 |
|
Naros |
I can't seem to design such a package hierarchy that makes logical sense, avoids circular dependencies, but promotes good separations of the code base through layers. |
| 03:51 |
|
Naros |
i considered "com.company.app.services" and then "com.company.app.model", etc. |
| 03:51 |
|
Naros |
but given the size of our app, some of those packages would contain hundreds of classes. |
| 03:51 |
|
sfisque1 |
vertical slices |
| 03:52 |
|
Naros |
i've heard that term, yes. but not sure how to slice it that way |
| 03:52 |
|
Naros |
sfisque: you familiar with ERP systems? |
| 03:53 |
|
Naros |
Generally they have an Inventory (materials management) module, Accounts Payable, Accounts Receivable, Purchasing, Sales, etc modules |
| 03:53 |
|
sfisque |
sort of. i've written an MDM from the ground up, as well as other enterprise data/xact systems |
| 03:53 |
|
Naros |
and each module talks to other modules through well defined interfaces and APIs |
| 03:53 |
|
sfisque |
aye |
| 03:53 |
|
sfisque |
well that's the concept, whether it happens or not in reality |
| 03:54 |
|
Naros |
aye. |
| 03:54 |
|
Naros |
The current code base is broken out similiar to those modules |
| 03:54 |
|
Naros |
there is an inventory package, a purchasing package, a repair, warranty, etc packages |
| 03:54 |
|
sfisque |
aye, but the problem is they consume the same entities, and cross call services? |
| 03:54 |
|
Naros |
and each of those contain their own related services, repository, model, and view components |
| 03:54 |
|
Naros |
Right |
| 03:55 |
|
Naros |
So the repair service might need to actually fetch an item for some repair process. |
| 03:55 |
|
sfisque |
segmenting entities doesnt work very well, i have fround. easier to just put them all together in an "entity library" that the other higher systems consume |
| 03:56 |
|
sfisque |
services are easier to segment because you can build a separate "stub lib" with the interface/stubs |
| 03:56 |
|
Naros |
Right, that is the first thing I have done. I actually was planning to create a persistence jar with all repository and entity objects. |
| 03:56 |
|
Naros |
but in that jar, i didn't want to dump all 2500 entities into a single package either |
| 03:57 |
|
sfisque |
it's kind of superfluous. it won't change the classloading and with an ide, you won't notice anyway |
| 03:58 |
|
Naros |
Understand, it's just that this code base is continually growing and I want to keep it to some decent standard if at all possible. |
| 03:58 |
|
Naros |
So in the persistence jar, I was going to have com.company.app.persistence.<module> with a repository and model sub package |
| 03:58 |
|
sfisque |
think of it this way, the only packaging that would make sense is if there exists a logical boundary in the schema (you can drop several tables, and the remaining tables all operate properly in with referential integrity |
| 03:59 |
|
sfisque |
explain the diff between model and repositolry in this context |
| 03:59 |
|
Naros |
repository is the DAOs |
| 03:59 |
|
Naros |
model is the Entities |
| 03:59 |
|
sfisque |
oh. spring? |
| 03:59 |
|
Naros |
Yep. |
| 03:59 |
|
sfisque |
gotcha |
| 04:00 |
|
Naros |
Usually there is a 1:1 between an entity & dao with a lot of the dao being abstracted to a base framework with extentions on specific daos where necessary |
| 04:00 |
|
sfisque |
then yes. EXCEPT be careful of coupling the dao layer that closely to the entities. DAO layers can churn harder than entities and you want these deep libraries to solidify as much as possible |
| 04:00 |
|
Naros |
e.g.: stuff like getUserByName() would be a custom DAO method for a User entity |
| 04:00 |
|
sfisque |
aye |
| 04:01 |
|
sfisque |
in the EE sense, you wouldnt package session beans with entities |
| 04:01 |
|
sfisque |
but DAO's are slightly different |
| 04:01 |
|
Naros |
but to your comment about referential integrity. there are large portions of entities that refer to a common set of other entities. |
| 04:02 |
|
sfisque |
right. but there must be at the very least, a boundary between "data" and "metadata" |
| 04:02 |
|
Naros |
ie: repair record depends on an item, a facility, a customer, a user, and perhaps a vendor and purchase order line. |
| 04:02 |
|
sfisque |
so that gives you at least 2 entity packages |
| 04:02 |
|
Naros |
So I guess I need to look at the DB relationships and build the package structure perhaps from that so that I don't have circular dependencies between packages |
| 04:02 |
|
sfisque |
aka, you can drop all the data tables and the metadata tables will still operate properly |
| 04:03 |
|
sfisque |
aye |
| 04:03 |
|
sfisque |
if you have objects taht "span" like join tables and such, you can put them in a third package |
| 04:03 |
|
* SoniEx2 |
hugs sfisque in an overly cute way ^-^ |
| 04:03 |
|
Naros |
Right, such as a core package or somesuch. |
| 04:04 |
|
Naros |
but in the case of lets say an Item, which is heavily associated to a lot of higher level entities in the relationship diagram. |
| 04:04 |
|
* sfisque |
hugs soniex2 back |
| 04:04 |
|
SoniEx2 |
^-^ |
| 04:05 |
|
Naros |
even if it's in an inventory package, so long as inventory doesn't depend lets say on purchasing but purchasing depends on inventory, that would be alright. |
| 04:05 |
|
sfisque |
aye. bi-directional graphs get fuzzy, but you get the idea |
| 04:05 |
|
Naros |
b/c logically a purchase order has a relationship to an inventory item entity. |
| 04:05 |
|
sfisque |
yup |
| 04:06 |
|
Naros |
So sounds like I'm on the right track, it's just I have read a bit of package by layers, not by features. |
| 04:06 |
|
Naros |
and I see the above as package by feature, perhaps because of how the app has evolved over time. |
| 04:06 |
|
sfisque |
gotta slice both directions (vertical and horizontal) |
| 04:06 |
|
Naros |
Aye, I believe Springs approach is horizontal in the package, vertical by module iirc. |
| 04:07 |
|
sfisque |
aye. jboss projects are similarly structured |
| 04:07 |
|
sfisque |
so is osgi |
| 04:07 |
|
Naros |
where often org.sf.<module> |
| 04:07 |
|
sfisque |
aye |
| 04:07 |
|
Naros |
so considering modules, persistence would be one. |
| 04:08 |
|
Naros |
another would be the services tier |
| 04:08 |
|
Naros |
the other would be the web or view |
| 04:08 |
|
sfisque |
view / controller / service / persistence (as a start, then modularize within each realm) |
| 04:09 |
|
Naros |
aye |
| 04:09 |
|
sfisque |
those are the basic 4 horizontal slices. you can slice them vertically by feature/domain |
| 04:09 |
|
Naros |
That was the direction I was taking. |
| 04:09 |
|
sfisque |
acct view vs. inventory view vs report view |
| 04:09 |
|
sfisque |
etc. |
| 04:09 |
|
Naros |
one last question. |
| 04:10 |
|
sfisque |
never |
| 04:10 |
|
sfisque |
there is always more :P |
| 04:10 |
|
Naros |
lol. our services make heavy use of spring annotations |
| 04:10 |
|
Naros |
but our services are exposed via a public api interface |
| 04:11 |
|
Naros |
for the implementation side, naming & package naming wise, worthwhile to distinguish it's dependence on spring? |
| 04:11 |
|
Naros |
e.g. SpringInventoryService vs InventoryServiceImpl |
| 04:11 |
|
sfisque |
depends. are you using the spring proprietary annotations or are you using the CDI annotations that spring supports? |
| 04:11 |
|
sfisque |
if its the former, i'd say yes. if its the latter, shouldnt matter |
| 04:12 |
|
Naros |
Just using @Service, @Resource, @Autowired, @PreAuthorize/@PostAuthorize/@PostFilter |
| 04:12 |
|
sfisque |
well, 2 of those 6 are cdi, the rest are spring proprietary |
| 04:12 |
|
Naros |
Aye. |
| 04:12 |
|
sfisque |
so yes, i'd say make it obvious that you're dependent on spring |
| 04:13 |
|
sfisque |
bbiab, time to tuck in the kids |
| 04:13 |
|
Naros |
likewise, ty for the insight. |
| 04:28 |
|
|
Quest joined ##javaee |
| 04:35 |
|
|
Naros joined ##javaee |
| 05:15 |
|
xll11 |
I never understood annotations |
| 05:15 |
|
xll11 |
even going through the trails |
| 05:16 |
|
xll11 |
maybe it is because I don't use XML yet, and annotations is sort of xml replacement? |
| 05:17 |
|
Quest |
yes |
| 05:58 |
|
Quest |
annotations were meant to replace xml, and I think they are easy |
| 06:18 |
|
Quest |
Naros, http://stackoverflow.com/questions/17986486/loginid-not-passed-to-userdetailsservice-for-spring-security |
| 06:18 |
|
Quest |
if you are free. ^ I dont know why I just cant settle down. spring is not that complicated. Iam just stuck on simple initial start things. :) |
| 06:35 |
|
|
caverdude joined ##javaee |
| 07:29 |
|
Quest |
Naros, Solved. Nevermind ^ I answered bellow for others to refer in similar situations. |
| 08:21 |
|
|
SoniEx2|2 joined ##javaee |
| 10:02 |
|
pdurbin |
sfisque: did you see what I wrote about PermGen? |
| 10:23 |
|
Quest |
pdurbin, permgen. the thing that usually gets out of memory errors? |
| 11:20 |
|
|
SoniEx2 joined ##javaee |
| 11:46 |
|
pdurbin |
Quest: yes, that permgen thing: http://irclog.greptilian.com/javaee/2013-08-01#i_15596 |
| 11:47 |
|
Quest |
hm |
| 12:53 |
|
Naros |
permgen typically is an issue in large apps that use proxies. |
| 12:54 |
|
Naros |
With so many entities in our system, we quickly ran out of it and had to increase it from the JVM default. |
| 12:54 |
|
Naros |
anywho, commute time to work. be back in 15-30. |
| 13:32 |
|
|
Naros joined ##javaee |
| 14:01 |
|
|
grug joined ##javaee |
| 14:16 |
|
sfisque |
pd i did not, i must have been in transit when you responded |
| 14:17 |
|
sfisque |
oh, nm, i see the link in scrollback |
| 14:18 |
|
sfisque |
yes i know about the commons.logging permgen leak (that's been around for about a decade now) |
| 14:18 |
|
sfisque |
i was unaware that hibernate had one too. thing is, though that afaict, glassfish does not use either |
| 14:18 |
|
Naros |
hibernate doesn't have a leak, it's just that depending on the size of the app, the default permgen size isn't sufficient due to all the proxies which get created and the metadata which must be maintained. |
| 14:19 |
|
sfisque |
ok. i know commons.logging does (or at least did) have a permgen leak |
| 14:19 |
|
Naros |
hm. that's interesting to know. |
| 14:20 |
|
sfisque |
that's was always the culprit when tomcat would permgen fault |
| 14:27 |
|
pdurbin |
sfisque: I wonder if it's been fixed. We could simply upgrade our commons.logging jar |
| 14:27 |
|
sfisque |
funny, reading that chat log you linked pdurbin. it's interesting that people don't realize that almost every servlet/ee container is descended from jserv/tomcat |
| 14:28 |
|
sfisque |
i didnt think gf 3+ used commons.logging? i havent traipsed accross it during my travels thorught he ogsi modules |
| 14:28 |
|
pdurbin |
maybe we add it. I'm not sure |
| 14:45 |
|
sfisque |
anyone know a way to introspect the permgen space to see what's actually in there and possibly orphaned (other than core dumping the jvm or using an os level debugger and surfing the raw memory) |
| 14:50 |
|
Naros |
hrm. i thought JProfiler allowed you to see that |
| 14:50 |
|
Naros |
Haven't fired it up lately, but I could have sworn it had memory & permgen inspection. |
| 14:51 |
|
sfisque |
dunno if the new ones do. i have an outdated copy (4.x) and it would tell you "gross" stuff about memory, but nothing fine grained on PG. maybe that's changed? |
| 14:51 |
|
|
kobain joined ##javaee |
| 14:53 |
|
Naros |
i am not 100% certain |
| 14:53 |
|
Naros |
jmap looks like an option. |
| 14:54 |
|
Naros |
http://stackoverflow.com/questions/4080010/how-to-dump-permgen |
| 15:27 |
|
* SoniEx2 |
hugs sfisque in an overly cute way ^-^ |
| 15:27 |
|
* sfisque |
hugs soniex2 in a totally inappropriate way :-P |
| 15:28 |
|
SoniEx2 |
you know... I'm 14... :P |
| 15:28 |
|
sfisque |
lmao, had no idea |
| 15:28 |
|
sfisque |
i guess that makes that a triple entendre then |
| 15:28 |
|
* sfisque |
blushes |
| 15:29 |
|
sfisque |
anywho, time for commuting. code strong! |
| 15:32 |
|
|
ibaca joined ##javaee |
| 16:34 |
|
|
sfisque joined ##javaee |
| 16:48 |
|
Naros |
lol @ sfisque |
| 16:53 |
|
sfisque |
lol delayed reaction :P |
| 16:54 |
|
Naros |
heh i was afk :P |
| 17:05 |
|
sfisque |
so back to the permgen question. does the newer (newest) version(s) of jprofiler allow introspection into the permgen space to find PG leaks? |
| 17:05 |
|
sfisque |
the version i have (4.x) only tracks PG monolithically |
| 17:06 |
|
sfisque |
and the same for the J6/J7 versions of jvisualvm |
| 17:08 |
|
Naros |
sfisque: i'm not 100% certain. my copy has expired too. |
| 17:09 |
|
Naros |
one of the SE posts I saw claimed it did |
| 17:09 |
|
Naros |
er rather SO (stackoverflow) |
| 17:09 |
|
sfisque |
i will have to investigate this. if so, i foresee a purchase order in my future :P |
| 17:10 |
|
whartung |
just wait for Java 8 :) |
| 17:10 |
|
whartung |
do you have perigean issues with production or just development? |
| 17:11 |
|
sfisque |
just dev because when we do a prod deployment, they generally have to drop the container at some point to update environment artifacts and such |
| 17:11 |
|
sfisque |
but i foresee PG being an issue if we start doing hot-deploys and other "fabric" stuff |
| 17:12 |
|
sfisque |
since GF will PGfail on my after about 5 redeploys (and i've bumped the PG up a little from the default settings) |
| 17:12 |
|
sfisque |
so i'd like to know the "fixable" PG leaks (our code) versus the ones we have to live with (bundled with GF) |
| 17:13 |
|
whartung |
yea I never really know if it's worth the time to bother to hunt those down rather than making the undeploy/restart gf/deploy process as painless as possible |
| 17:13 |
|
whartung |
I guess it depends if you have other things deployed in GF than your app |
| 17:14 |
|
whartung |
empty GF starts up pretty fast |
| 17:14 |
|
* pdurbin |
just restart netbeans (and therefore glassfish) disturbingly frequently :( |
| 17:16 |
|
sfisque |
aye. i'm more concerned with the footprint IF we start doing hot-deploys - there is talk that "they" want to move to an ESB model [i can only wish, currently i feel like i'm ready to take this enterprise to the next level but the knowledge base and sense of adventure are "thin" here] |
| 17:16 |
|
sfisque |
but then "they" are talking of scrapping EE and going to TC/Spring/myBatis (blech) |
| 17:17 |
|
* Naros |
giggles, spring :P. |
| 17:17 |
|
sfisque |
because, if you want to do ESB, using crippled tools is the way to go... right? |
| 17:17 |
|
sfisque |
why would you want a fully vetted stack when you can go through all the trouble of assembling your ESB from microscopic pieces |
| 17:18 |
|
whartung |
ya know I was looking at that a little a while back. |
| 17:18 |
|
whartung |
and it all depends on the complexity of your workflow |
| 17:19 |
|
whartung |
but you can do some nice stuff with just deploying (and redeploying) a bunch of stand alone MDBs linked via queues. Straight in the container, no "framework" needed. |
| 17:20 |
|
sfisque |
aye but does TC support MDBs (i know it doesnt do EE unless you leverage the TomEE stack)? |
| 17:20 |
|
Naros |
far as I know, TC7 doesn't support MDBs |
| 17:20 |
|
whartung |
oh, TC. missed that. |
| 17:20 |
|
|
SoniEx2|2 joined ##javaee |
| 17:20 |
|
whartung |
that's crazy |
| 17:20 |
|
sfisque |
and even then, i'm not familiar enough with Tee to know if it's TCK passed |
| 17:21 |
|
Naros |
You can use OpenEJB |
| 17:21 |
|
Naros |
to enhance TC with that functionality. |
| 17:21 |
|
whartung |
Tee is Tomcat with OpenEJB |
| 17:21 |
|
sfisque |
they want TC. the NOC has a boner for tomcat |
| 17:21 |
|
sfisque |
why |
| 17:21 |
|
sfisque |
i do not know |
| 17:22 |
|
whartung |
I'm a GF fanboi, and there are reasons for using TC over GF, but only for much simpler apps |
| 17:22 |
|
whartung |
reinventing the JEE stack with Tomcat via Spring or whatever, is, kinda nuts IMHO |
| 17:23 |
|
whartung |
actually I don't know how different the TC memory footprint is compared to GF that's just running a WAR. |
| 17:23 |
|
whartung |
with all the dynamic loading stuff GF does |
| 17:23 |
|
* sfisque |
aggrees with whartung |
| 17:23 |
|
whartung |
smaller disk footprint, sure (but who cares about disk…) |
| 17:24 |
|
whartung |
Mind, I have ported a JEE app to Jetty once :) |
| 17:24 |
|
whartung |
I wrote my own session bean implementation lol |
| 17:24 |
|
sfisque |
the issue is they want to start leveraging JMS more and wiring into legacy systems. IMO, that is enough to say, "umm... WTF are you thinking" but i'm "just a contractor" and "they" ... supposedly know what thy are doing.... |
| 17:25 |
|
whartung |
I like JMS, we use it a lot here. JMS is fine. GF JMS works well |
| 17:25 |
|
sfisque |
done that too. i built a "bean pool" using java commons pooling and apache digester for the xml bindings, when i wa previously handcuffed to tomcat |
| 17:25 |
|
sfisque |
but i'd rather use a vetted platform than start over and deal with "jar hell" |
| 17:25 |
|
whartung |
si |
| 17:27 |
|
whartung |
why do I want to have to bolt all that crap together |
| 17:27 |
|
whartung |
GF is drag and drop and has a great admin tool |
| 17:28 |
|
whartung |
NOC guys need to stop reading blogs... |
| 17:35 |
|
sfisque |
lolz |
| 17:35 |
|
sfisque |
PREACH ON, BROTHAH!!!! |
| 17:37 |
|
whartung |
I mean, that's the point earlier. With queues and MDBs, you can ad hoc as ESB on top of stock glass fish. You don't need to use an ear, just a jar file with the MDB in it. When you change ethe MDB, the queue stops (amazing!) the mdb reloads and then picks up processing. You can deploy raw EJBs (redeploy, and…) to add shared functionality. Yea, they're "remote" but GF will use local call semantics on "local" remote beans. No big dea |
| 17:37 |
|
whartung |
It's super flexible. |
| 17:38 |
|
whartung |
if you need to update an EJB that an MDB relies on, disable the MDB, redeploy the EJB, and reenable the MDB. |
| 17:38 |
|
whartung |
3 lines in a script |
| 17:38 |
|
whartung |
simple |
| 17:38 |
|
sfisque |
aye |
| 17:38 |
|
sfisque |
i know JBoss will optimize a @Remote into an @Local call on the fly. GF does that too? |
| 17:38 |
|
whartung |
yea it can do that |
| 17:39 |
|
sfisque |
nifty |
| 17:39 |
|
whartung |
You lose some first class concepts like joining and forking queues, but simple MDBs can be made to do that. if you really need it. |
| 17:40 |
|
whartung |
and you don't get the neat graph showing your ESB. |
| 17:40 |
|
whartung |
ooh |
| 17:40 |
|
whartung |
so, for a large ESB, yea, I can see needing a more formal ESB tool |
| 17:40 |
|
whartung |
but as I posted on SO once, someone asking about ESBs, I told him if you needed an ESB you'd KNOW you needed one. |
| 17:41 |
|
whartung |
since it's 90% a management task, and whatever you're doing now is getting out of hand. |
| 17:41 |
|
whartung |
but, hey, the MDB idiom will drag and drop in to modern ESBs with almost no work! so, EZ upgrade. |
| 17:42 |
|
whartung |
plus you get kick ass transaction handling that tomcat will all you to "hand craft" thankyouverymuch |
| 17:42 |
|
whartung |
*allow you |
| 17:42 |
|
sfisque |
aye. and i'm not a big fan of spring's TXing |
| 17:43 |
|
whartung |
yay, my time machine drive is spitting teeth again. |
| 17:44 |
|
whartung |
see if that continues... |
| 17:44 |
|
sfisque |
lolz |
| 17:45 |
|
sfisque |
i just started using TM. i upgraded my aging macbook to a 1tb drive and split it to 500g partitions. the secondary is the TM drive so i don't have to lug around an external |
| 17:46 |
|
sfisque |
i had to tune TM to a "less aggressive" profile so i could get work done |
| 17:46 |
|
whartung |
I love T M but for some reason, at least on these iMacs, it eats drives. Or maybe we just get crappy drives. |
| 17:46 |
|
whartung |
I think I've already reformatted this one once |
| 18:23 |
|
sfisque |
time to commute. cuiab. code strong! |
| 19:35 |
|
Naros |
early commute :o |
| 20:20 |
|
|
SoniEx2|2 joined ##javaee |
| 20:26 |
|
|
kobian joined ##javaee |
| 20:35 |
|
|
sfisque joined ##javaee |
| 20:38 |
|
|
sfisque1 joined ##javaee |
| 21:46 |
|
|
caverdude joined ##javaee |
| 21:52 |
|
caverdude |
hello |
| 21:52 |
|
SoniEx2 |
sfisque: ^-^ |
| 21:55 |
|
sfisque |
G R E E T I N G S |
| 21:55 |
|
caverdude |
have you guys seen the phigits controller? |
| 21:55 |
|
caverdude |
you can use Java among other langs to program it |
| 21:56 |
|
caverdude |
http://www.phigits.com i think |
| 22:00 |
|
sfisque |
www.phidgets.com |
| 22:02 |
|
Naros |
sfisque: I haven't been so giddy to refactor code like this in ages |
| 22:02 |
|
caverdude |
ya that one |
| 22:02 |
|
caverdude |
sorry |
| 22:03 |
|
sfisque |
:-) |
| 22:03 |
|
Naros |
Do you know whether there is any performance loss when using embeddable class components heavily in the domain? |
| 22:04 |
|
whartung |
huh? |
| 22:04 |
|
sfisque |
do you mean embedded PKs? |
| 22:04 |
|
Naros |
i don't see why there would be other than whatever meta-data has to be inspected during loading phase. |
| 22:04 |
|
whartung |
oh |
| 22:04 |
|
Naros |
no not PKs, actual parts of an entity |
| 22:04 |
|
Naros |
ie: reusable groups of columns across multiple entities |
| 22:04 |
|
whartung |
there will obviously be some cpu hit, but i doubt it's noticable |
| 22:05 |
|
whartung |
once everything is warmed up |
| 22:05 |
|
sfisque |
are you talking about "derived" entities that are results of tuple style queries? |
| 22:05 |
|
Naros |
No. |
| 22:05 |
|
sfisque |
then how would you have the same columns in different entities? |
| 22:06 |
|
Naros |
for example, I create an Embeddable class that contains say address fields. |
| 22:06 |
|
Naros |
I use that embeddable in a User, in a Vendor, and in a Manufacturer entity. |
| 22:06 |
|
sfisque |
as opposed to just doing a @Join? |
| 22:06 |
|
Naros |
As opposed to just hard-coding those fields as a part of all three entities. |
| 22:06 |
|
sfisque |
aka @OneToOne, etc. |
| 22:07 |
|
Naros |
all three have address_line_1, address_line_2, and city, state, zip fields in the table. |
| 22:07 |
|
sfisque |
i can see that as confusing the api. the entity should be a durable definition of a table |
| 22:07 |
|
sfisque |
if one table chagnes then you have to mutate unrelated entites |
| 22:07 |
|
Naros |
No, this would be where if one changes, all change. |
| 22:08 |
|
sfisque |
unless one has to change and the others do not |
| 22:08 |
|
sfisque |
business driver |
| 22:08 |
|
sfisque |
IMO an entity/table shoudl form an idempotent coupling |
| 22:08 |
|
sfisque |
i should not have to chagne them if some unrelated table/entity changes |
| 22:09 |
|
whartung |
but that's a risk he may be willing to take |
| 22:09 |
|
Naros |
A perfect example in my code base is on purchasing records such as pos, requisitions, contracts, and agreements. |
| 22:09 |
|
sfisque |
aye, but do not forget the ROI on maintenance. i forget who said it, but "when you write code, assume the future maintainer is a homocidal maniac who knows where you live" |
| 22:10 |
|
Naros |
Each document has a list of conditions at the header & line level of those documents. |
| 22:10 |
|
sfisque |
i understand the context. i do not agree with the mechanic |
| 22:10 |
|
Naros |
hm |
| 22:10 |
|
sfisque |
but that is personal taste |
| 22:10 |
|
whartung |
yes |
| 22:10 |
|
whartung |
personal taste |
| 22:10 |
|
whartung |
not germane to the question at hand :) |
| 22:10 |
|
sfisque |
you have to maintain it or answer to whomever will, so have at it |
| 22:11 |
|
sfisque |
as a fellow mathematician would quip, "just because you can, does not mean you should..." :P |
| 22:11 |
|
Naros |
Understood, just wanted to make sure that if I opted that route, would there be any consequences from performance for said decision. |
| 22:11 |
|
whartung |
that's what so great about computer game programming. Write it until it survives shipping then BU BYE! |
| 22:11 |
|
* sfisque |
giggles |
| 22:12 |
|
sfisque |
they wait that long? |
| 22:12 |
|
Naros |
Maintenance is an entirely different ballgame :P |
| 22:12 |
|
sfisque |
in enterprise, maintenance is everything (from the enterprise's standpoint) |
| 22:12 |
|
sfisque |
it takes too long to replace somethign |
| 22:12 |
|
sfisque |
to not address maintainence |
| 22:13 |
|
Naros |
touche |
| 22:13 |
|
whartung |
I'm neck deep in an EJB 2 project, trying to remember how to wire EJBs... |
| 22:14 |
|
* sfisque |
hands whartung several books on XML and XSLT, and a bottle of scotch |
| 22:14 |
|
whartung |
it's funny |
| 22:14 |
|
whartung |
someone once asked about advantaged of EJB 3 |
| 22:15 |
|
Naros |
sfisque: do you think using a parent abstract class to define commonality and then extending it per entity implementation is just as worse? |
| 22:15 |
|
whartung |
and one of the things I listed was "compatible with EJB 2" |
| 22:15 |
|
Naros |
rather than trying to approach it from a component breakdown approach. |
| 22:18 |
|
Naros |
anywho, laters. |
| 22:23 |
|
SoniEx2 |
sfisque: could you help me? |
| 22:24 |
|
sfisque |
that all depends... are we going to rob a bank? |
| 22:24 |
|
SoniEx2 |
no... and I don't get that... |
| 22:25 |
|
sfisque |
nm. what's up? i reserve saying yes/no until after i hear what IT is |
| 22:25 |
|
SoniEx2 |
I need better streams |
| 22:25 |
|
sfisque |
call the EPA? |
| 22:25 |
|
sfisque |
JK. how so? |
| 22:26 |
|
SoniEx2 |
this type of stream: https://github.com/SoniEx2/NBX-API/blob/master/src/com/github/soniex2/nbx/api/NBSOutputStream.java |
| 22:28 |
|
sfisque |
ok. better, how? what are you trying to achieve "better" |
| 22:31 |
|
SoniEx2 |
something that makes more sense than having NBSOutputStream extend ByteArrayOutputStream and NBSInputStream extend InputStream |
| 22:31 |
|
whartung |
why shouldn't they do that? |
| 22:31 |
|
|
caverdude joined ##javaee |
| 22:36 |
|
sfisque |
well, bear in mind that BAOS is a memory only stream. it does not persist (you have to decorate it with another stream). since you're R/W many "types" why not use a DataIn/OutputStream or ObjectIn/OutputStream |
| 22:37 |
|
sfisque |
and don't forget to decorate with BufferedI/OStream because if you do any file i/o you're going to pay in performance if you don't |
| 22:42 |
|
SoniEx2 |
Data<In/Out>putStream is big-endian |
| 22:42 |
|
SoniEx2 |
afaik |
| 22:43 |
|
sfisque |
gotcha |
| 22:49 |
|
SoniEx2 |
I could override the methods but that's... yeah... |
| 22:55 |
|
sfisque |
well you already are. it looks like you have several of the same signature methods |
| 22:55 |
|
SoniEx2 |
I have protected instead of public... |
| 22:56 |
|
sfisque |
why? |
| 22:57 |
|
sfisque |
the IO package is a decorator paradigm, every class is usable or decoratable (except the abstract / interfaces) |
| 22:58 |
|
SoniEx2 |
because I'm stupid like that... |
| 22:58 |
|
sfisque |
nah, just learning :-) |
| 22:58 |
|
sfisque |
i wasnt sure if that was deliberate or taste |
| 23:01 |
|
SoniEx2 |
eh everything in Data<In/Out>putStream is final |
| 23:01 |
|
SoniEx2 |
:/ |
| 23:02 |
|
sfisque |
ah, that makes sense, since it's tied to the endian-ness |
| 23:02 |
|
sfisque |
hadn't considered that |
| 23:06 |
|
sfisque |
one thing to keep in mind, if you want your stream class to be decoratable, you want to override the other constructors that BAOS exposes, and call them in your constructor so the BAOS internals are setup properly if you're decorating |
| 23:07 |
|
sfisque |
or being decorated |
| 23:10 |
|
SoniEx2 |
I'll simply use Filter<In/Out>putStream and Data<In/Out>put |
| 23:18 |
|
sfisque |
there ya go |
| 23:20 |
|
|
SoniEx2|2 joined ##javaee |
| 23:38 |
|
|
oO0Oo joined ##javaee |
| 23:58 |
|
SoniEx2 |
this is NOT how you make methods: http://imgur.com/dX7BWIs |
