[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1322?page=com.atlassian.jira.plugin... ]
Ron Sigal closed JBREM-1322.
----------------------------
Resolution: Out of Date
> Cannot set up serverBindAddress for secondarySocket in bisocket transport
> -------------------------------------------------------------------------
>
> Key: JBREM-1322
> URL: https://issues.jboss.org/browse/JBREM-1322
> Project: JBoss Remoting
> Issue Type: Bug
> Components: transport
> Affects Versions: 2.5.4.SP4
> Reporter: Igor Kostromin
> Assignee: Ron Sigal
>
> Using IS_CALLBACK_SERVER = true.
> In BisocketClientInvoker.java:355
> InvokerLocator getSecondaryLocator() throws Throwable {
> ...
> 355: Object o = invoke(r);
> ...
> }
> It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
> Object o = invoke(r);
> // DZ: patch to use original server address for creating secondary connection
> // instead of address retrieved from server (because server will return jboss bind address
> // that can be local address, inaccessible from client)
> InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace(
> (( InvokerLocator ) o).getHost(), this.getLocator().getHost() )
> );
> log.debug("secondary locator: " + o);
> log.debug("patched secondary locator: " + patchedLocator);
> return patchedLocator;
> and rebuild jboss-remoting project.
> For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBREM-1289) CLONE [JBREM-1288] - StreamServer for in-jvm connection should create a LocalServerInvoker
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1289?page=com.atlassian.jira.plugin... ]
Ron Sigal closed JBREM-1289.
----------------------------
Resolution: Out of Date
> CLONE [JBREM-1288] - StreamServer for in-jvm connection should create a LocalServerInvoker
> ------------------------------------------------------------------------------------------
>
> Key: JBREM-1289
> URL: https://issues.jboss.org/browse/JBREM-1289
> Project: JBoss Remoting
> Issue Type: Bug
> Affects Versions: 2.2.4
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 2.2.4.SP1
>
>
> When the org.jboss.remoting.Client method
> public Object invoke(InputStream inputStream, Object param) throws Throwable;
> or one of its variants is called, it calls new StreamServer(inputStream), which creates an org.jboss.remoting.transport.Connector to serve the contents of the InputStream. To determine the transport to be used, StreamServer looks for a system property "remoting.stream.transport", and, if it doesn't exist, it uses "socket" by default. However, if the InputStream is being sent to a server in the same JVM, the "local" transport should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBSER-113) Caching of replaced objects doesn't conform to Java serialization specification
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBSER-113?page=com.atlassian.jira.plugin.... ]
Ron Sigal closed JBSER-113.
---------------------------
Resolution: Out of Date
> Caching of replaced objects doesn't conform to Java serialization specification
> -------------------------------------------------------------------------------
>
> Key: JBSER-113
> URL: https://issues.jboss.org/browse/JBSER-113
> Project: JBoss Serialization
> Issue Type: Bug
> Affects Versions: 1.0.3 GA
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 1.1.0 Beta
>
>
> The Java serialization spec gives the following steps in serialization:
> 4. If the object has been previously replaced, as described in Step 8, write the handle of the replacement to the stream and writeObject returns.
> ...
> 8. a. ....
> b. ...
> If the original object was replaced by either one or both steps above, the mapping from the original object to the replacement is recorded for later use in Step 4. Then, Steps 3 through 7 are repeated on the new object.
> But JBossSerialization does this:
> * Apply all the replacements
> * If the replacement object has already been written, write its "handle".
> I used to think this was just an efficiency issue (why do the replacement code on an object the second time it gets processed), but one of the JBossMarshalling tests shows that there is an actual semantic difference:
> ArrayList<Object> testList = new ArrayList<Object>();
> testList = Collections.unmodifiableList(testList);
> marshaller.writeObject(testList);
> marshaller.writeObject(testList);
> assertSame(unmarshaller.readObject(), unmarshaller.readObject());
> The assertion will fail with JBossSerialization because Collections.unmodifiableList() returns an instance of
> static class UnmodifiableRandomAccessList<E> extends UnmodifiableList<E> implements RandomAccess {
> private Object writeReplace() {
> return new UnmodifiableList<E>(list);
> }
> }
> JBossSerialization applies UnmodifiableRandomAccessList.writeReplace() during each call to marshaller.writeObject(), so two different copies of testList get written. But in Java serialization, the second call would see that the object has already been written and a handle would get written.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBSER-112) Adjust JBossSerialization to support JBossMarshalling
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBSER-112?page=com.atlassian.jira.plugin.... ]
Ron Sigal reopened JBSER-112:
-----------------------------
> Adjust JBossSerialization to support JBossMarshalling
> -----------------------------------------------------
>
> Key: JBSER-112
> URL: https://issues.jboss.org/browse/JBSER-112
> Project: JBoss Serialization
> Issue Type: Feature Request
> Affects Versions: 1.0.3 GA
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 1.1.0 Beta
>
>
> The JBossMarshalling project presents a unitied API for marshalling and unmarshalling objects. It supports a number of pluggable facilities, including object and class resolvers, externalizers, and so forth. There is a native implementation (River) and an implementation that is compatible with standard Java serialization. A number of changes are necessary to support an implementation this is based on, and compatible with, JBossSerialization.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBSER-112) Adjust JBossSerialization to support JBossMarshalling
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBSER-112?page=com.atlassian.jira.plugin.... ]
Ron Sigal closed JBSER-112.
---------------------------
Resolution: Out of Date
> Adjust JBossSerialization to support JBossMarshalling
> -----------------------------------------------------
>
> Key: JBSER-112
> URL: https://issues.jboss.org/browse/JBSER-112
> Project: JBoss Serialization
> Issue Type: Feature Request
> Affects Versions: 1.0.3 GA
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 1.1.0 Beta
>
>
> The JBossMarshalling project presents a unitied API for marshalling and unmarshalling objects. It supports a number of pluggable facilities, including object and class resolvers, externalizers, and so forth. There is a native implementation (River) and an implementation that is compatible with standard Java serialization. A number of changes are necessary to support an implementation this is based on, and compatible with, JBossSerialization.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBSER-114) Object replacement and resolution doesn't conform to Java serialization
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBSER-114?page=com.atlassian.jira.plugin.... ]
Ron Sigal closed JBSER-114.
---------------------------
Resolution: Out of Date
> Object replacement and resolution doesn't conform to Java serialization
> -----------------------------------------------------------------------
>
> Key: JBSER-114
> URL: https://issues.jboss.org/browse/JBSER-114
> Project: JBoss Serialization
> Issue Type: Bug
> Affects Versions: 1.0.3 GA
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 1.1.0 Beta
>
> Attachments: ClebertOutputSample.java
>
>
> There are two ways in which object replacement and resolution in JBossSerialization doesn't conform to Java serialization.
> This discussion applies to JBossSerialization as it currently exists on trunk.
> ===============================================================================
> First divergence.
> According to Section 3 "Object Input Classes" (http://java.sun.com/javase/6/docs/platform/serialization/spec/input.html) of the Java Object Serialization Specification, the sequence of replacements while writing an object is:
> 1. if the class has a writeReplace() method, that method is called, and then
> 2. if replacement has been enabled by calling ObjectOutputStream.enableReplaceObject(), then ObjectOutputStream.replaceObject() is called.
> [NOTE that the implementation in java.io.ObjectOutputStream.writeObject0() doesn't seem to conform to the above algorithm:
> for (;;) {
> // REMIND: skip this check for strings/arrays?
> Class repCl;
> desc = ObjectStreamClass.lookup(cl, true);
> if (!desc.hasWriteReplaceMethod() ||
> (obj = desc.invokeWriteReplace(obj)) == null ||
> (repCl = obj.getClass()) == cl)
> {
> break;
> }
> cl = repCl;
> }
> if (enableReplace) {
> Object rep = replaceObject(obj);
> if (rep != obj && rep != null) {
> cl = rep.getClass();
> desc = ObjectStreamClass.lookup(cl, true);
> }
> obj = rep;
> }
> In particular, the for loop seems to be divergent from the semantics.]
>
> On the other hand, JBossSerialization does the following:
> 1. if replacement has been enabled, call ObjectOutputStream.replaceObject() [In DataContainer.DataContainerDirectOutput.writeObject()]
> 2. if the class has a writeReplace() method then keep applying writeReplace() until it returns either (1) null, (2) the object to which it was applied, (3) an object of the same class as the object to which it was applied, or (4) an immutable value. If (1) or (4), write new value and return.
> 3. if replacement has been enabled, call ObjectOutputStream.replaceObject().
> 4. *GOTO* 2.
> While reading an object in Java serialization, the sequence of replacements is
> 1. if the class has a readResolve() method, that method is called, and then
> 2. if replacement has been enabled by calling ObjectInputStream.enableResolveObject(), then ObjectInputStream.resolveObject () is called.
> On the other hand, JBossSerialization does the following:
> 1. if replacement has been enabled by calling ObjectInputStream.enableResolveObject(), then ObjectInputStream.resolveObject () is called.
> 2. if the class has a readResolve() method, that method is called, and then
> 3. if replacement has been enabled by calling ObjectInputStream.enableResolveObject(), then ObjectInputStream.resolveObject () is called.
> ===============================================================================
> Second divergence.
> The Java serialization spec gives the following steps in serialization:
> 4. If the object has been previously replaced, as described in Step 8, write the handle of the replacement to the stream and writeObject() returns.
> ...
> 8. a. ....
> b. ...
> If the original object was replaced by either one or both steps above, the mapping from the original object to the replacement is recorded for later use in Step 4. Then, Steps 3 through 7 are repeated on the new object.
> But JBossSerialization does this:
> * Apply all the replacements
> * If the replacement object has already been written, write its "handle".
>
> The following test will fail in JBossSerialization:
> ArrayList<Object> testList = new ArrayList<Object>();
> testList = Collections.unmodifiableList(testList);
> marshaller.writeObject(testList);
> marshaller.writeObject(testList);
> assertSame(unmarshaller.readObject(), unmarshaller.readObject());
> The assertion will fail because Collections.unmodifiableList() returns an instance of
> static class UnmodifiableRandomAccessList<E> extends UnmodifiableList<E> implements RandomAccess {
> private Object writeReplace() {
> return new UnmodifiableList<E>(list);
> }
> }
>
> JBossSerialization applies UnmodifiableRandomAccessList.writeReplace() during each call to marshaller.writeObject(), so two different copies of testList get written. But in Java serialization, the second call would see that the object has already been written and a handle would get written.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBSER-112) Adjust JBossSerialization to support JBossMarshalling
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBSER-112?page=com.atlassian.jira.plugin.... ]
Ron Sigal closed JBSER-112.
---------------------------
Resolution: Done
I think this once can go.
> Adjust JBossSerialization to support JBossMarshalling
> -----------------------------------------------------
>
> Key: JBSER-112
> URL: https://issues.jboss.org/browse/JBSER-112
> Project: JBoss Serialization
> Issue Type: Feature Request
> Affects Versions: 1.0.3 GA
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 1.1.0 Beta
>
>
> The JBossMarshalling project presents a unitied API for marshalling and unmarshalling objects. It supports a number of pluggable facilities, including object and class resolvers, externalizers, and so forth. There is a native implementation (River) and an implementation that is compatible with standard Java serialization. A number of changes are necessary to support an implementation this is based on, and compatible with, JBossSerialization.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10616) ContextResolver doesn't work
by George Trudeau (JIRA)
George Trudeau created WFLY-10616:
-------------------------------------
Summary: ContextResolver doesn't work
Key: WFLY-10616
URL: https://issues.jboss.org/browse/WFLY-10616
Project: WildFly
Issue Type: Bug
Components: REST
Affects Versions: 13.0.0.Final
Reporter: George Trudeau
Assignee: Alessio Soldano
I have a simple ContextResolver to set Date serialization format for my JAX-RS service, it works on 12.0.0.Final but it doesn't anymore on 13.0.0.Final :
{code:java}
@Provider
public class DateResolver implements ContextResolver<ObjectMapper>
{
private final ObjectMapper mapper;
public DateResolver()
{
mapper = new ObjectMapper();
mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"));
mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
}
@Override
public ObjectMapper getContext(Class<?> type) { return mapper; }
}
{code}
The {{getContext}} method isn't called on 13.0.0.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFWIP-53) Differences in ORM exception handling in 5.1 vs 5.3
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFWIP-53?page=com.atlassian.jira.plugin.s... ]
Gail Badner commented on WFWIP-53:
----------------------------------
Addition of an option for reverting to 5.1 exception handling is covered by:
https://hibernate.atlassian.net/browse/HHH-12666
> Differences in ORM exception handling in 5.1 vs 5.3
> ---------------------------------------------------
>
> Key: WFWIP-53
> URL: https://issues.jboss.org/browse/WFWIP-53
> Project: WildFly WIP
> Issue Type: Bug
> Components: JPA
> Reporter: Martin Simka
> Assignee: Gail Badner
> Priority: Blocker
>
> I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped by {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing list but without any outcome.
> http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
> {quote}
> I've been looking at differences in Hibernate exception handling for
> applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
> 5.3.
> As you know, exception handling changed in 5.2 when hibernate-entitymanager
> was merged into hibernate-core. This change is documented in the 5.2
> migration guide. [1]
> Here is the relevant text:
> "org.hibernate.HibernateException now extends
> javax.persistence.PersistenceExceptions.
> Hibernate methods that "override" methods from their JPA counterparts now
> will also throw various JDK defined RuntimeExceptions (such as
> IllegalArgumentException, IllegalStateException, etc) as required by the
> JPA contract."
> While digging into this, I see that a HibernateException thrown when using
> 5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
> (or a subclass), IllegalArgumentException, or IllegalStateException,
> depending on the particular operation being performed when the
> HibernateException is thrown.
> The reason why the exceptions may be wrapped or unwrapped is because
> Hibernate converts exceptions (via
> AbstractSharedSessionContract#exceptionConverter)
> for JPA operations which may wrap the HibernateException or throw a
> different exception. Hibernate does not convert exceptions from strictly
> "native" operations, so those exceptions remain unwrapped.
> Here are a couple of examples to illustrate:
> 1) A HibernateException (org.hibernate.TransientObjectException) was thrown
> in 5.1. In 5.3, the same condition can result in
> org.hibernate.TransientObjectException
> that is either unwrapped, or wrapped by IllegalStateException. I've pushed
> a test to my fork to illustrate. [2]
> Thrown during Session#save, #saveOrUpdate
> In 5.1: org.hibernate.TransientObjectException (unwrapped)
> In 5.3: org.hibernate.TransientObjectException (unwrapped)
> Thrown during Session#persist, #merge, #flush
> In 5.1, org.hibernate.TransientObjectException (unwrapped)
> In 5.3, org.hibernate.TransientObjectException wrapped by
> IllegalStateException
> 2) A HibernateException thrown when using 5.1 may be wrapped by a
> PersistenceException, even though HibernateException already extends
> PersistenceException.
> For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/test/java/org/hibernate/test/tm/
> TransactionTimeoutTest.java#L60-L82
> The exception thrown by the test indicates that the transaction timed out.
> This exception is important enough that an application might retry the
> operation, or at least log for future investigation.
> Thrown during Session#persist (or when changed to use Session#merge or
> Session#flush):
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
> PersistenceException
> Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException (unwrapped)
> Similarly, by adding some logging, I see that HibernateException objects
> can be wrapped by PersistenceException when running the 5.3 hibernate-core
> unit tests. Depending on the context, I see that some of the following
> exceptions can be wrapped or unwrapped.
> org.hibernate.exception.ConstraintViolationException
> org.hibernate.exception.DataException
> org.hibernate.exception.GenericJDBCException
> org.hibernate.exception.SQLGrammarException
> org.hibernate.id.IdentifierGenerationException
> org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
> org.hibernate.PersistentObjectException
> org.hibernate.PropertyAccessException
> org.hibernate.PropertyValueException
> org.hibernate.TransactionException
> You can see an example using
> org.hibernate.exception.ConstraintViolationException
> at [3].
> In order to deal with these differences, an application could change the
> following (which was appropriate for 5.1):
> try {
> ...
> }
> catch (HibernateException ex) {
> procressHibernateException( ex );
> }
> to the following for 5.3:
> try {
> ...
> }
> catch (PersistenceException | IllegalStateException |
> IllegalArgumentException ex) {
> if ( HibernateException.class.isInstance( ex ) ) {
> handleHibernateException( (HibernateException) ex );
> }
> else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
> handleHibernateException( (HibernateException) ex.getCause() );
> }
> }
> IMO, it's a little clumsy having to deal with both wrapped and unwrapped
> exceptions. It would be better if exceptions were consistently wrapped, or
> consistently unwrapped.
> I haven't had much of a chance to think about how we can deal with this,
> but one thing that comes to mind is to allow an application to choose a
> particular ExceptionConverter implementation. Hibernate would need to be
> changed to always convert exceptions (including for strictly native
> operations) before returning to the application.
> For example, a property, hibernate.exception_converter could be added with
> the following values:
> jpa - default for JPA applications (org.hibernate.internal.
> ExceptionConverterImpl)
> native (or legacy?) - default for native applications that does not wrap
> HibernateException
> fully-qualified class name that implements ExceptionConverter
> If users have to make changes to exception handling for 5.3, do you think
> they would be willing to change their application to use JPA exceptions
> (i.e., hibernate.exception_converter=jpa)?
> Comments?
> Regards,
> Gail
> [1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
> [2] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMTransientObjectExceptionUnitTestCase.java
> [3] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMConstraintViolationExceptionUnitTestCase.java
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month