Time |
S |
Nick |
Message |
00:17 |
|
|
knoppix joined ##javaee |
00:32 |
|
sfisque |
OMFG. reading the prettyfaces docs. too awesome... |
00:38 |
|
whartung |
prettyfaces? |
00:39 |
|
whartung |
so rather than doing a JCA for mail delivery, Ill just queue it up to a JMS queue and write a simple MDB to service that. That's 99.99% transactional, with a race condition between the close to the SMTP socket and the commit of the MDB method. |
00:40 |
|
whartung |
at worst we gets double message, but that's always a risk with async queueing anyway |
00:40 |
|
sfisque |
javaeebot lucky pretty faces jsf rewrite |
00:40 |
|
javaeebot |
sfisque: http://ocpsoft.org/prettyfaces/ |
00:41 |
|
whartung |
oh nice |
00:42 |
|
sfisque |
i'm surprised no one has written an XA mail handler. you'd think something like that would have been done years ago |
00:42 |
|
whartung |
so sfisque would you greenfield a JSF project today, or go pure ajaxy/RESTy |
00:42 |
|
whartung |
nobody thinks mail is important :) |
00:42 |
|
sfisque |
former. i prefer server side production of the representation because you cannot assume the client side |
00:43 |
|
whartung |
assume what? |
00:43 |
|
sfisque |
processing strength, browser compatibility, ram, screen real estate, etc. |
00:43 |
|
sfisque |
i like ajax for UX responsiveness not view construction |
00:44 |
|
sfisque |
doing full ajax/rest is like mailing the parts of a TV to a person and telling them to watch tv. |
00:44 |
|
sfisque |
you dont do that, you go out and buy a full tv fully assembled |
00:45 |
|
whartung |
what if you were guaranteed a specific browser (FF, IE, Chrome) |
00:45 |
|
sfisque |
i know that concept is "outdated" but it's how i feel about web app design |
00:45 |
|
sfisque |
i'd call the BA who gives you that constraint a liar :P |
00:46 |
|
whartung |
That funny, our company is mandating a browser for it's new app to the clients. |
00:46 |
|
sfisque |
if they're willing to "fix" the browser, you might as well remove the browser from the picture and do webstart or a RIA |
00:46 |
|
whartung |
I mean, at that point, you should just use one of the "browser as app" packaging techniques that Chrome and FF have. |
00:47 |
|
sfisque |
that would also be an option at that point |
00:47 |
|
whartung |
because that's what the browser is becoming, the PowerBuilder of our age. |
00:47 |
|
whartung |
only "kind portable" |
00:47 |
|
whartung |
*kinda |
00:48 |
|
whartung |
Or I should say "The PowerBuilder of our age, only harder to use" :) |
00:48 |
|
sfisque |
lolz |
00:48 |
|
whartung |
and you talk HTTP and JSON instead of SQL and Stored Procedures |
00:48 |
|
whartung |
same ol client server |
00:48 |
|
sfisque |
and xml |
00:49 |
|
whartung |
*sigh* I miss Informix 4GL … I'm such a fuddy duddy |
00:49 |
|
sfisque |
dude i hear you. i look at web tech these days, and i wonder…. we went from hypercard… to this? |
00:49 |
|
whartung |
I saw a "productivity" graph once, and it plummeted when web apps became popular lol |
00:50 |
|
sfisque |
rofl |
00:50 |
|
whartung |
just bounced off the cieling |
00:50 |
|
whartung |
be nice to not need a MA in UX to do a dialog box |
00:51 |
|
sfisque |
more like MS… all the voodoo css and javascript :P |
00:52 |
|
whartung |
yea |
00:53 |
|
sfisque |
krikey , below freezing until monday… /sigh |
00:53 |
|
sfisque |
i love you noaa.gov, but man… F U |
00:53 |
|
whartung |
where? |
00:53 |
|
sfisque |
pdx |
00:54 |
|
whartung |
is that an airport code? |
00:54 |
|
sfisque |
a cold day here is like 37' normally. an average day is like 43 in dead of winter |
00:54 |
|
sfisque |
yes portland or |
00:54 |
|
whartung |
ah ok |
00:54 |
|
whartung |
yea we have a guy who works up there, was just chatting with im |
00:54 |
|
whartung |
weather didn't come up |
00:55 |
|
sfisque |
it's is unnaturally cold right now here |
00:55 |
|
sfisque |
like supernatural horror cold |
00:55 |
|
whartung |
supposed to bounce off of 40 over night down here |
00:55 |
|
whartung |
no, that's chicago |
00:55 |
|
sfisque |
:P |
00:55 |
|
whartung |
8 degress |
00:55 |
|
whartung |
brrfuck |
00:56 |
|
sfisque |
yah, i had a friend who went to NW U. he said it was actually "too cold for snow" |
00:56 |
|
whartung |
yea |
00:56 |
|
whartung |
"what..how..but..." |
00:56 |
|
sfisque |
yah. that's what my response was like |
00:57 |
|
sfisque |
add in a look of incredulity and you have the picture |
00:57 |
|
whartung |
heh |
01:02 |
|
sfisque |
well time for me to pack up and commute. c'y'all later. code strong! |
02:50 |
|
|
jenue joined ##javaee |
03:56 |
|
|
kobain_ joined ##javaee |
04:06 |
|
|
sess joined ##javaee |
04:17 |
|
|
sfisque joined ##javaee |
04:25 |
|
|
sfisque1 joined ##javaee |
05:29 |
|
|
Losowski joined ##javaee |
05:44 |
|
|
Losowski left ##javaee |
06:10 |
|
|
snowyrooftops joined ##javaee |
06:12 |
|
snowyrooftops |
Hi! |
06:12 |
|
snowyrooftops |
I'm looking for help with getting an Axis2 web service running |
06:13 |
|
snowyrooftops |
I tried getting it to run from within Eclipse, but no luck there - it couldn't find the AxisServlet (NoClassDefFoundError) |
06:14 |
|
|
jenue joined ##javaee |
06:47 |
|
|
jenue joined ##javaee |
06:58 |
|
keruspe |
Did some of you already used some jersey2 stuff? |
06:59 |
|
keruspe |
If I try to get the data I get from a form with @FormParam it works, but if I want all of them in a Map directly, the map is empty. |
07:00 |
|
keruspe |
the doc says it's possible though https://jersey.java.net/documentation/latest/jaxrs-resources.html example 3.13 |
07:05 |
|
|
AlexCzar joined ##javaee |
07:51 |
|
|
AlexCzar joined ##javaee |
07:56 |
|
|
pleroma joined ##javaee |
08:28 |
|
|
jenue2 joined ##javaee |
08:30 |
|
|
pleroma_ joined ##javaee |
09:50 |
|
|
neuro_sys joined ##javaee |
09:55 |
|
|
neilus joined ##javaee |
09:57 |
|
|
helga joined ##javaee |
10:02 |
|
|
SLovenberg joined ##javaee |
10:09 |
|
|
neilus joined ##javaee |
10:58 |
|
|
neuro_sys joined ##javaee |
11:10 |
|
|
drspockbr joined ##javaee |
11:34 |
|
|
acuzio left ##javaee |
11:34 |
|
|
acuzio joined ##javaee |
13:15 |
|
pdurbin |
keruspe: I'm using Jersey 2 in Glassfish 4. I haven't tried the form param thing though |
13:18 |
|
* pdurbin |
looks at JAX-RS @FormParam example - http://www.mkyong.com/webservices/jax-rs/jax-rs-formparam-example/ |
13:18 |
|
pdurbin |
<form action="rest/user/add" method="post"> |
13:18 |
|
pdurbin |
interesting |
14:27 |
|
keruspe |
pdurbin: getting the args with @FormParam works |
14:27 |
|
keruspe |
Getting the whole stuff in a MultivaluedMap<String,String> or in a Form doesn't, when supposed to |
14:29 |
|
pdurbin |
hmm |
14:29 |
|
acuzio |
JAX-RS is possibly one of the best parts of the _new_ Java |
14:30 |
|
pdurbin |
I'm loving it in Jave EE 7 |
14:30 |
|
|
sheenobu joined ##javaee |
14:31 |
|
|
sheenobu joined ##javaee |
14:37 |
|
|
Naros joined ##javaee |
14:45 |
|
|
kobain joined ##javaee |
14:47 |
|
acuzio |
hey Naros |
14:52 |
|
Naros |
Morning |
15:07 |
|
|
knoppix joined ##javaee |
16:09 |
|
|
AlexCzar joined ##javaee |
16:53 |
|
|
rektide joined ##javaee |
16:58 |
|
|
Centauri left ##javaee |
18:10 |
|
|
knoppix_ joined ##javaee |
18:55 |
|
pdurbin |
Twitter / philipdurbin: @jsfcentral it looks like this ... - https://twitter.com/philipdurbin/status/408935022893486080 |
19:10 |
|
Naros |
anyone ever created a mappedsuperclass that has an abstract method that the subclassed entity implements? |
19:11 |
|
Naros |
i'm pondering how to annotate such a scenario to avoid getting "Duplicate property mapping" |
19:11 |
|
sfisque1 |
is this that thing you were wrestling with a few weeks ago? |
19:11 |
|
Naros |
Yah got the code to a deployable state but it doesn't startup |
19:11 |
|
Naros |
I have AbstractAttachment<Owner> |
19:12 |
|
Naros |
which has public abstract Owner getOwner() and public abstract void setOwner(Owner owner); |
19:12 |
|
Naros |
annotations are on the subclass |
19:16 |
|
Naros |
Maybe @ManyToOne needs to be on the parent class and using AssociationOverride on derived, let me try that |
19:20 |
|
semiosis |
Naros: i think i have, let me check |
19:21 |
|
Naros |
no longer get the duplicate property error but now the index validation fails cause it cannot locate the field :E |
19:21 |
|
Naros |
placed @ManyToOne on the owner abstract getter and then used |
19:21 |
|
Naros |
@AssociationOverride(name="owner",joinColumns=@JoinColumn(name="REQUEST_ID",....)) |
19:22 |
|
Naros |
but the @Index annotation fails to validate cause it claims no column is defined as REQUEST_ID |
19:22 |
|
semiosis |
Naros: i have @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) on the abstract parent class |
19:23 |
|
semiosis |
otherwise nothing special afaict |
19:26 |
|
Naros |
I am not sure that is necessary tho |
19:28 |
|
Naros |
semiosis: question is in your case, do you have an @Index annotation for one of those abstract fields? |
19:31 |
|
Naros |
I am wondering if I need to take those two abstract methods and make them part of an interface instead. |
19:35 |
|
Naros |
That seemed to work. public abstract class AbstractAttachment<Owner> implements OwnedEntity<Owner>, Serializable |
19:36 |
|
Naros |
SpecialAttachment extends AbstractAttachment<SpecialOwner> |
19:43 |
|
|
drspockbr joined ##javaee |
20:13 |
|
pdurbin |
"in ElasticSearch you can have multiple Types of documents in a single Index. This means that you can index documents of different index structure (for example users and their documents) in a single Index. ElasticSearch is able to distinguish those Types during indexing as well as querying. In order to achieve the same with Solr you would have to simulate that inside your application or develop a custom |
20:13 |
|
pdurbin |
search component." -- http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ |
20:14 |
|
pdurbin |
I have a question about this... the idea of indexing users vs. their documents |
20:15 |
|
|
knoppix__ joined ##javaee |
20:15 |
|
pdurbin |
but unfortuantely, the term "documents" is a bit overloaded in the world of Solr and Lucene... |
20:16 |
|
pdurbin |
so I'll use GitHub examples instead... repos vs. code vs. issues vs. users |
20:17 |
|
pdurbin |
let's say I want to be able to index all of these |
20:17 |
|
pdurbin |
and be able to search all of them |
20:17 |
|
pdurbin |
search for a repo, search for users, etc. |
20:17 |
|
pdurbin |
right now I only have one type |
20:18 |
|
pdurbin |
let's say that type is "users" |
20:18 |
|
pdurbin |
I'm indexing the users into "collection1": http://localhost:8983/solr/#/collection1 |
20:19 |
|
pdurbin |
but now I want to index repos... |
20:19 |
|
pdurbin |
do repos go in collection2? |
20:19 |
|
pdurbin |
and issues would go into collection3? |
20:21 |
|
pdurbin |
I ask because the id 1 in collection1 is a user, which maps to id 1 in the user table of my database. (row 1) |
20:22 |
|
|
tmichel joined ##javaee |
20:22 |
|
|
tmichel left ##javaee |
20:23 |
|
pdurbin |
so at index time I don't want to overwrite id 1 in collection1 with a different type, such as a repo or code or an issue |
20:25 |
|
pdurbin |
is this making sense? |
20:32 |
|
pdurbin |
to talk about from the search side, GitHub lets you search differnt types: |
20:33 |
|
pdurbin |
- https://github.com/search?q=foo&type=Repositories |
20:33 |
|
pdurbin |
- https://github.com/search?q=foo&type=Code |
20:33 |
|
pdurbin |
- https://github.com/search?q=foo&type=Users |
20:33 |
|
pdurbin |
and this is basically what I want to do |
20:34 |
|
pdurbin |
but do I use collection1, collection2, collection3 in Solr to support this? |
20:36 |
|
|
sheenobu joined ##javaee |
20:49 |
|
Naros |
pdurbin: I know from a Lucene point of view with Hibernate, all three of those "entities" would be indexed in their entity-specific index. |
20:50 |
|
pdurbin |
Naros: ah, so three indexes... repos, code, users |
20:50 |
|
Naros |
Using the JoinUtil API, you can then join multiple indices together to get one index based on parameters that found matches against another index. |
20:50 |
|
pdurbin |
indices* :) |
20:51 |
|
Naros |
In fact, our inventory material search does precisely that. You can find an Item based on item attributes, text keywords or stem fragments, or based on part number relationships which are all three stored in their own respective index but joined together using runtime joins. |
20:52 |
|
Naros |
I would suspect that Elastic Search offers similar things |
20:53 |
|
pdurbin |
Naros: that blog post says "ElasticSearch is able to distinguish those Types during indexing as well as querying" |
20:53 |
|
pdurbin |
must be magic :) |
20:54 |
|
Naros |
it probably does something similar to hibernate search where each entity document has a _hibernate_class attribute associated to it and it's basically the fully qualified class name. |
20:55 |
|
pdurbin |
hmm. I've never used hibernate but that makes sense |
20:55 |
|
Naros |
We dont maintain such attribute but the engine itself does it for you. |
20:55 |
|
pdurbin |
Naros: any thoughts on this? http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2013-12-06#l248 |
20:55 |
|
Naros |
nod, under the hood the hibernate search in our case is basically lucene & solr. |
20:55 |
|
Naros |
the hibernate search piece just maps annotations to lucene apis |
20:55 |
|
pdurbin |
"pdurbin: if the schemas for each type have some overlap, it can make sense to combine them into one core. It really all depends on how complex you think the queries might get and how much application-side complexity vs. solr-side complexity you want to manage." -- from #lucene-dev |
20:56 |
|
pdurbin |
"it's usually a good idea to include a field for differentiating the types, "type" is a good name for that. :)" |
20:57 |
|
Naros |
Right, makes sense. For example .. |
20:57 |
|
Naros |
We have two entities ManufacturerPartNumber and VendorPartNumber. While they are two different entities in a POJO point of view, we actually combine them into a single index using a type field to differential them. |
20:58 |
|
Naros |
It significantly simplifies the queries because joins aren't necessary. |
20:59 |
|
pdurbin |
Naros: and they probably have similar schemas, the 2 part numbers |
20:59 |
|
Naros |
Technically even at the DB level, they have the same fields but were kept separate to make FK relationships easier to manage. |
20:59 |
|
Naros |
Yep, precisely. |
21:00 |
|
pdurbin |
Naros: ok, but say you wanted to index something radically different... such a users. Then what? |
21:00 |
|
pdurbin |
as* |
21:01 |
|
Naros |
In that case its in its own index or w/e elastic searches equivalent term is, collection or w/e. |
21:02 |
|
Naros |
so I think you're spot on having repos, users, and code be 3 cores/collections |
21:02 |
|
pdurbin |
because the schemas are so different... |
21:02 |
|
Naros |
yep |
21:02 |
|
semiosis |
Naros: no @index anywhere in my code |
21:03 |
|
pdurbin |
semiosis: are you talking about Solr/search? |
21:03 |
|
Naros |
nah semiosis is talking about my earlier conundrum. |
21:03 |
|
pdurbin |
semiosis: sssh! |
21:03 |
|
pdurbin |
:) |
21:03 |
|
semiosis |
pdurbin: no, is Naros? |
21:03 |
|
semiosis |
i thought we were talking about jpa |
21:03 |
|
Naros |
so code has a user_id, repo has a user_id and user has a user_id |
21:03 |
|
pdurbin |
semiosis: we're talking about Solr. Help! :) |
21:04 |
|
Naros |
if i want to find all code a user has I could then just query code out-right ofc ;P |
21:04 |
|
Naros |
i modeled the indices much like a typical DB table except that SOLR knows how to handle text queries, wildcard queries, etc far more efficiently ofc. |
21:05 |
|
* Naros |
hates LIKE '%kit%' across millions of rows :(. |
21:05 |
|
pdurbin |
Naros: really I'm indexing dataveres, datasets, files, and users. I just don't feel like explaining what a dataverse is :) |
21:05 |
|
pdurbin |
dataverses* |
21:05 |
|
Naros |
no worries. |
21:06 |
|
semiosis |
pdurbin: a dataverse is one line in a datasong |
21:06 |
|
semiosis |
we've been over this |
21:06 |
|
Naros |
I think whatever you're indexing, the same approach probably holds true. |
21:06 |
|
pdurbin |
http://en.wikipedia.org/wiki/Dataverse :) |
21:06 |
|
semiosis |
well that article is clearly wrong. don't worry i'll fix it |
21:07 |
|
pdurbin |
lol |
21:07 |
|
Naros |
What I found tho was where you can minimize the joins between indices, you'll be far better off even if it comes at the expense of a larger index. |
21:08 |
|
pdurbin |
Naros: you're talking about Lucene indexes? |
21:08 |
|
Naros |
Yah, because joining two indices based on some conditions means that it first must run the first query against index 1, get those results and then join those results to the query against index 2 and give you the conjunction. |
21:10 |
|
pdurbin |
right. ok. I'm not sure yet if I'll need to do similar joins |
21:11 |
|
Naros |
aye, will depend on what functionality you're trying to achieve. |
21:13 |
|
pdurbin |
Naros: so if you get an id back from your query... you use that id to look up an entity? a one to one mapping between the Solr document id and the id of a ManufacturerPartNumber or whatever? |
21:14 |
|
Naros |
Yah, its my understanding that h-search gets the entity's pk fields from the solr document and then uses that to fetch the entity from the EM. |
21:14 |
|
Naros |
Albeit on SQL Server, that isn't quite efficient when your solr query returns approximately more than 64 hits. |
21:14 |
|
pdurbin |
Naros: ok, I'm doing something similar: dataverse = dataverseService.find(searchResult.getId()) |
21:15 |
|
Naros |
I should say when the solr's result set to actually fetch is larger than 64 hits. The SOLR query can hit millions of rows easily, just the fetch is poorly handled. |
21:16 |
|
Naros |
but that's hibernate-specific :P |
21:18 |
|
pdurbin |
ok :) |
21:29 |
|
|
knoppix_ joined ##javaee |
21:47 |
|
pdurbin |
Naros: thanks |
22:22 |
|
|
[[thufir]] joined ##javaee |
22:33 |
|
|
neuro_sys joined ##javaee |