Testing Play! and WebSockets

In: Christophe Hamerling|java|petalslink|WebService

7 Sep 2011

I spent one hour playing with the [Play Framework](http://playframework.org) and WebSockets in order to push some (SOAP) messages received on some Web services hosted by the Play application to the clients browser.

The result is really amazing: We can simply push these SOAP messages to clients in less than 100 lines of code. There are some problems with some messages lost due to some conception problems but which are not Play ones. In fact, the current prototype just send the messages to all the clients but what should be done is creating streams per client with some ID to identify them…

The source code is available on GitHub at [https://github.com/chamerling/play-soap-websockets](https://github.com/chamerling/play-soap-websockets)

A quick screen capture with SOAPUI sending messages to the Play! SOAP service. The Play application pushes the SOAP message to the clients (Two browsers).


Classé dans:Java, WebService Tagged: Java, Open source, petalslink, play!, playframework, poc, Web service, WebService, websockets

Invoke business services from service bus kernel

In: Christophe Hamerling|java|Petals ESB|Petals ESB|petalslink

1 Sep 2011

Let’s introduce what it means…

While Petals ESB does not provide any solution to invoke services directly from the kernel/component Java code, the DSB now provides a solution for that… By using this DSB feature, we can really use the power of service oriented architecture directly in our code. No more direct calls to services, you just need to call the client and say which service you want to invoke. The service bus will resolve the endpoint and route the message to the right place by using the right way/path. By using this way, you do not have to care if you need to speak with a SOAP service, a JMS queue or a REST service: Just call the service, the DSB will do the rest.

Now some code…

So, let’s have a look on the client code and first, let’s imagine that you have a web service which is bound to the service bus. Once bound, a DSB endpoint is available inside the DSB, and all messages which are sent to this endpoint will be forwarded to the final web service. One basic approach is to create a web service hosted by the service bus which ‘consumes’ the DSB service. As a result, a SOAP message sent to the DSB web service will be forwarded to the DSB endpoint which will forward it again to the final web service. Allright, but this is just for external SOAP clients and it is impossible to invoke anything firectly from the service bus kernel.
Now, let’s call the DSB endpoint from Java code… To put ourselves in a **real** case, let say that you are DSB kernel developer and that you want to say hello to the world (oh s*** really?) by using the *HelloWorldService* which is bound to the bus. Let’s code this client:

https://gist.github.com/1186183

So, just get a *org.petalslink.dsb.service.client.Client* from the *org.petalslink.dsb.service.client.ClientFactory* factory, create your *org.petalslink.dsb.service.client.Message* and send it by using the *sendReceive* method. That’s all… Let’s try to clarify what it means with a simple schema:

Hacker inside!

It looks so simple… I just deeply hacked the petals service bus kernel to provide such a thing. Why? Because the service bus is also deeply based on the JBI specification: Creating a client means that the client need to be able to receive responses and acts itself as a service on the service bus point of view. It is also built using all the component context stuff. No component context means no way to send/receive messages (component contexts are just created when JBI components are installed).
So it is really important to release the client when you do not use it anymore: There are tons of listeners and threads in the different layers which are just used to receive messages. If you do not release the client, there will be unused resources for a long time.


Classé dans:Java, PEtALS Tagged: Client (computing), Java, Petals ESB, petalslink, Programming, Service-oriented architecture, soap, Web service

Petals Studio 1.2 RC2

In: Uncategorized

19 Aug 2011

Petals Studio RC2 is available ! You can download it below.
This should be the last version release candidate before stable 1.2. Please tell us any problem you encounter.

Unknownname
Petals-Studio--1.2.0--linux.gtk.x86.zip 16-Aug-2011 14:56 151M
Unknownname
Petals-Studio--1.2.0--linux.gtk.x86_64.zip 16-Aug-2011 14:56 151M
Unknownname
Petals-Studio--1.2.0--macosx.cocoa.x86_64.zip 17-Aug-2011 15:45 151M
Unknownname
Petals-Studio--1.2.0--win32.win32.x86.zip 16-Aug-2011 14:56 151M
Unknownname
Petals-Studio--1.2.0--win32.win32.x86_64.zip 16-Aug-2011 14:57 151M

Release note:

Bug

Improvement Request

  • [PETALSSTUD-20] - Have real use case categories in the SU wizards
  • [PETALSSTUD-22] - Validate the referenced classes, files and XPath expressions
  • [PETALSSTUD-40] - The JBI builder should validate the consumes' MEP and operation
  • [PETALSSTUD-49] - Make the SU wizards lighter
  • [PETALSSTUD-54] - Change the Java <=> WSDL utilities
  • [PETALSSTUD-66] - The DnD of a Petals end-point on a BPEL diagram should open a dialog
  • [PETALSSTUD-67] - Create an EIP designer
  • [PETALSSTUD-69] - Relative import URIs should be located in the "jbi" directory
  • [PETALSSTUD-88] - Update to SQL WSDL template version 1.2
  • [PETALSSTUD-89] - Change the UI in the first page of the EJB wizard
  • [PETALSSTUD-94] - Add a preference to determine whether jbi.xml should be formatted in JBI editors
  • [PETALSSTUD-95] - Display component operations in consumers with no WSDL
  • [PETALSSTUD-96] - Improve XSLT and Validation WSDL
  • [PETALSSTUD-99] - The Java nature is ambiguous
  • [PETALSSTUD-101] - Show the target component when creating a consumer
  • [PETALSSTUD-102] - Change the way registration information are sent
  • [PETALSSTUD-111] - Better recognition of component projects
  • [PETALSSTUD-116] - SA validation error with closed SU projects
  • [PETALSSTUD-120] - Change the notion of croquis
  • [PETALSSTUD-134] - Show Java packages in the Petals projects view
  • [PETALSSTUD-137] - Replace the BPEL croquis by an export wizard
  • [PETALSSTUD-139] - Replace "jbi.xml" tab title when editing a JBI by a more meaningful name, such as the SU name
  • [PETALSSTUD-141] - Add a shortcut "Configure Build Path" on Java projects in the Petals projects view
  • [PETALSSTUD-143] - Component type != Component ID
  • [PETALSSTUD-144] - Be able to change the end-point name in provider SU
  • [PETALSSTUD-145] - Be able to change the service name in provider SU
  • [PETALSSTUD-153] - EIP croquis: add a warning instead of an error for not set operations
  • [PETALSSTUD-176] - Change the File Transfer wizard

New Feature

Task

Permalink | Leave a comment  »

GMF Tooling is back in the train

In: Eclipse

17 Aug 2011

Unfortuantely, GMF Tooling did not have enough resources to get in the latest Indigo release traine.

GMF-Tooling and Indigo...

However, this was just an exception: GMF Tooling is already back on the Juno train! In order to be more reactive to the release train requirement, GMF Tooling moved its build to Tycho, making the build system quite easy to maintain, and release train rythm much easier to follow.

Thanks to Tycho, GMF-Tooling is already in the train

And you can see it here:alrea

GMF Tooling in Juno

Then you won’t have to search a lot in order to get GMF Tooling in Juno.


Jouons avec WebServiceProvider…

In: Christophe Hamerling|cxf|java|jaxws|petalslink|WebService

12 Aug 2011

Il y a des jours où exposer ses classes annotés avec @WebService n’est pas satisfaisant…
Pour moi ce jour c’est aujourd’hui: Il m’est impossible de marshaller mes beans en document DOM à cause d’un contexte JAXB tordu et d’une API qui ne prend que du DOM en entrée (OK bon ça c’est nul mais c’est pas de moi…). Qu’a cela ne tienne, il est temps d’utiliser les WebServiceProvider puisque ils vont me permettre de directement récupérer mon message SOAP sous forme de document… Un peu moins straight forward comme approche mais qui peut convenir dans certains cas. Comme les exemples ne courent pas le Web, regardons ce que l’on peut faire pour s’en sortir…

(Tout le code source de cet article est disponible sur Github : http://github.com/chamerling/chamerling.org-samples/tree/master/cxf-serviceprovider-072011)

Une première solution simple est d’implémenter javax.xml.ws.Provider, de rajouter deux/trois annotations et le tour est quasiment joué:

package org.chamerling.blog.cxf.serviceprovider;

import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceProvider;

/**
* @author chamerling
*
*/
@WebServiceProvider
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class SimpleServiceProvider implements Provider {

/*
* (non-Javadoc)
*
* @see javax.xml.ws.Provider#invoke(java.lang.Object)
*/
@Override
public SOAPMessage invoke(SOAPMessage in) {
return null;
}
}

Reste à l’exposer avec CXF en utilisant org.apache.cxf.jaxws.JaxWsServerFactoryBean. Cette approche simpliste a le mérite de marcher, il ne reste plus qu’a manipuler les SOAPMessage dans l’implémentation de la méthode invoke.

Besoin de l’opération qui est appelée? Ajoutons javax.xml.ws.WebServiceContext en tant que javax.annotation.Resource. Ce contexte sera automatiquement rempli pour nous par CXF et accessible dans le corps de la méthode invoke. Par exemple, on peut travailler de la sorte:

/**
 *
 */
package org.chamerling.blog.cxf.serviceprovider;

import javax.annotation.Resource;
import javax.xml.namespace.QName;
import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.WebServiceProvider;
import javax.xml.ws.handler.MessageContext;

/**
 * @author chamerling
 *
 */
@WebServiceProvider
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class SimpleServiceProvider implements Provider {

	@Resource
	WebServiceContext wsContext;

	/*
	 * (non-Javadoc)
	 *
	 * @see javax.xml.ws.Provider#invoke(java.lang.Object)
	 */
	@Override
	public SOAPMessage invoke(SOAPMessage in) {
		System.out.println("Operation : " + getOperation());
		System.out.println("Message In :");
		try {
			in.writeTo(System.out);
		} catch (Exception e) {
			// bad
		}
		System.out.println();
		return null;
	}

	private QName getOperation() {
		QName result = null;
		if (wsContext != null && wsContext.getMessageContext() != null) {
			Object o = wsContext.getMessageContext().get(
					MessageContext.WSDL_OPERATION);
			if (o != null && o instanceof QName) {
				result = (QName) o;
			}
		}
		return result;
	}
}

Et invoquer le service:

package org.chamerling.blog.cxf.serviceprovider;

import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;

import junit.framework.TestCase;

/**
 * @author chamerling
 *
 */
public class SimpleServiceTest extends TestCase {

	public void testExpose() throws Exception {
		String url = "http://localhost:9999/foo/bar/SimpleService";
		final JaxWsServerFactoryBean ssf = new JaxWsServerFactoryBean();
		ssf.setAddress(url);
		ssf.setServiceBean(new SimpleServiceProvider());
		ssf.create();

		HelloService client = getClient(url);
		client.sayHello("Rock N Roll!");
	}

	/**
	 * @param url
	 * @return
	 */
	private HelloService getClient(String url) {
		JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
		factory.setAddress(url);
		factory.setServiceClass(HelloService.class);
		Object client = factory.create();
		return HelloService.class.cast(client);
	}
}

Dans ce cas, on a une opération affichée qui est {http://serviceprovider.cxf.blog.chamerling.org/}invoke et le message SOAP

Rock N Roll!

Pas très convaincant pour l’opération avec cette approche… Le mieux est de pousser un peu plus loin et partir du contrat de service (WSDL) de notre Provider. CXF permet de le spécifier via ses factories lors de la construction du service. Cette utilisation plus avancée est détaillée en partant de org.chamerling.blog.cxf.serviceprovider.CXFExposer. L’approche utilisée dans CXFExposer permet aussi de cacher toute la tambouille JAXWS à l’utilisateur, au final il a besoin d’implementer seulement org.chamerling.blog.cxf.serviceprovider.Service

package org.chamerling.blog.cxf.serviceprovider;

import javax.xml.namespace.QName;

import org.w3c.dom.Document;

/**
 * @author chamerling
 *
 */
public interface Service {

    /**
     * Get the WSDL description
     *
     * @return
     */
    String getWSDLURL();

    /**
     * Get the service URL ie where to publish it...
     *
     * @return
     */
    String getURL();

    QName getEndpoint();

    QName getInterface();

    QName getService();

    /**
     * Invoke the service
     *
     * @param request
     * @param action
     */
    Document invoke(Document in, QName operation) throws ServiceException;

}


Classé dans:Java, WebService Tagged: Annotation, Apache CXF, Application programming interface, cxf, Java, Java Architecture for XML Binding, javax.xml.ws, jaxws, petalslink, Web service, webserviceprovider, XML

Petals ESB 3.1.3

In: Uncategorized

29 Jul 2011

Petals ESB 3.1.3 maintenance version was just released. It includes both 3.1.2 and 3.1.3  container fixes, and a SE-POJO maintenance version.

Download: Petals ESB 3.1.3 - Petals-SE-POJO 2.2.5

Release note :

Bug

  • [PETALSESBCONT-18] - The container is always on State: UNKNOWN
  • [PETALSESBCONT-28] - The MIME "application / zip" check is too restrictive when deploying a JBI artefact
  • [PETALSESBCONT-70] - A META tag is added when a HTML message is set as output message content
  • [PETALSESBCONT-83] - Lack of robustness if we play with JMX
  • [PETALSESBCONT-92] - Error creating new org.ow2.petals.registry.core.repository.bo.Endpoint
  • [PETALSESBCONT-93] - Two versions of petals-registry-api are packaged
  • [PETALSESBCONT-98] - The JMX API InstallationServiceMBean.loadInstaller is not JBI compliant when the installer does not exist
  • [PETALSESBCONT-100] - Successful creation of... 2 EPs with same name !
  • [PETALSESBCONT-105] - WSDL are transmitted at each request
  • [PETALSESBCONT-117] - Use of an unsynchronized DateFormat
  • [PETALSESBCONT-127] - Error message when using the autoloader to install a component
  • [PETALSESBCONT-131] - Error restart Petals ESB after to have installed a faulty component
  • [PETALSESBCONT-136] - Unable to install a component from a readonly file-based JBI archive
  • [PETALSESBCONT-141] - Some HQL requests of the registry don't use named parameter
  • [PETALSESBCONT-142] - Unable to uninstall a component using Ant task after a failed installation
  • [PETALSESBCONT-143] - The error message of Ant task 'jbi-uninstall-component' is not clear when the component is not installed
  • [PETALSESBCONT-144] - The Ant task does not manage correctly configuration attributes when set by configuration file and nested element
  • [PETALSESBCONT-145] - No error occurs stopping a component in state 'shutdown'
  • [PETALSESBCONT-146] - A suite of life cycle changes results in end-point leak
  • [PETALSESBCONT-147] - The error message of the Ant task 'jbi-install-...' or 'jbi-deploy-...' is not clear when the attribute 'file' is empty
  • [PETALSESBCONT-149] - The error message of the Ant task 'petals-configure-...' is not clear when the attribute 'file' or 'outputFile' is empty
  • [PETALSESBCONT-151] - The Ant task 'petals-configure-...' does not delete its temporary files
  • [PETALSESBCONT-161] - Unable to re-install a component: "Component already registered"
  • [PETALSESBCONT-164] - A NumberFormatException occurs when component configuration parameters are set with invalid values
  • [PETALSSEPOJO-10] - Unable to configure the component attribute 'properties-file'
  • [PETALSSEPOJO-11] - Unable to configure the component attribute 'processor-max-pool-size'

Improvement Request

  • [PETALSESBCONT-45] - A trace MUST be logged about recovering of shared libraries
  • [PETALSESBCONT-96] - In the server.properties, correct and improve comment about the parameter 'petals.repository.path'
  • [PETALSESBCONT-103] - Error about opening zip file when loading a new installer from an HTTP URL associated to an HTML page
  • [PETALSESBCONT-107] - Instanciation number of DOM document builder can be optimized
  • [PETALSESBCONT-108] - Instanciation number of transformer factory can be optimized
  • [PETALSESBCONT-109] - Fix and improve inheritance between JBIServiceEndpointImpl and ServiceEndpointImpl
  • [PETALSESBCONT-112] - Exchange forker can be improved using an entry set instead of a key set
  • [PETALSESBCONT-116] - Prefer to use ConcurrentHasMap instead of Collections.synchronizedMap(...)
  • [PETALSESBCONT-118] - Incorrect error message when loading a new installer from a HTTP URL pointing on something that is not a ZIP file
  • [PETALSESBCONT-119] - Incorrect error message when loading a new installer from an inexisting HTTP URL
  • [PETALSESBCONT-120] - Don't use utility method of the registry implementation
  • [PETALSESBCONT-125] - Use preparedStatement instead of simple statement to improve performance and security
  • [PETALSESBCONT-128] - The recovering thread pool should be sizable
  • [PETALSESBCONT-130] - Add default option -Djava.net.preferIPv4Stack=true when starting petals
  • [PETALSESBCONT-132] - Use String Reader instead of StringBufferInputStream in XmlUtil
  • [PETALSESBCONT-134] - The persistence service should use batch of SQL commands to insert array of the same data
  • [PETALSESBCONT-135] - The persistence service should use fetch-array with ResultSet to retrieve data of a request returning several lines
  • [PETALSESBCONT-138] - The logged trace about installer loading should be different in both installer loading methods
  • [PETALSESBCONT-148] - The error message of Ant tasks managing component lifecycle is not clear when the component identifier is empty
  • [PETALSESBCONT-150] - No error is thrown when using the Ant task 'petals-configure-...' with an output archive that already exists
  • [PETALSESBCONT-155] - The error message of Ant tasks uninstalling a shared library is not clear when the shared library identifier is empty
  • [PETALSESBCONT-158] - Add a MBean operation to synchronize the registry

 

Permalink | Leave a comment  »

Petals BPM

In: Christophe Hamerling|java|opensource|Petals ESB|petalslink

25 Jul 2011

Petals BPM (previously Geasy BPMN Editor) is an open source, web-based BPMN 2.0 editor developped with GWT.

Petals BPM

Petals BPM

Tout est dit en une seule phrase… Petals BPM est un des produits que nous sommes en train de développer activement au Labs. Cette Web application open source, développée en GWT permet de créer et d’éditer des process BPMN 2.0, d’importer et d’exporter en BPMN 2.0, XPDL, mais aussi exporter vers un fichier BPEL 2.0.

Beaucoup de choses à venir autour de ce produit, j’espère assez rapidement. Ca sera bien sur décrit ici.


Classé dans:PetalsLink Tagged: Business process management, Business Process Modeling Notation, Java, opensource, PEtALS, petalslink, Web application

PetalsLink DSB expliqué

In: Christophe Hamerling|jaxws|jbi|opensource|Petals ESB|petalslink|soa

25 Jul 2011

Dédramatiser le Bus de Service que je développe depuis 2 ou 3 ans, tel est le but de ces quelques slides que j’ai présenté à l’équipe R&D la semaine dernière…

 


Classé dans:Uncategorized Tagged: esb, jaxws, jbi, Open source, opensource, PEtALS, petalslink, Service-oriented architecture, SOA

PLAY Project Video

In: Christophe Hamerling|eda|opensource|Petals ESB|petalslink|soa|WebService

12 Jul 2011

Le projet PLAY ne déroge pas à la règle de la vidéo explicative et voici donc la première expliquant un scénario d’utilisation avec le fameux Paul…


Classé dans:Play Tagged: eda, esb, event, marketplace, Open source, opensource, PEtALS, petalslink, Service-oriented architecture, SOA, video, WebService

Back on Grenoble Demo Camp

In: Eclipse

1 Jul 2011

The first Eclipse DemoCamp in Grenoble took place on Tuesday. With 25 attendees, it was a very good opportunity to meet people who are well-known in the Eclipse community, but also some new people who start using Eclipse to develop plugins to resolve very interesting use-cases.

Here is a small summary of the event (Thanks to Adrian for the pictures).

Agenda

First, Adrian welcomed us at the Xerox Research Europe castle. A very nice place!

View Larger Map

Then the event was made of 2 parts.

Eclipse projects

The first one consisted in presenting new stuff at Eclipse. Of course, Indigo, but also to give news about some other projects.

I started by giving some insight about “What’s new in Indigo?” to the audience, and then to present a demo of WindowBuilder. I hope I convinced almost everybody to use this project I personally love!

Me presenting the Runtime Packaging Project

Then my former dear colleague Aurélien prensented and demonstrated to the audience how they could leverage the Memory Analyzer tools to resolve memory issues in there applications. Slides are here.

"You need a snapshot of your memory"

Next, Vincent , my new colleague since I joined PetalsLink, presented 2 projects of the SOA landscape at Eclipse: the SCA editor, and the BPEL designer, which is coming back to life at Eclipse and is going to join the SOA top-level project very soon.

Vincent explaining what is SCA and demo'ing the editor

Aurélien and I closed the first part of the event by presenting an overview of the Modeling stuff at Eclipse. I liked presenting it, so that I submitted a presentation about Modeling at Eclipse to Devoxx, if it gets accepted, it will include more demonstrations and will be improved thanks to the feedback people gave us during the DemoCamp!

It was the time for a break! Adrian came with beverages and very good food such as macaroons. I love macaroons. Unfortunately, there is no picture of this break, but people really looked satisfied of speaking one and other, and of drinking and eating.

Case studies

The second part of the DemoCamp was dedicated to case-studies: showing to people what people do with Eclipse and how they achieve their goals.

First one to present a case-study was Aurélien (again! ;) who highlighted the main Modeling features of the “Best Eclipse Modeling Application” Bonita Open Solution, and who explained what are the tricks used by Bonita to customize GMF Editors. See slides.

Aurélien and Bonita Open Solution

Next, Marc Dutoo (my first Eclipse mentor who made me a committer on JWT while I was a trainee) from Open Wide presented us the EasySOA research project, in which one the leverage several Eclipse SOA technologies to make consumption of services easier.

Marc explaining the goals of EasySOA

The following presentation was a presentation of Xeproc, a model that they use at Xerox to process documents. Thierry Jacquin explained us the use-case of Xeproc, which they use to discover how documents are structured and extract some meta-informations from them, and Adrian explained us how he plans to make it interacting with several SOA projects at Eclipse, using Mangrove.

Adrian explaining how Mangrove can be used as a pivot for all SOA technologies

Both last presentations were proposed by guys from IsandlaTech. and came to present solution for their daily work with Eclipse. Olivier Gattaz started by explaining us that they use a lot the spellchecking in Eclipse, mainly to write documentation; and started by telling us what are the limit of current spellchecker in Eclipse for his use-cases. Then he introduced us the Hunspell4Eclipse project, available on Eclipse MarketPlace, that provides an implementation of spell-checking in Eclipse that is the same as in Firefox or Libre Office. It was very interesting, and doing this work, Olivier discovered some issues in the JDT editor that I hope will be fixed one day! (slides)

Olivier convincing us to use Hunspell4Eclipse

And the last speaker was Thomas Calmant, who demonstrated us the ReST Editor, which is a very smart (maybe the smartest) editor for reStructuredText, a language to create documentation widely used in the Python community. This editor is full of very nice features that makes editing of reStructuredText much more comfortable that with a basic text editor. Click here for the slides!

Lessons I learnt

  • Eclipse DemoCamp are cool events to meet people
  • Eclipse DemoCamp are cool events to discover new Eclipse use case
  • Eclipse DemoCamp are cool events to be a speaker
  • Eclipse DemoCamp are cool useful for the life of the community
  • Modeling is not an easy thing to present, but it is quite interesting to do it. Everyone likes at least one thing in the Modeling landscape at Eclipse.
  • Xerox offices looks like an holiday center ;)
  • It is not always for people who develop plugins to find how to get an influence on big Eclipse projects. People who have been involved for a while do know that everything starts with participating in forums and opening bugs, but it is not so obvious for newcomers. It is our role as member of the community to guide them, and to recruit them in the community. DemoCamps are perfect events for that.
  • According to the audience of this DemoCamp, a lot of people really like GMF, but find this very difficult to use it. The documentation is very weak compared to the power of the project. That’s why I spent some time refactoring the Tutorial. The objective is to make GMF an easy-to-use project. You feedback is welcome.

Thanks to everyone who participated to this event! See you next year (and why not before) !


Welcome

  • No comments

Archives

Categories

Latest Tweets

Page 5 of 32« First...34567102030...Last »


Copyright © 2007 - Blog Petals planet - is proudly powered by WordPress | Log in