Re: [jug-discussion] Spam
I didn't get it either, and I don't use Gmail or other filtering. Christopher, spam email headers are *always* forged, because spamming is illegal in many areas. If you have a public email that's posted on the web, your email address is probably being used for spam. I know mine is - about every month or so I get a deluge of bounces from email servers all around the world with a variety of different spam emails being rejected and the rejection messages coming back to me. I've set up mail filters to eliminate most of them. So don't take the supposed from address on an email seriously. - Dennis Chad Woolley wrote: On Fri, Nov 21, 2008 at 10:04 AM, Christopher Sharp [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I opened what I thought was a message from this group, and found instead spam on Viagra and other similar products. It was in the form of an image. I didn't get it. Do you use Gmail? If not, consider it... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Web Oriented Architecture WOA
Hi Randy, There's a lot of confusion over terminology in this area. REST is a particular approach to working with distributed resources, and most of what's being done under the name of REST doesn't actually match the rules. What's really becoming popular is POX - Plain Old XML, exchanged using any convenient protocol (HTTP, TCP, SMTP, etc.). POX approaches offer much of the flexibility of SOAP Web services without requiring complex frameworks to implement. WOA seems an inappropriate restriction to HTTP, so I don't really see this as a big innovation. - Dennis BTW, I'm going to be passing through Tucson tomorrow afternoon and again on Monday afternoon. If anyone has some needs in the Web services realm I'd be glad to stop by and discuss. Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 Randolph Kahle wrote: Anyone following the discussion about WOA? Here is a link to a discussion about it: http://hinchcliffe.org/archive/2006/09/10/9275.aspx Regards, Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Organization Hosting Solution
G'day, mates. I'd definitely recommend Rimu. I've been with them for the last 2-3 years, after initially trying a couple of other Java hosting outfits. Rimu gives you a full virtual system, and you can install whatever packages you want on that system (as well as configure iptables, etc., however you want). I just use Tomcat on mine, with iptables port forwarding so that incoming requests on port 80 get redirected to 8080. That way I can run Tomcat non-root. Besides the flexibility, Rimu also has a great set of how-tos for everything from Tomcat and MySQL through email setup. - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Wellington, NZ +64-4-298-6117 Seattle, WA +1-425-296-6194 Warner Onstine wrote: On Jan 30, 2006, at 10:38 PM, Tim Colson ((tcolson)) wrote: Cool, thanks for checking into that, Chad! I'm +1 for rimuhosting...assuming we can get enough dues collected to cover at least 12 months, preferably 24 months. Until we are a non-profit organization with a bank account... somebody will have to personally handle the hosting/payment, eh? I think we should figure out a bit more of the organization and business stuff before we get the hosting solution and dues going Thoughts? I agree. Also, one thing that wasn't mentioned in the email (and I can't find on their site) is email accounts and mailing list management. With our current solution it is very easy to add new addresses as well as manage the mailing list (which is also something that I do on a regular basis that I would gladly hand over to someone). -warner -Tim -Original Message- From: Chad Woolley [mailto:[EMAIL PROTECTED] Sent: Monday, January 30, 2006 10:08 PM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] scripting language shootout RimuHosting got back to me. They will waive the setup fee and give us a 10% discount, which works out to $18/month for a linux VPS with full root access and choice of distro, 96MB ram and 4 gig of disk: http://rimuhosting.com/order/startorder.jsp These guys have great support too, they are very helpful plus have a bliki with lots of specific HOWTOs on setting stuff up: http://bliki.rimuhosting.com/space/start If anyone knows of a better deal that gives full root access, pipe up. Lets get this moving... P.S. As for hosting it on SourceForge as was suggested, I'd personally rather have it hosted on something we have control over - with a wiki, and with subversion, and anything else we think up. On 1/30/06, Tim Colson (tcolson) [EMAIL PROTECTED] wrote: It's been the time and coordination that has been difficult. Ex. Hardware. Stable OS. Access to the box. Setup of Java SDK. Setup of - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] MSoft + Jboss?
I agree that JBoss is evolving in some strange ways. Having taken over a large developer mindshare in the J2EE market I think they're trying to figure out where to go from here - J2EE looks to me to be on the downswing, with lighter weight technologies increasingly used as alternatives. Meanwhile, JBoss is getting more competition in the free/open source J2EE app server market. It is telling that they say most developers are using JBoss on Windows; that's a low-end system market, certainly not what I'd expect to see in even medium sized companies. I haven't noticed any problems installing it on Linux, though - untgz, go to bin, and run the script. What kind of problems have you seen? The only way this arrangement with MS makes sense as a technical development (rather than a marketing one) is if JBoss intends to go more into non-J2EE or J2EE++ technologies. Perhaps they're planning to add features beyond standard JAX-RPC/JAX-WS support in their replacement for Axis (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWS), and want to work toward Microsoft compatibility. I think that's probably a bad approach, if they're building on top of the standard - JAX-RPC is a horrible mess, and I don't really think JAX-WS is much better (annotation overload). Axis1 became a mess in large part because it was built around JAX-RPC; Axis2 is taking the cleaner approach of building their own core with the intent to support JAX-RPC/JAX-WS as a wrapper. - Dennis josh zeidner wrote: well, C was meant to be a solution to UNIX platform compatibility. We all know how that went. Jboss has been evolving into a strange beast in the last year. They are almost their own platform apart from J2EE. Certainly the odd man out of the J2ee world. Try installing it on linux... -josh --- Todd Ellermann [EMAIL PROTECTED] wrote: This occured for me like the un-announcement Uhhh Doesn't JBoss run on Java? Doesn't Java Run Anywhere? -Todd Todd R. Ellermann President PHXJUG.org [EMAIL PROTECTED] 602-738-6187 __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] IBM DeveloperWorks Headline Article on AOP Tools
Hey, I don't count? http://www-106.ibm.com/developerworks/java/library/j-cwt02095/ Actually mine just went up today. It didn't get the lead position because somebody else is being featured, Nick. :-P Looks like there's going to be a lot of AOP on devWorks this year - the next three installments of my new column are covering AspectWerkz. I should probably run them by you in advance to make sure I'm not embarrassing myself with AOP terminology misuse. Email me off-list if you're willing to give them a quick read. - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Redmond, WA 425.885.7197 Nicholas Lesiecki wrote: Ok, so I didn't write the article, but it's neat to see two JUGers on developerWorks! (Rick on JSF, Nick's series on AOP) (see the announcement below:) Long live Tucson! Nicholas Lesiecki Software Craftsman, specializing in J2EE, Agile Methods, and aspect-oriented programming m: 520 591-1849 Books: * Mastering AspectJ: http://tinyurl.com/66vf * Java Tools for Extreme Programming: http://tinyurl.com/66vt Articles on AspectJ: * http://tinyurl.com/66vu and http://tinyurl.com/66vv Begin forwarded message: *From: *Nicholas Lesiecki [EMAIL PROTECTED] *Date: *February 8, 2005 3:12:44 PM MST *To: [EMAIL PROTECTED] *Cc: [EMAIL PROTECTED] *Subject: [aspectj-users] IBM DeveloperWorks Headline Article on AOP Tools Reply-To: [EMAIL PROTECTED] IBM's developerWorks has just launched a new article series entitled [EMAIL PROTECTED] The [EMAIL PROTECTED] series is intended for developers who have some background in aspect-oriented programming and want to expand or deepen what they know. Each of the authors contributing to the series has been selected for his leadership or expertise in aspect-oriented programming. Many of the authors are contributors to the projects or tools covered in the series. Each article is subjected to a peer review to ensure the fairness and accuracy of the views expressed. The series will cover a range of topics, from testing aspect-oriented programs to the intersection of AOP and metadata. Articles are planned once a month through early 2006. The presence of another article series in a mainstream publication is great news for the AOP community, as it signals further industrial acceptance of the technology as well as the growth in the ranks of industrial practitioners. The first article in that series, AOP tools Comparison is currently headlining the developerWorks website. In the article aspect-oriented programming expert Mik Kersten compares the four leading AOP tools (AspectJ, AspectWerkz, JBoss AOP, and Spring AOP) to help readers evaluate the right tool for the project. As series lead, I welcome commentary from the AOP community regarding individual articles and the series as a whole. --Nicholas Lesiecki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Next week's meeting
Warner Onstine wrote: On Sep 8, 2004, at 4:05 PM, Tim Colson wrote: So, for the meeting next week, Warner has asked me to present on Tapestry. Excellent! I was wondering if that was still on tap... I'll add your name to the website link so you can't back out. :-) Anybody up for doing a mini-preso on something? Dennis is doing one. (I forget off the top of my head). -warner SWT is what we talked about. I've got a simple app to demonstrate, and can show the basic Eclipse tools for working with SWT as well. If I have the chance perhaps I'll try doing an equivalent demo with Swing, just to contrast. - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Eclipse question
[EMAIL PROTECTED] wrote: I think you are thinking of Simon -- he's the man that knows about writing Plugins and using SWT. Unfortunately he is off to New Zealand for a couple weeks, so it looks like you get to read that big PDF. Hi Vincent, Not sure if we've met or not - I'm up in Seattle, but get down to Tucson periodically. I'll be there for this month's meeting for a short presentation on SWT. Two things caught my attention in your reply: I'm interested in what people are doing with SWT/Plugins, and also in moving to New Zealand. It's unclear from your reply if Simon is with your company or you just know him, but if it's the same company can you tell me anything about the work you're doing with SWT/Plugins, and also if you have business contacts with New Zealand? Thanks for any info, - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Eclipse question
Dennis Sosnoski wrote: Hi Vincent, Not sure if we've met or not - I'm up in Seattle, but get down to Tucson periodically. I'll be there for this month's meeting for a short presentation on SWT. ... Shucks, caught by the reply-to. I meant to send direct to Vincent... Tim, for the plugin help a lot depends on what you want to do in your plugin. There are some related articles linked from the Eclipse site, including one on the PDE (Plugin Development Environment): http://www.eclipse.org/articles/Article-PDE-does-plugins/PDE-intro.html The actual PDE documentation included with Eclipse covers the basics (Help/Help Contents/Platform Plug-in Developers Guide and PDE Guide), and with the wizards provided it's easy to create basic plugins of several flavors. I've found the learning curve gets very steep once you're past the basics, though, especially if you're picky about how you want things to work. On the book topic, I've got the Eclipse: Building Commercial-Quality Plug-ins one. It looks pretty good to me, though I haven't dived into the in-depth plugin development parts yet. - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] UI stuff
That's interesting to see, they're taking an approach similar to
something I've been planning. People have been trying for several years
now to come up with XML GUI designs for Java, along the lines of
Mozilla's XUL. I think that kind of approach is overkill for Java,
though, and that rather than trying to put the whole GUI description
(including actions and such) into an XML configuration, you'd be much
better off to just put the layout information there. The layouts are
about 90% of the pain in doing cross-platform GUIs anyway, at least in
my experience. It looks like Intellij is going further than I'd take it,
but that's typical of these visual layout tools. At least it's cleaner
than generating the GridBag garbage in code with // {@ AUTOGENERATED
CODE - DO NOT MODIFY tags around it.
My idea is to just do the layouts in an XML configuration, and do it
that way as a convenience to programmers who basically want to control
things themselves rather than using a DD-type tool (so you still create
your active controls, only the passive containers and layouts go into
the XML; that way you can easily tweak the layouts without recompiling,
or even support multiple layouts depending on how something is being
used). Maybe I'll have an example for SWT by September.
- Dennis
Tim Colson wrote:
How do they actually handle the layouts, if they're not
generating code?
Voodoo. :)
It's a black box... I visually created a .form in XY space (creates an XML
file but do not edit the file), then you slap a grid on the components,
bind the form to a class, add bindings for each component, create a Jframe
and add the Form contentPane, and then during compile, et voila -- magic
fairies create the UI bits.
Some kind of configuration file that gets interpreted at runtime?
I recall seeing at JavaOne2003 a demo... and I thought they were doing some
bytecode manipulation post-compile. But honestly, I'm ignorant of what is
happening under the covers.
Heres an example of a simple form, one label, one text field, one button,
some spacers, seems like they have a Grid layout, perhaps custom:
?xml version=1.0 encoding=UTF-8?
form xmlns=http://www.intellij.com/uidesigner/form/; version=1
bind-to-class=com.cisco.hrit.Preferences
grid id=29ae7 row-count=3 column-count=3
same-size-horizontally=false same-size-vertically=false hgap=-1
vgap=-1
margin top=0 left=0 bottom=0 right=0/
constraints
xy x=35 y=40 width=354 height=90/
grid row=0 column=0 row-span=1 col-span=1 vsize-policy=3
hsize-policy=3 anchor=0 fill=3/
/constraints
properties/
border type=none/
children
component id=65ed1 class=javax.swing.JTextField
binding=nametext
constraints
xy x=62 y=0 width=186 height=21/
grid row=0 column=1 row-span=1 col-span=1
vsize-policy=0 hsize-policy=6 anchor=8 fill=1
preferred-size width=150 height=-1/
/grid
/constraints
properties/
/component
component id=a0d38 class=javax.swing.JButton binding=Apply
constraints
xy x=258 y=66 width=96 height=24/
grid row=2 column=2 row-span=1 col-span=1
vsize-policy=0 hsize-policy=3 anchor=0 fill=1/
/constraints
properties
text value=Apply/
/properties
/component
component id=2e73 class=javax.swing.JLabel
constraints
xy x=0 y=3 width=52 height=14/
grid row=0 column=0 row-span=1 col-span=1
vsize-policy=0 hsize-policy=0 anchor=8 fill=0/
/constraints
properties
text value=Item Name/
/properties
/component
hspacer id=64a7c
constraints
xy x=258 y=5 width=96 height=11/
grid row=0 column=2 row-span=1 col-span=1
vsize-policy=1 hsize-policy=6 anchor=0 fill=1/
/constraints
/hspacer
vspacer id=535de
constraints
xy x=300 y=26 width=11 height=40/
grid row=1 column=2 row-span=1 col-span=1
vsize-policy=6 hsize-policy=1 anchor=0 fill=2/
/constraints
/vspacer
/children
/grid
/form
Cheers,
Timo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA 425.885.7197
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] UI stuff
Interesting stuff - that's very similar to what I had in mind for use
with SWT, though I'd intended to have the code actually create any
active components (SwiXML apparently creates them from the XML and then
uses reflection to save references in fields for access by the code).
Have you tried this out?
- Dennis
Warner Onstine wrote:
Umm, have you guys seen SwiXML?
http://swixml.org/
-warner
On Aug 8, 2004, at 12:29 AM, Dennis Sosnoski wrote:
That's interesting to see, they're taking an approach similar to
something I've been planning. People have been trying for several
years now to come up with XML GUI designs for Java, along the lines
of Mozilla's XUL. I think that kind of approach is overkill for Java,
though, and that rather than trying to put the whole GUI description
(including actions and such) into an XML configuration, you'd be much
better off to just put the layout information there. The layouts are
about 90% of the pain in doing cross-platform GUIs anyway, at least
in my experience. It looks like Intellij is going further than I'd
take it, but that's typical of these visual layout tools. At least
it's cleaner than generating the GridBag garbage in code with // {@
AUTOGENERATED CODE - DO NOT MODIFY tags around it.
My idea is to just do the layouts in an XML configuration, and do it
that way as a convenience to programmers who basically want to
control things themselves rather than using a DD-type tool (so you
still create your active controls, only the passive containers and
layouts go into the XML; that way you can easily tweak the layouts
without recompiling, or even support multiple layouts depending on
how something is being used). Maybe I'll have an example for SWT by
September.
- Dennis
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] UI stuff
Tim Colson wrote: Similar topic -- I went through the demo for Intellij's GUI designer while waiting on jury duty this week. Currently it's geared toward simple forms (no menus) and unlike other GUI designers, the primary operating style is to NOT generate code. (They added the option to gen code, but recommend just letting IDEA take care of it completely.) Whipping up basic forms and wiring them into business objects is fairly easy. Hi Tim, How do they actually handle the layouts, if they're not generating code? Some kind of configuration file that gets interpreted at runtime? - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] ColdFusion from JAXRPC
Duffy Gillman wrote: ... So far I've wished real hard, crossed my fingers and held my breath. Neither these nor scouring newsgroups and tutorial sites have yielded the tools nor tutorials I imagine. So I thought to put this to the group. Has anyone ventured to implement the same web service on different platforms (ideally JAXRPC and ColdFusion)? Am I the only wingnut out there who wants to treat WSDL as an interface definition for multiple services (I *can't* be, but hope I'm not the only one here)? Is it possible to get ColdFusion to produce errors (SOAP fault messages) that match up with those in a Java-derived WSDL document? I'd be interested in whatever experieces y'all have had. -Duffy P.S. If I put down a vote for Dennis for the full meeting, do I get to ask obnoxious questions about sharing WSDL files between platforms ;) 'course you do, obnoxious questions are half the fun of speaking at developer groups! :-) As for the specifics of what you're running into, I don't really know anything about the ColdFusion implementation but I suspect this may be one of the examples of why the trend is away from rpc/encoded and toward doc/literal. Most of the existing stuff is written to the rpc/encoded style, which basically takes the parameters to a method call and translates them into XML in a manner that's supposed to be cross-language and cross-platform. The problems with that are (1) it's pretty much impossible to do a cross-language and cross-platform data representation that goes beyond the basics and actually have it work well, and (2) it exposes too much information about your implementation structure as part of the interface, and that implementation may not be appropriate for developers on a different language or platform. I assume that's probably what you're trying to work with. doc/lit basically says ignore the implementation and specify the XML. That means you just have a schema description of the data going in each direction, and it's up to the applications on each end (or the frameworks, more often) to translate that to something useful. For what you're describing a doc/lit approach should work a lot better than rpc/enc. JAX-RPC RI has decent doc/lit support built in; don't know about ColdFusion. If it's based on the Axis code (which I suspect it is - several of the Macromedia people are major participants on Axis), you're probably going to have problems - they're finally getting some of the doc/lit problems cleaned up in the current 1.2 version, but it's still messy even there and anything actually being shipped is likely to be the old 1.1 code. I'll definitely discuss why it's a mess and what to do for workarounds next week, but don't know how much that will help for working within the ColdFusion framework. - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] may preso good news/bad news
While you're soliciting opinions, let me give the group some choices for what I should focus on: * Basic why and what of XML web services, historical background and intro to SOAP WSDL, Apache Axis * Web service details: rpc/enc vs. doc/lit, WS-I Basic Profile, howtos with JAX-RPC, Axis, JibxSoap * Advanced issues: implementing doc/lit on JAX-RPC, Axis, JibxSoap, performance, attachments, securing and hardening web services I won't have time for the whole range even if I get the whole meeting, so I'll let you pick which of the three levels sounds most interesting. I'll try to include a little of whichever other one is the runner up. - Dennis Warner Onstine wrote: So, unfortunately Dave Geary won't be able to present on JSF this month, however Dennis has offered to cover the full 1.5 hours on Web Services. This goes against our typical format of short preso/long preso, so here are the choices: 1) Dennis presenting on Web Services (Axis, jax-rpc, JiBX-Soap) for roughly an hour with half an hour QA 2) Dennis presenting on Web Services for 45 minutes with 15-20 min QA and Tim Colson doing a proper demo of Confluence/Fat Cow testing -warner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Redmond, WA 425.885.7197 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] OGNL and JSRs
Drew Davidson wrote: I just got this forwarded to me by Randy Kahle: http://www.sys-con.com/story/?storyid=44117rss=1 Interesting how Apache (via Gier Magnusson) is part of this JSR, as well as Richard Monson-Haefel (famous author and Java guru). When the idea of an OGNL JSR was brought up to Sun's Rob Gingell I got a negative response (almost condescending actually - Rob shook his head and chuckled a no to me). In light of this JSR I'd like to know why OGNL is not worthy of a JSR and Groovy is. I personally feel that ego JSRs such as this are turning the way the process should work on its head by saying we're going to build this technology that everybody is going to want to use. If that's really the case, why not just build the technology and let people use it? Once it's in widespread use you can always do a JSR for it at that point, and the JSR will actually have some meaning. Otherwise, it's just designing in a vacuum. JDOM is the first and still most prominent example of this type of JSR. The founders got the idea pushed through that (1) there should be a special standard for Java in this particular area, and (2) they should be the ones who get to decide what that standard is. A few years back I expressed the naive idea that the purpose of the JDOM JSR was to define a structure for working with XML documents in Java, and that the experts involved would look at the technologies available and select the best features for the standard. Brett McLaughlin wasted no time in correcting me that the purpose of the JDOM JSR was to get JDOM enshrined as a standard for Java, not to look at other technologies. Anyone who's been following the progress of JDOM can see how well that approach works... (for those who haven't, it's still in beta and the API is still in flux after four years of development, while other similar alternatives that started later have been out in production release for more than two years). Does anyone have any idea why Sun and Apache are so negative toward OGNL? I've struggled with this for years and I just can't figure it out. I forwarded the idea of a binding language for Struts, Ant, etc. till I was blue in the face but no one wanted to hear about it. Then JSP 2.0 comes out with EL and these same people are gung-ho on the idea, even though EL is inferior to OGNL in many ways. I just don't get it. There's a lot of politics involved in technology, unfortunately. I think the best you can do if you're not into the politics is show people what they can do with the technology. If it's useful it'll spread, JSR or not. Look at Hibernate, for instance - this directly competes with the officially sanctioned JDO technology, but Hibernate's winning (won). The downside of JSRs is that they never go away and the implementations usually get bundled into the Java platform (SE or EE). This means that an ever-growing amount of obsolete or semi-useless technology is becoming part of our working environments. I personally think this is what will eventually drag Java down. - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] OGNL and JSRs
Warner Onstine wrote: And also with reference to what Dennis said about JDOM, whatever happened with that JSR? http://www.jcp.org/en/jsr/detail?id=102 It looks like it died, but I don't see any explanation. It refuses to die, but so far has successfully resisted completion. See http://www.jdom.org/ for the latest version. I've been recommending people stay away from JDOM for the last two years, though, because the API changes from beta to beta. This continues to create problems in applications deployed in shared environments because of version conflicts (if something closer to the root happens to use a version of JDOM that's different from your's, you're pretty much screwed) and in maintenance (yes, that bug was fixed long ago - get the latest CVS code... at which point you've no longer got the bug, but your application is broken until you tweak code to match the API changes). - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] anyone see this?
We've had some discussion of this up here on the Seattle JUG, too. Sounds good to me - Sun would still own the Java trademark, but the Linux distros would be able to include it and developers would be able to experiment with language changes and such (as long as they didn't call their tweaked version Java). For a contrary view (and other interesting material), see our Charles Ditzel's blog at http://cld.blog-city.com BTW, being there for the meeting Rob spoke at last year ended up saving me $100. He said then that they'd dropped the fee for individual members of the JCP, so when I got a call asking me to cough up for another year I just referred the accounting people to him. Didn't quite pay for the trip, but it helped! ;-) - Dennis Warner Onstine wrote: Hey guys, Looks like we may have a livelier discussion on the JCP with Rob than I thought ;-). http://www.eweek.com/article2/0,4149,1539664,00.asp Check out the second page, where it mentions the illustrious Rob Gingell ;-). -warner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Prevayler
You might want to look into my JiBX (http://www.jibx.org) project for the XML part, too. JiBX is a higher-level solution than Betwixt and Digester, which I think you'd find easier to set up while also delivering better performance. It's not as automatic as the bean serialization in JDK 1.4, but it gives you control over the XML format and should be more flexible for versioning than the basic bean serialization. I also suspect it's much faster, though I haven't actually tested this. - Dennis Todd Ellermann wrote: Rolled our own Tx Management (pretty simple transaction queue). As for the XML thing. the problem can be solved by handling the serialization manually and overriding the serial ID's etc... to pick up when an old form of the object is being read in. The xml thing would have given us a fill in those fields that are available and set others to defaults approach. The DTD would maybe change slightly but you could handle backwards compatibility for free. Our solution, don't ever update the model or when you do reinstall. The app has no long term reporting requirements and the product catalog is constantly changing. Translation, update = delete old install new. Happy to share the code. In addition, to the new Java XML serialization we tried betwixt digester from the apache group as an approach. Neither got all the attention and love they needed, so I still think it is possible. -Todd __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] code coverage
Sounds like a great meeting - wish I could have been down for last night. On the topic of bytecode manipulation, did anyone discuss Javassist? It's got great hooks for aspect-oriented use, including the ability to easily apply systematic transformations to all uses of a method or field. The JBoss crew is basing their aspect-oriented features on Javassist, though I haven't seen or heard much about what they're doing since the initial release last summer. I don't know of any code coverage projects using Javassist yet, but if anyone hears of one I'd like to find out. I've been using BCEL for some time on the JiBX project. BCEL is reasonably solid, but I'm finding the API increasingly ugly the more I work with it. Until recently it was the only bytecode toolset available under Apache-style licensing, which was the reason I've stuck with it. Now the ASM (http://asm.objectweb.org/) framework is using a BSD license, so I may try switching to that after the upcoming JiBX 1.0 release. - Dennis Warner Onstine wrote: Since this came up in a few of the presentations last night I thought I'd post some follow-up links for y'all ;-) jcoverage - http://jcoverage.com quilt - http://quilt.sf.net If you scroll down to the bottom you will see that this project has been split: http://jxcl.sourceforge.net/ http://cvs.codehaus.org/viewcvs.cgi/quilt/?root=codehaus Now, the last I heard from the Quilt developers was that it wasn't actually doing anything (even at .6a), so I don't know why the split happened. Still haven't received a reply to an email I sent asking about that. Clover - http://www.thecortex.net/clover/index.html -warner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] code coverage
I've now got a second article on devWorks about using Javassist at http://www-106.ibm.com/developerworks/library/j-dyn0203.html (the first one on Javassist was from last fall, and just covered the basics; the third one, covering the systematic transform hooks, should be out in a couple of weeks). Javassist *is* really nice, especially in letting you work with a Java-source-like language for your code. That's much more user friendly than having to use the equivalent of bytecode assembler (as with BCEL, ASM, etc.). If you really *want* to work at the bytecode assembler level, on the other hand, Javassist makes it harder than the other frameworks. For most applications the Java-source-like approach of Javassist is going to be sufficient and a lot easier to learn. - Dennis Warner Onstine wrote: Yeah, Drew brought up Javassist, he really likes it. After looking at the API a bit, it looks really nice. Tapestry is currently using it, and I believe OGNL is as well, but I wasn't clear on that. -warner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] code coverage
I've also implemented wrappers that hide the BCEL dualities, for instance, along with equivalents to some of the other things on your list. Isn't the fact that it's necessary for users to write their own wrapper APIs a sign that the underlying API is badly designed? I think it is. My biggest problem is in the stack/control flow area. In JiBX (http://www.jibx.org) I do complex code generation using nested calls - basically, I want a call to add some code to the method under construction, then call a method that generates more code based on what was added, and generally add some more clean up code after the called method returns. When something gets messed up in the code generation logic I usually end up with a verification failure in the modified class because of a stack mismatch. Ideally I'd like to track the stack contents as I'm appending code to a method and make sure that the stack is consistent both in terms of instruction operands and stack contents at merge points. Then if something goes wrong I'd get an immediate exception, rather than having to first decrypt the problem in the bytecode and then trace through the code generation to find the part that went wrong. I could do something like this based on BCEL, as it sounds like you've done, but ASM sounds like a cleaner and more efficient basis. On the other hand, if you're making your BCEL extensions publicly available I'd love to take a look. :-) - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Support - http://www.sosnoski.com JiBX Lead Developer - http://www.jibx.org Redmond, WA 425.885.7197 BTW, how'd you get money from the New Economy Research Fund of New Zealand? I wouldn't think the Kiwis would have much connection with your rather arid institution... [EMAIL PROTECTED] wrote: My impression of the BCEL api is that it gives you everything you need for bytecode manipulation, and nothing you don't. as in, it's stripped down and bar-bones. The project I work on (www.cs.arizona.edu/sandmark/) has developed a lot of code that works on top of bcel that makes it much easier to use bcel. We have an api for building expressions (like a = b + c) and generating bytecode from them, an api for figuring out what's on the stack anywhere in a method, a control flow graph, an api that hides the JavaClass/ClassGen, Method/MethodGen, Field/FieldGen, etc, dualities, and a whole lot of other stuff. so what i'm saying is, i don't think bcel is bad as such, just fairly minimalist and something you might have to build on top of. Dennis said: I've been using BCEL for some time on the JiBX project. BCEL is reasonably solid, but I'm finding the API increasingly ugly the more I work with it. Until recently it was the only bytecode toolset available under Apache-style licensing, which was the reason I've stuck with it. Now the ASM (http://asm.objectweb.org/) framework is using a BSD license, so I may try switching to that after the upcoming JiBX 1.0 release. - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] For those who haven't seen this yet - Apacheannounces J2EE stack
Whoops, later on in the FAQ I see: *Q: What is Elba?* A: Elba is basically an LGPLed snapshot of JBoss (but not called JBoss to avoid lawsuits). Its not really intended to be developed or enhanced - its a temporary code repository of increasingly shrinking code. The idea being for the next (say 1 year) Geronimo by itself isn't gonna be a full J2EE stack. So rather than suffering a Mozilla-style period of lack of use - Elba is a temporary LGPL add-on to Geronimo that Jboss code with Geronimo to provide a full J2EE stack. So from day 1 Geronimo can be used (if so desired) as a full J2EE stack by using the Elba code. ... - Dennis Dennis Sosnoski wrote: Warner Onstine wrote: From what I've read on the incubator site he is the basic breakdown of what they are doing: 1) They will have a snapshot of the Jboss code which will be a full J2EE stack This doesn't appear to match the FAQ statements: *Q: Will it involve JBoss code.* A: No. This is a new Apache project, running under Apache guidelines. The Apache Software Foundation accepts only voluntary contributions of material from authors who possess the legal right to donate it. ... *Q: Relationship to JBoss and in particular, the JBoss source base.* A: Several (former) JBoss committers are Geronimo committers. The JBoss codebase cannot, and will not, be used, at all (it is LGPL). - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] For those who haven't seen this yet - Apacheannounces J2EE stack
Warner Onstine wrote: From what I've read on the incubator site he is the basic breakdown of what they are doing: 1) They will have a snapshot of the Jboss code which will be a full J2EE stack This doesn't appear to match the FAQ statements: *Q: Will it involve JBoss code.* A: No. This is a new Apache project, running under Apache guidelines. The Apache Software Foundation accepts only voluntary contributions of material from authors who possess the legal right to donate it. ... *Q: Relationship to JBoss and in particular, the JBoss source base.* A: Several (former) JBoss committers are Geronimo committers. The JBoss codebase cannot, and will not, be used, at all (it is LGPL). - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jug-discussion] JiBX Data Binding framework Beta 2
Just to follow up on my talk back in April, I finally posted the long-delayed Beta 2 release for my JiBX XML data binding framework, with many added features: http://www.jibx.org I'll try to get an updated version of my presentation on JiBX and JAXB out on my web site within the next week or so, and I'll post a link to that when I get it online. It was great to meet the crew at the JUG, and I hope I get the chance to attend again. I just got back yesterday from another trip down to Tucson, and have my next one scheduled in September. It's more fun to visit your area in the winter than in the summer, though! - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Support http://www.sosnoski.com Redmond, WA 425.885.7197 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] April 8 Meeting Announcement
I'm really looking forward to meeting people in person at the meeting! I've got a couple of articles that were published this week by IBM devWorks, so I may as well put in a plug for those: Data Binding Part 3: JiBX architecture http://www-106.ibm.com/developerworks/library/x-databd3/index.html on the XML zone, and Securing Linux for Java services http://www-106.ibm.com/developerworks/linux/library/l-secjav.html on the Linux zone. - Dennis Simon Ritchie wrote: The next meeting on April 8, will feature two interesting speakers: Dennis Sosnoski and Rob Gingell. The meeting will be held in the large conference room at Arizona Mail Order. Here are the presentation topics: Short Presentation The short presentation will be from Dennis Sosnoski. He will be speaking on his open source data binding project JiBX (http://www.jibx.org). Dennis is the founder of Sosnoski Software Solutions http://www.sosnoski.com/ and is a frequent speaker on Java technologies and related Internet issues. Main Presentation The main presentation will be from Rob Gingell. Rob will be speaking on JCP, Sun and Network Computing. It will be a presentation in two parts. Part I: a largely vendor agnostic discussion of the status of the Java Community Process and recent updates to it. Part II: a largely vendor specific discussion about Sun's interests in Java and Network Computing. Rob Gingell is a Sun Fellow and Vice President and currently serves as Sun's Chief Engineer and also as the Chair of the Java Community Process (SM). He has been with Sun since 1985 and prior to that was on the staff of Case Western Reserve University, from which he received a B.S. in Computer Engineering in 1977. His current interests are in network computing environments. Thanks, Simon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jug-discussion] Big savings through open source Java
There's a very nice article on ZDNet discussing how FCCI Insurance Group made the move from Windows/IIS/Delphi to Linux/JBoss/Eclipse: http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2908812,00.html If your group is having a tough time convincing management to let you go with open source software this may make a good plug. - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Support http://www.sosnoski.com Redmond, WA 425.885.7197 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] JDK 1.4 and XML?
Tim Colson wrote: From a cursory look, would I be correct saying JAXB appears suited to Java Object mapping to/from generic XML, whereas java.beans.XMLEncode/Decode appear suited to Java Object Serialization to/from Java Specific XML? If that's not correct, could you please give the high-level what's the difference and when would you use one versus the other? Thanks! Tim Your statement's a pretty good summary. Just to add a little detail for anyone interested, XMLEncoder and XMLDecoder are much more limited than the data binding frameworks I discuss in the article. They only work with JavaBean objects, they only work with a particular format that corresponds directly to the JavaBeans, and because they only use runtime reflection their performance is likely to be poorer than the data binding frameworks (though I don't know that for sure - they can't handle the XML I use for my tests, so I haven't actually tried them out to see how they stack up by comparison). XMLEncoder and XMLDecoder are still very useful if you just want to work with an XML format for things like configuration data. You just plug into them and get instant XML in a fairly readable format. - Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] FYI: dom4j
Hey Tom, since you linked to my articles I may as well toss in my $.02. I've tried a number of different projects using any one or more of these three APIs. I'd put the tradeoffs this way: * DOM - the big advantages are cross-language interface (if you use other languages beside Java) and wide support, including JAXP support and combining it with XSLT * JDOM - convenient API for simple document construction and data retrieval, generally pretty easy to understand (but eternal beta project, typically with some API tweaks between betas) * dom4j - power API (splitting large documents, XPath built in, etc.), stable production release, very good performance; but API more complex, and multiple levels of interfaces can be confusing at first (let's see, there should be a method that does X for an element, now is it in Element, Branch, or Node?) For most types of XML processing some other type of approach may be better than any of the document models. If you just want to extract information from an input document, Jakarta Digester or a pull parser (http://www.xmlpull.org) may be your best bet. If you just want to generate a document as output, XMLWriter (http://www.megginson.com/Software/) is easy. If you're doing more sophisticated processing of the data in a document, but are only interested in it as data, data binding (http://www.castor.org, http://java.sun.com/xml/jaxb/index.html, etc.) is probably the best. The only time you really need to mess with document models is when you're actually working with the XML structure of documents - if you're writing an XML editor, for instance, or a processor that needs to work with different types of documents. - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Support http://www.sosnoski.com Redmond, WA 425.885.7197 (BTW, I don't have search bots constantly scanning mailing lists for reference to my articles so I can jump in on the discussion. :-) I've been on the Tucson list for a while since I get down your way fairly often and wanted to find out about projects in the area. I'll be down this next Saturday; hope to make it for your JUG meeting one of these trips.) Thomas Hicks wrote: At 12:04 AM 12/11/2002 -0700, I wrote: Here's a (slightly old) related article which compares some XML document models, including JDOM, DOM, and dom4j: http://www-106.ibm.com/developerworks/library/x-injava/index.html RatsI forgot to include the URL for Part 2 of the article cited above. Part 2 does some small code comparisons: http://www-106.ibm.com/developerworks/library/x-injava2/ -tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
