mingus:~/ $ cd /usr/local/openejb-1.0-beta1 mingus:/usr/local/openejb-1.0-beta1 03:37:33 $ cp beans/openejb-webadmin-main.jar lib/ mingus:/usr/local/openejb-1.0-beta1 03:37:52 $ ./bin/openejb start OPENEJB_HOME = /usr/local/openejb-1.0-beta1 OpenEJB 1.0-beta1 build: 20050829-2233 http://www.openejb.org resources 1 OpenEJB ready. [init] OpenEJB Remote Server ** Starting Services ** NAME IP PORT admin thread <IP_ADDRESS> 4200 ejbd <IP_ADDRESS> 4201 telnet <IP_ADDRESS> 4202 webadmin <IP_ADDRESS> 4203 ------- Ready!
Webadmin
The Webadmin is a new addition to OpenEJB 1.0 and very innovative in that it lets you plug-in your own admin beans. Here are some screenshots:
Enabling the Webadmin in 1.0 beta 1
The Webadmin console is in the 1.0 beta 1 release. To enable it, simply move into the openejb.home directory and copy the openejb-webadmin-main.jar from the beans directory into the lib directory. Then start the server.
Now you can open your browser to go to http://localhost:4203/
WebAdmin Beans
To create an EJB and have it included as part of the WebAdmin, simply subclass from WebAdminBean and include it in your ejb-jar.xml file as such:
<session> <description>A JNDI viewer</description> <ejb-name>webadmin/ViewJndi</ejb-name> <home>org.openejb.webadmin.HttpHome</home> <remote>org.openejb.webadmin.HttpObject</remote> <ejb-class>org.openejb.webadmin.clienttools.ViewJndiBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> </session>
The ejb-name is used to create the menus and should follow the format of 'menu-section/menu-item'. WebAdminBeans are grouped together by the 'menu-section' portion of their ejb-name. The 'menu-item' is the clickable link that causes the EJB code to be execute. Very simple and makes it possible to package administrative components with your EJB applications.
WebAdmin Plugins
Here is a project that already takes advantage of the new feature. [BeanGen |
Developers guide
Below is David Blevins' email on how webadmin worked. Please have a look at the text below before you start working on porting the existing WebAdmin to version 3.
Plain old stateless beans were used as the "servlets". To make a bean that would show up in the Webadmin Console you simply had to implement the HttpBean interface (i think it’s now called HttpListener) and give your bean a deploymentId following this format "webadmin/{section}/{page}". Anyone could add to the Webadmin console by doing both of these things, which is really cool as people developing EJB apps can also deploy beans for administering those apps right in the exact same jar. This is not only easy for packaging but means new sections can be added/removed on the fly.
Using the described "webadmin/{section}/{page}" deploymentId format, things end up automagically grouped in the JNDI tree. There’s a 'webadmin' context we grab which will contain any number of "section" contexts ("ClientTools", "EJBGenerator", etc.). Each of those section subcontexts will contain several beans which we will use to make the pages. Making the menu is pretty easy as we just iterate over the webadmin section of the global jndi tree.
When an http request came in we just took the path part of the GET or POST request, prepended "webadmin/" and then went looking for a bean with that deployment id and invoked it via it’s HttpBean (now called HttpListener) interface passing in a HttpRequest and HttpResponse objects which are trimmed down versions of similar servlet classes. There’ll be some changes to this as now we support our plain ejb protocol over our http implementation, so the two will have to find a way to share the URL space. See the openejb-http module.
To implement session state, we had a stateful session bean implementing an HttpSession interface (again, similar to the servlet equivalent) and simply wrote the internal ID of the bean instance into a Cookie sent to the browser. For some reason we would write the javax.ejb.Handle of the stateful bean’s EJBObject to disk and read it back out on subsequent requests then used it to get a reference to the EJBObject again. I’m not sure why we didn’t just keep a static hashmap and put the EJBObject right in it using an ID we could just make up like UUID (that would have been way simpler).
We had a standard superclass we favored for beans that implemented the HttpBean (HttpListener) interface that did templating and the aforementioned menu construction. The templating was perhaps too tricky as we used a non-printable character to determine where to insert data. Now we could just use swizzle-stream for some pretty decent templating ability or even velocity. I’d be hesitant to endorse velocity as we already have a dep on swizzle-stream and wouldn’t want to see us add another meg to our distro size if we can avoid it — we have like 3 times as many deps as 1.0 did and we should probably start tightening the belt.
To serve static things like images, we had a "default" HttpBean which searched for the items in the classpath and wrote them into the response setting the mime type, etc. correctly. One thing that we never did which still needs to happen is that the bean didn’t have the logic to set the modification information into the response so the "If modified since" header which would allow the browser to rely on it’s cache instead of requesting the same images over and over again.
That pretty much covers the way it was put together.
-
The Jndi Viewer, Class Viewer, Ejb Viewer, and Object Invoker were written by yours truly
-
The EJB Generator was written by Jeremy Whitlock
-
Everything else was written by Tim Urberg. Tim was "WebAdmin guy" for a good long while. Before Tim came along the webadmin was just some experimental code I had in a branch, he did more than he realizes by putting his energy into it — active people attract/ create more active people. Maybe we can convince him to come back and work on it ;)
And of course I have to mention our own Paulo Lopes who wrote a really cool project out in SF.net (http://beangen.sourceforge.net/) which was the first plugin for the OpenEJB Webadmin. He wrote it before we even had shipped a release containing the Webadmin or had any docs at all on it, which in my mind shows just how neat the idea of using ejb’s and simple conventions to do the console really is.
Some notes going forward is that we have a truck load of meta-data now available via SystemInstance.get().get (OpenEjbConfiguration.class). Certainly JSR-77 is one option, but we could do far better with plain old java code. That tree is the primary source of meta-data for OpenEJB, it’s what was used to construct every container, bean, resource adapter, database connector and everything in the system (well, sans the protocols). Someone new to the project can look at it and understand it without having to read any abstract specs. Something to consider. The tree is read only in it’s function, however it is possible to copy then edit and make new containers, etc. based on existing definitions.
Additionally, using this same data structure it’s possible to show the potential services available via the service-jar.xml files in the classpath that detail containers, resource adapters, database connectors, etc. which can be configured/created at runtime. So we could also display a sort of catalogue of components (aka. services) that someone could click and deploy via the console.


TO SEARCH, ENTER YOUR PASSWORD
Don't have one? Sign up for free on our website
ThE NeW SeArCh EnGiNe©
Version2.0.13
Private Edition 2009
Type your password:
Customised Search
Default Search
COMMONLY VISITED PAGES:
Yahoo!Mail
Gmail
Hotmail
Facebook
Twitter
nVIDIA
NetCarShow
Wikimapia
Wikipedia
Videos recently watched on Youtube:
Movie


Upon program instantiation, you are immediately presented with a standard 3x3x3 Rubik's cube. It is not immediately obvious, because no cuts are visible on the cube, but if you click on the "Puzzle" menu, you'll see that the "Rubiks3x3x3" menu item is checked. You can use this menu to create other puzzle types.
The sub-sections that follow are worth reading, but if you'd like to watch a video introduction to the program, I tried to make one at "https://youtu.be/OVWdLHdGs2M". If this link fails, it may be that you need to install "snapd-xdg-open". Note that I failed to capture the mouse cursor in this video, but it should still be fairly instructive.
In general, the often-combersome nature of manipulating a virtual twisty puzzle can make them much less fun to play with than their physical counter-parts. The intuitiveness and ease-of-use of the user-interface to such a puzzle, therefore, is of paramount importance; and that is why a number of ways of manipulating the puzzle have been provided as discussed in the following sub-sections. Dispite these difficulties, however, there are a number of obvious advantages to a computer simulation as I hope you'll see.
Holding down the left mouse button with the cursor inside the window's drawing area while dragging the mouse, you'll see that the puzzle can be rotated so as to give you a view of the puzzle from almost any perspective. While holding down the shift key, rotating the mouse wheel lets you zoom in and out.
There are two ways to do this using the mouse, and a third way using the keyboard.
By now you've probably noticed a few semi-transparent arrows poking out of the puzzle. These represent axes of rotation about which a cut-shape cuts-out and rotates a portion of the puzzle. After right-clicking on the arrow-tip of one of these axes, you'll see the cut-shape appear and the arrow draw a bit brighter. You can then use the mouse wheel to rotate the portion of the puzzle intersected by the selected cut-shape.
Manually selecting the cut-shape axis like this can be annoying; so in that case, you may find it more convenient to turn on auto-selection of these axes. To do that, use the "Auto Select Axes" menu item under the "Interface" menu. This causes the cut-shape axis nearest the mouse-ray to be selected at all times. Admittedly, this is an idea stolen from the well-known gelatin-brain program.
This means of manipulating the puzzle was harder to implement and, consequently, a bit less reliable, but it is far more intuitive and less tedious than the previous method. As of this writing, it is best to generate all cuts of the puzzle before using this method, which is often the case after a good scrambling. Go to the "Program" menu and select "Scramble". After dismissing the subsequent dialog, wait for the puzzle to scramble, then move your mouse cursor over a face of the puzzle. Now, while holding down the right mouse button, drag the mouse to see how the puzzle is manipulated. With practice, you can get a feel for how this works. Be sure to drag the mouse cursor in a straight line for best results. If at all possible, click on a face of the puzzle that can only be affected by the desired rotation axis. I've noticed that with puzzle with many axes, it's just too hard to use this manipulation method. Furthermore, if a puzzle has overlapping, parallel rotation axes, I do not as yet have a way of determing which one is the intended axes of rotation.
Go to the "Render" menu and select "Draw Axis Labels" if it is not already checked. Axis labels should then appear next to each of the arrows poking out of the puzzle. There are two types of such labels: those that are assigned dynamically, and those that are statically assigned. If in the former case, the labels will changes as you orient the puzzle; otherwise, they always stay the same. For some puzzles, this dynamic labeling is convenient, for others, it might not matter. Use the "Lock Labels" menu item under the "Interface" menu to freeze the current axis labeling if you don't want it to change as you orient the puzzle.
Now click in the text-control at the bottom of the window, above the status bar. Here you can enter a comma-delimited sequence of rotation commands, each of which being simply the name of an axis of the puzzle with an "i" optionally appended. For example, on the Rubik's Cube, you might enter "U,R,Ui,Li,U,Ri,Ui,L" without the quotes. Entering this sequence should enqueue 8 rotations as shown in the status bar. For puzzles with a special move, such as the CurveyCopter3, you can prepend an exclamation mark, or caret symbol to access the special move, and its alternate.
Some puzzles have special moves that other puzzles do not. As of this writing, the CurvyCopter and CurvyCopter3 are the only examples. To jumble an edge of the CurvyCopter, select its rotation axis, then rotate with the mouse wheel as usual, but while holding down a combination of 0, 1 or 2 on the num-pad. The same goes for the CurvyCopter3. A special kind of jumble unique to the Curvy-Copter Plus is supported by both the CurvyCopter and CurvyCopter3 puzzles. Currently there is no way to specify a jumble using the command-line interface.
If you make a mistake, you can always use the "Go Backward" menu option under the "History" menu. Note that as of this writing, your rotation history does not presist with the saving of your puzzle to disk.
If you so desire, you can change the color of the faces of a puzzle by right-double-clicking on a face to bring up the color-choose dialog. Note that you can do this with any face, even after the puzzle has been scrambled. So if you want the keep the puzzle sane, choose your colors before you scramble the puzzle.


Abstract Window Toolkit (AWT)
The Abstract Window Toolkit (AWT) supports Graphical User
Interface (GUI) programming. AWT features include:
- A set of native user interface components
- A robust event-handling model
- Graphics and imaging tools, including shape, color, and font
classes
- Layout managers, for flexible window layouts that do not depend
on a particular window size or screen resolution
- Data transfer classes, for cut-and-paste through the native
platform clipboard
The Swing classes are built on
top of the AWT architecture.
API Specification
Tutorials and Programmer's Guides
API Enhancements
More Information


public static final class R.string
extends java.lang.Object
| Constructor and Description |
|---|
R.string() |
public static final int action_settings
public static final int app_name
public static final int builder_interest_error
public static final int builder_interest_label_name
public static final int builder_interest_label_room
public static final int builder_io_error
public static final int builder_io_label_from
public static final int builder_io_label_to
public static final int builder_io_label_two_way
public static final int builder_io_not_enough_room
public static final int builder_io_same_room
public static final int builder_load_level_error
public static final int builder_load_level_nok
public static final int builder_load_level_ok
public static final int builder_menu_interest
public static final int builder_menu_io
public static final int builder_menu_load
public static final int builder_menu_menu
public static final int builder_menu_room
public static final int builder_menu_save
public static final int builder_room_already_referenced
public static final int builder_room_error
public static final int builder_room_name
public static final int builder_room_name_empty
public static final int builder_room_nok
public static final int builder_room_ok
public static final int builder_save_level_error
public static final int builder_save_level_name
public static final int builder_save_level_name_empty
public static final int builder_save_level_nok
public static final int builder_save_level_ok
public static final int builder_switch_rotation
public static final int builder_title
public static final int hello_world
public static final int menu_main_button_builder
public static final int menu_main_button_game
public static final int menu_main_button_quit
public static final int menu_main_button_share
public static final int menu_main_share
public static final int menu_main_share_error
public static final int menu_main_title
public static final int title_activity_game


You'd think that Object-Oriented languages would have more things in common.
Then again, when you think about it, you'd think that maybe they should be more different.
Javascript is different then Ruby. But it isn't that different. A lot of things stay the same- the biggest change is to remember a ; at the end of a line. But for the most part, things are the same, they just go by different names.
A hash is a Ruby thing. It's a Key-Value pair. Which is a fancy way of saying you want one thing to lead to another - like a dictionary. I have a bag of fruit, and want to document how many of each I have. I can create a hash that is called fruit_count. In it, I say "apple" ==> 3 and "pear" ==> 2. Now, when I want to see how many I have, I can just tell Ruby to look up the hash, and to access the apple part. It will return 3.
Let's first say that everything in ruby is an object. Even the hash, it's just a special kind of object.
JavaScript calls things objects, when in reality many other things are also objects.
But as to what it calls an object- it behaves much the same way that a Ruby hash would. Again, saying I have a bag of fruit. When I declare the variable fruit, I'll give it properties, and then those properties will have values. Sounds similar... So, I can again point apple to 3 and pear to 1.
Now, probably the biggest difference is how you get back to the values.
In Ruby, if you want to get to the apple count, you'd do this-
fruit_count[:apple]
JavaScript is along those lines. You'd say
fruit_count.apple
In both cases, the output will be 3.


Message Signature
Transaction:
$
From:
To:
Private Key:
Sign
Transaction Signature:
Signature Verification
Transaction:
$
From:
To:
Public Key:
Verify
Transaction Signature:


About Me
Hi, my name is Dominique Buford. I am from Dallas, Texas, I'm a sophomore at Duke University, and I plan to major in Computer Science. At Duke, I am a member of the Baldwin Scholars Program and the MireCourt Selective Living Group. I am also very close with my family and I love spending time with them. My family includes my mom, my dad,my two sisters, Brianna and Cortney, and my two dogs, T.J. and Bella. I hope this portfolio gives you a little more insight on who I am as a person.
My Mission for Code
I have always been interested in learning how things around us function. More importantly, I wanted to know how I could create something useful of my own with technology.I believe that coding is a unique way to combine technology and creativity to produce amazing projects that can impact the world around us. Fortunately, since technology continues to rapidly evolve before our very eyes, there is always so many new things to learn.My mission is to one day use technology to help underprivileged communities in an impactful way.


Community is important for learning a new language. You can test your skills in real life situations and learn from others. Its also a great way to make friends!
Meetups take place regularly around Stuttgart and Ludwigsburg. Meetup locations vary from cafes to bars or even a picnic if the weather is nice!
Head to upcoming events to see where we are meeting next.


{% import "photo_card.html" as photo_card %} {% import "header.html" as header %} {% import "tag_object.html" as tag_object %} {% import "clipboard_tray.html" as clipboard_tray %}
You got {{photos|length}} items


--- date: 2015-01-14 10:00:03 author: Jen Gray title: "PhoneGap Day US 2014: The New PhoneGap Developer Apps" format: html tags: - PhoneGap Day - Event - Community ---
A big thanks to everyone who was able to make it to PhoneGap Day US. We'll be posting more videos from the conference so check back on our blog or Youtube channel.
In this session we'll take a look at the newest additions to the PhoneGap toolset, the PhoneGap Desktop App and the PhoneGap Developer App.
Herm Wong, Adobe | @hermwong
Tim Kim, Adobe | @timkim