Search Results

Search found 56 results on 3 pages for 'holden robbins'.

Page 3/3 | < Previous Page | 1 2 3 

• What do you read?

  - by sixtyfootersdude

  I have almost finished reading all the articles on Joel on software. I am a new developer and hoping to get something interesting to read. Here is what is currently on my list: Java Concurrency in Practice by Brian Goetz sed & awk by Dougherty & Robbins (O'Reilly) The Pragmatic Programmer by Andrew Hunt and David Thomas Head First Design Patterns Can anyone suggest anything else? Would especially like something similar to Joel. Something that is a bit edgy but informative. Pragmatic programmer has some key concepts but is a bit dry.

  Read the article

• local msmtp and ovh hosting

  - by klez

  I have my personal email hosted on OVH (personal hosting plan) and I'm not able to send mails using msmtp. Here's a typical session ignoring system configuration file /etc/msmtprc: File o directory non esistente loaded user configuration file /home/klez/.msmtprc using account default from /home/klez/.msmtprc host = ssl0.ovh.net port = 465 timeout = off protocol = smtp domain = localhost auth = choose user = federicoculloca%xxxxxxx password = * ntlmdomain = (not set) tls = on tls_starttls = off tls_trust_file = (not set) tls_crl_file = (not set) tls_fingerprint = (not set) tls_key_file = (not set) tls_cert_file = (not set) tls_certcheck = off tls_force_sslv3 = off tls_min_dh_prime_bits = (not set) tls_priorities = (not set) auto_from = off maildomain = (not set) from = federicoculloca@xxxxxxxx dsn_notify = (not set) dsn_return = (not set) keepbcc = off logfile = (not set) syslog = (not set) reading recipients from the command line TLS certificate information: Owner: Common Name: ssl0.ovh.net Organizational unit: Domain Control Validated Issuer: Common Name: OVH Secure Certification Authority Organization: OVH SAS Organizational unit: Low Assurance Country: FR Validity: Activation time: lun 31 gen 2011 01:00:00 CET Expiration time: mer 15 feb 2012 00:59:59 CET Fingerprints: SHA1: F9:DC:41:F9:A2:38:51:9B:56:E4:98:E6:CD:81:31:42:E6:0E:26:6D MD5: FC:EC:F3:8F:28:E4:7E:28:99:89:E6:BB:C9:DF:71:CE <-- 220 ns0.ovh.net ssl0.ovh.net. You connect to mail427.ha.ovh.net ESMTP --> EHLO localhost <-- 250-ssl0.ovh.net. You connect to mail427.ha.ovh.net <-- 250-AUTH LOGIN PLAIN <-- 250-AUTH=LOGIN PLAIN <-- 250-PIPELINING <-- 250-8BITMIME <-- 250 SIZE 109000000 --> AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <-- 235 ok, go ahead (#2.0.0) --> MAIL FROM:<federicoculloca@xxxxx> --> RCPT TO:<[email protected]> --> DATA <-- 250 ok <-- 250 ok <-- 354 go ahead --> hello world --> . <-- 554 mail server permanently rejected message (#5.3.0) And my configuration # ~/.msmtp # Mostly from Peter Garrett's examples # https://lists.ubuntu.com/archives/ubuntu-users/2007-September/122698.html # Accounts from Scott Robbins' `A Quick Guide to Mutt' # http://home.nyc.rr.com/computertaijutsu/mutt.html account xxxxx host ssl0.ovh.net from federicoculloca@xxxxxx auth on user federicoculloca%xxxxxx password xxxxxx tls on tls_certcheck off tls_starttls off Any idea?

  Read the article

• Authlogic OpenID: Fetching E-Mail from Provider.

  - by Shripad K

  This is a really weird problem: I have set up the authlogic_openid_selector_example app. When i register, the email id is not returned by the openid provider the first time. But if i delete the account and register again, the email id is returned. But this doesn't seem to be happening in the example hosted here: http://big-glow-mama.heroku.com/. How do i fix this problem? Has this got to do with caching? I have hosted my version of the app here: http://pingauthtest.heroku.com/ I guess the author of authlogic_openid_selector_example app (@holden) has forgotten to commit new changes. :) I looked at my development log and the first time the provider doesn't return the openid.ext1.value.ext0 which contains the email id. This is returned the second time only after having deleted the account first. Edit: This is some extra info for debugging: THIS IS WHEN IT REGISTERS: OpenIdAuthentication::Association Load (5.3ms) SELECT * FROM "open_id_authentication_associations" WHERE ("open_id_authentication_associations"."server_url" = E'https://www.google.com/accounts/o8/ud') Generated checkid_setup request to https://www.google.com/accounts/o8/ud with assocication AOQobUde_9BUnQsk91rb_Sf9tguJ-S7Gpkwahc-nvDGDYAC8nphisNqu Redirected to https://www.google.com/accounts/o8/ud? openid.assoc_handle=AOQobUde_9BUnQsk91rb_Sf9tguJ-S7Gpkwahc-nvDGDYAC8nphisNqu &openid.ax.mode=fetch_request &openid.ax.required=ext0 &openid.ax.type.ext0=http%3A%2F%2Faxschema.org%2Fcontact%2Femail &openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select &openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select &openid.mode=checkid_setup &openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0 &openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0 &openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1 &openid.realm=http%3A%2F%2Flocalhost%3A3000%2F &openid.return_to=http%3A%2F%2Flocalhost%3A3000%2Faccount%3Ffor_model%3D1%26_method%3Dpost%26open_id_complete%3D1 &openid.sreg.required=email Completed in 3574ms (DB: 14) | 302 Found [http://localhost/account] THIS IS WHEN IT USES SESSIONS: OpenIdAuthentication::Association Load (5.3ms) SELECT * FROM "open_id_authentication_associations" WHERE ("open_id_authentication_associations"."server_url" = E'https://www.google.com/accounts/o8/ud') Generated checkid_setup request to https://www.google.com/accounts/o8/ud with assocication AOQobUde_9BUnQsk91rb_Sf9tguJ-S7Gpkwahc-nvDGDYAC8nphisNqu Redirected to https://www.google.com/accounts/o8/ud? openid.assoc_handle=AOQobUde_9BUnQsk91rb_Sf9tguJ-S7Gpkwahc-nvDGDYAC8nphisNqu &openid.ax.mode=fetch_request &openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select &openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select &openid.mode=checkid_setup &openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0 &openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0 &openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1 &openid.realm=http%3A%2F%2Flocalhost%3A3000%2F &openid.return_to=http%3A%2F%2Flocalhost%3A3000%2Fuser_session%3Ffor_session%3D1%26_method%3Dpost%26open_id_complete%3D1 Completed in 2708ms (DB: 15) | 302 Found [http://localhost/user_session]

  Read the article

• ClassCastException When Calling an EJB that Exists on Same Server

  - by aaronvargas

  I have 2 ejbs. Ejb-A that calls Ejb-B. They are not in the same Ear. For portability Ejb-B may or may not exist on the same server. (There is an external property file that has the provider URLs of Ejb-B. I have no control over this.) Example Code: in Ejb-A EjbBDelegate delegateB = EjbBDelegateHelper.getRemoteDelegate(); // lookup from list of URLs from props... BookOfMagic bom = delegateB.getSomethingInteresting(); Use Cases/Outcomes: When Ejb-B DOES NOT EXIST on the same server as Ejb-A, everything works correctly. (it round-robbins through the URLs) When Ejb-B DOES EXIST on the same server, and Ejb-A happens to call Ejb-B on the same server, everything works correctly. When Ejb-B DOES EXIST on the same server, and Ejb-A calls Ejb-B on a different server, I get: javax.ejb.EJBException: nested exception is: java.lang.ClassCastException: $Proxy126 java.lang.ClassCastException: $Proxy126 NOTE (not normal use case but may help): When Ejb-B DOES EXIST on the same server, and this server is NOT listed in the provider URLs for Ejb-B, and Ejb-A calls Ejb-B on a different server, I get the same Exception as above. I'm using Weblogic 10.0, Java 5, EJB3 Basically, if Ejb-B Exists on the server, it must be called ONLY on that server. Which leads me to believe that the class is getting loaded by a local classloader (on deployment?), then when called remotely, a different classloader is loading it. (causing the Exception) But it should work, as it should be Serialized into the destination classloader... What am I doing wrong?? Also, when reproducing this locally, Ejb-A would favor the Ejb-B on the same server, so it was difficult to reproduce. But this wasn't the case on other machines.

  Read the article

• ClassCastException When Calling an EJB Remotely that Exists on Same Server

  - by aaronvargas

  I have 2 ejbs. Ejb-A that calls Ejb-B. They are not in the same Ear. For portability Ejb-B may or may not exist on the same server. (There is an external property file that has the provider URLs of Ejb-B. I have no control over this.) Example Code: in Ejb-A EjbBDelegate delegateB = EjbBDelegateHelper.getRemoteDelegate(); // lookup from list of URLs from props... BookOfMagic bom = delegateB.getSomethingInteresting(); Use Cases/Outcomes: When Ejb-B DOES NOT EXIST on the same server as Ejb-A, everything works correctly. (it round-robbins through the URLs) When Ejb-B DOES EXIST on the same server, and Ejb-A happens to call Ejb-B on the same server, everything works correctly. When Ejb-B DOES EXIST on the same server, and Ejb-A calls Ejb-B on a different server, I get: javax.ejb.EJBException: nested exception is: java.lang.ClassCastException: $Proxy126 java.lang.ClassCastException: $Proxy126 I'm using Weblogic 10.0, Java 5, EJB3 Basically, if Ejb-B Exists on the server, it must be called ONLY on that server. Which leads me to believe that the class is getting loaded by a local classloader (on deployment?), then when called remotely, a different classloader is loading it. (causing the Exception) But it should work, as it should be Serialized into the destination classloader... What am I doing wrong?? Also, when reproducing this locally, Ejb-A would favor the Ejb-B on the same server, so it was difficult to reproduce. But this wasn't the case on other machines. NOTE: This all worked correctly for EJB2

  Read the article

• What Every Developer Should Know About MSI Components

  - by Alois Kraus

  Hopefully nothing. But if you have to do more than simple XCopy deployment and you need to support updates, upgrades and perhaps side by side scenarios there is no way around MSI. You can create Msi files with a Visual Studio Setup project which is severely limited or you can use the Windows Installer Toolset. I cannot talk about WIX with my German colleagues because WIX has a very special meaning. It is funny to always use the long name when I talk about deployment possibilities. Alternatively you can buy commercial tools which help you to author Msi files but I am not sure how good they are. Given enough pain with existing solutions you can also learn the MSI Apis and create your own packaging solution. If I were you I would use either a commercial visual tool when you do easy deployments or use the free Windows Installer Toolset. Once you know the WIX schema you can create well formed wix xml files easily with any editor. Then you can “compile” from the wxs files your Msi package. Recently I had the “pleasure” to get my hands dirty with C++ (again) and the MSI technology. Installation is a complex topic but after several month of digging into arcane MSI issues I can safely say that there should exist an easier way to install and update files as today. I am not alone with this statement as John Robbins (creator of the cool tool Paraffin) states: “.. It's a brittle and scary API in Windows …”. To help other people struggling with installation issues I present you the advice I (and others) found useful and what will happen if you ignore this advice. What is a MSI file? A MSI file is basically a database with tables which reference each other to control how your un/installation should work. The basic idea is that you declare via these tables what you want to install and MSI controls the how to get your stuff onto or off your machine. Your “stuff” consists usually of files, registry keys, shortcuts and environment variables. Therefore the most important tables are File, Registry, Environment and Shortcut table which define what will be un/installed. The key to master MSI is that every resource (file, registry key ,…) is associated with a MSI component. The actual payload consists of compressed files in the CAB format which can either be embedded into the MSI file or reside beside the MSI file or in a subdirectory below it. To examine MSI files you need Orca a free MSI editor provided by MS. There is also another free editor called Super Orca which does support diffs between MSI and it does not lock the MSI files. But since Orca comes with a shell extension I tend to use only Orca because it is so easy to right click on a MSI file and open it with this tool. How Do I Install It? Double click it. This does work for fresh installations as well as major upgrades. Updates need to be installed via the command line via msiexec /i <msi> REINSTALL=ALL REINSTALLMODE=vomus   This tells the installer to reinstall all already installed features (new features will NOT be installed). The reinstallmode letters do force an overwrite of the old cached package in the %WINDIR%\Installer folder. All files, shortcuts and registry keys are redeployed if they are missing or need to be replaced with a newer version. When things did go really wrong and you want to overwrite everything unconditionally use REINSTALLMODE=vamus. How To Enable MSI Logs? You can download a MSI from Microsoft which installs some registry keys to enable full MSI logging. The log files can be found in your %TEMP% folder and are called MSIxxxx.log. Alternatively you can add to your msiexec command line the option msiexec …. /l*vx <LogFileName> Personally I find it rather strange that * does not mean full logging. To really get all logs I need to add v and x which is documented in the msiexec help but I still find this behavior unintuitive. What are MSI components? The whole MSI logic is bound to the concept of MSI components. Nearly every msi table has a Component column which binds an installable resource to a component. Below are the screenshots of the FeatureComponents and Component table of an example MSI. The Feature table defines basically the feature hierarchy.  To find out what belongs to a feature you need to look at the FeatureComponents table where for each feature the components are listed which will be installed when a feature is installed. The MSI components are defined in the  Component table. This table has as first column the component name and as second column the component id which is a GUID. All resources you want to install belong to a MSI component. Therefore nearly all MSI tables have a Component_ column which contains the component name. If you look e.g. a the File table you see that every file belongs to a component which is true for all other tables which install resources. The component table is the glue between all other tables which contain the resources you want to install. So far so easy. Why is MSI then so complex? Most MSI problems arise from the fact that you did violate a MSI component rule in one or the other way. When you install a feature the reference count for all components belonging to this feature will increase by one. If your component is installed by more than one feature it will get a higher refcount. When you uninstall a feature its refcount will drop by one. Interesting things happen if the component reference count reaches zero: Then all associated resources will be deleted. That looks like a reasonable thing and it is. What it makes complex are the strange component rules you have to follow. Below are some important component rules from the Tao of the Windows Installer … Rule 16: Follow Component Rules Components are a very important part of the Installer technology. They are the means whereby the Installer manages the resources that make up your application. The SDK provides the following guidelines for creating components in your package: Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies. Two components must not have the same key path file. This is a consequence of the previous rule. The key path value points to a particular file or folder belonging to the component that the installer uses to detect the component. If two components had the same key path file, the installer would be unable to distinguish which component is installed. Two components however may share a key path folder. Do not create a version of a component that is incompatible with all previous versions of the component. This rule should be applied across applications, products, product versions, and companies. Do not create components containing resources that will need to be installed into more than one directory on the user’s system. The installer installs all of the resources in a component into the same directory. It is not possible to install some resources into subdirectories. Do not include more than one COM server per component. If a component contains a COM server, this must be the key path for the component. Do not specify more than one file per component as a target for the Start menu or a Desktop shortcut. … And these rules do not even talk about component ids, update packages and upgrades which you need to understand as well. Lets suppose you install two MSIs (MSI1 and MSI2) which have the same ComponentId but different component names. Both do install the same file. What will happen when you uninstall MSI2?   Hm the file should stay there. But the component names are different. Yes and yes. But MSI uses not use the component name as key for the refcount. Instead the ComponentId column of the Component table which contains a GUID is used as identifier under which the refcount is stored. The components Comp1 and Comp2 are identical from the MSI perspective. After the installation of both MSIs the Component with the Id {100000….} has a refcount of two. After uninstallation of one MSI there is still a refcount of one which drops to zero just as expected when we uninstall the last msi. Then the file which was the same for both MSIs is deleted. You should remember that MSI keeps a refcount across MSIs for components with the same component id. MSI does manage components not the resources you did install. The resources associated with a component are then and only then deleted when the refcount of the component reaches zero.   The dependencies between features, components and resources can be described as relations. m,k are numbers >= 1, n can be 0. Inside a MSI the following relations are valid Feature    1  –> n Components Component    1 –> m Features Component      1  –>  k Resources These relations express that one feature can install several components and features can share components between them. Every (meaningful) component will install at least one resource which means that its name (primary key to stay in database speak) does occur in some other table in the Component column as value which installs some resource. Lets make it clear with an example. We want to install with the feature MainFeature some files a registry key and a shortcut. We can then create components Comp1..3 which are referenced by the resources defined in the corresponding tables.   Feature Component Registry File Shortcuts MainFeature Comp1 RegistryKey1     MainFeature Comp2   File.txt   MainFeature Comp3   File2.txt Shortcut to File2.txt   It is illegal that the same resource is part of more than one component since this would break the refcount mechanism. Lets illustrate this:            Feature ComponentId Resource Reference Count Feature1 {1000-…} File1.txt 1 Feature2 {2000-….} File1.txt 1 The installation part works well but what happens when you uninstall Feature2? Component {20000…} gets a refcount of zero where MSI deletes all resources belonging to this component. In this case File1.txt will be deleted. But Feature1 still has another component {10000…} with a refcount of one which means that the file was deleted too early. You just have ruined your installation. To fix it you then need to click on the Repair button under Add/Remove Programs to let MSI reinstall any missing registry keys, files or shortcuts. The vigilant reader might has noticed that there is more in the Component table. Beside its name and GUID it has also an installation directory, attributes and a KeyPath. The KeyPath is a reference to a file or registry key which is used to detect if the component is already installed. This becomes important when you repair or uninstall a component. To find out if the component is already installed MSI checks if the registry key or file referenced by the KeyPath property does exist. When it does not exist it assumes that it was either already uninstalled (can lead to problems during uninstall) or that it is already installed and all is fine. Why is this detail so important? Lets put all files into one component. The KeyPath should be then one of the files of your component to check if it was installed or not. When your installation becomes corrupt because a file was deleted you cannot repair it with the Repair button under Add/Remove Programs because MSI checks the component integrity via the Resource referenced by its KeyPath. As long as you did not delete the KeyPath file MSI thinks all resources with your component are installed and never executes any repair action. You get even more trouble when you try to remove files during an upgrade (you cannot remove files during an update) from your super component which contains all files. The only way out and therefore best practice is to assign for every resource you want to install an extra component. This ensures painless updatability and repairs and you have much less effort to remove specific files during an upgrade. In effect you get this best practice relation Feature 1  –> n Components Component   1  –>  1 Resources MSI Component Rules Rule 1 – One component per resource Every resource you want to install (file, registry key, value, environment value, shortcut, directory, …) must get its own component which does never change between versions as long as the install location is the same. Penalty If you add more than one resources to a component you will break the repair capability of MSI because the KeyPath is used to check if the component needs repair. MSI ComponentId Files MSI 1.0 {1000} File1-5 MSI 2.0 {2000} File2-5 You want to remove File1 in version 2.0 of your MSI. Since you want to keep the other files you create a new component and add them there. MSI will delete all files if the component refcount of {1000} drops to zero. The files you want to keep are added to the new component {2000}. Ok that does work if your upgrade does uninstall the old MSI first. This will cause the refcount of all previously installed components to reach zero which means that all files present in version 1.0 are deleted. But there is a faster way to perform your upgrade by first installing your new MSI and then remove the old one.  If you choose this upgrade path then you will loose File1-5 after your upgrade and not only File1 as intended by your new component design.   Rule 2 – Only add, never remove resources from a component If you did follow rule 1 you will not need Rule 2. You can add in a patch more resources to one component. That is ok. But you can never remove anything from it. There are tricky ways around that but I do not want to encourage bad component design. Penalty Lets assume you have 2 MSI files which install under the same component one file   MSI1 MSI2 {1000} - ComponentId {1000} – ComponentId File1.txt File2.txt   When you install and uninstall both MSIs you will end up with an installation where either File1 or File2 will be left. Why? It seems that MSI does not store the resources associated with each component in its internal database. Instead Windows will simply query the MSI that is currently uninstalled for all resources belonging to this component. Since it will find only one file and not two it will only uninstall one file. That is the main reason why you never can remove resources from a component!   Rule 3 Never Remove A Component From an Update MSI. This is the same as if you change the GUID of a component by accident for your new update package. The resulting update package will not contain all components from the previously installed package. Penalty When you remove a component from a feature MSI will set the feature state during update to Advertised and log a warning message into its log file when you did enable MSI logging. SELMGR: ComponentId '{2DCEA1BA-3E27-E222-484C-D0D66AEA4F62}' is registered to feature 'xxxxxxx, but is not present in the Component table.  Removal of components from a feature is not supported! MSI (c) (24:44) [07:53:13:436]: SELMGR: Removal of a component from a feature is not supported Advertised means that MSI treats all components of this feature as not installed. As a consequence during uninstall nothing will be removed since it is not installed! This is not only bad because uninstall does no longer work but this feature will also not get the required patches. All other features which have followed component versioning rules for update packages will be updated but the one faulty feature will not. This results in very hard to find bugs why an update was only partially successful. Things got better with Windows Installer 4.5 but you cannot rely on that nobody will use an older installer. It is a good idea to add to your update msiexec call MSIENFORCEUPGRADECOMPONENTRULES=1 which will abort the installation if you did violate this rule.

  Read the article

< Previous Page | 1 2 3