From kabir.khan at jboss.com  Mon Feb  1 05:19:16 2016
From: kabir.khan at jboss.com (Kabir Khan)
Date: Mon, 1 Feb 2016 10:19:16 +0000
Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite
In-Reply-To: <56AB1CA7.4080907@redhat.com>
References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com>
	<CAMquZP432zwaOv-d0CieTC1qdQUPJdttaUo9ZrAOqKYGMHwy8Q@mail.gmail.com>
	<56AB1CA7.4080907@redhat.com>
Message-ID: <4D37D223-5A34-4CB4-B55A-04BBA23E5A8E@jboss.com>

The snapshot is local to the build.
On one machine when a core PR is opened:
1) It builds the core snapshot
2) It runs the main build using the snapshot from 1)

The snapshot is not deployed anywhere, and AFAIK removed from the repository when the next build happens.
> On 29 Jan 2016, at 08:02, Carlo de Wolf <cdewolf at redhat.com> wrote:
> 
> I'm not saying, do not use snapshots. I'm saying do not use SNAPSHOT. :-)
> 
> Clearly the path is a shared one, so the build must use timed snapshots or risk interference.
> 
> Carlo
> 
> On 01/28/2016 12:54 PM, Toma? Cerar wrote:
>> 
>> On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf <cdewolf at redhat.com> wrote:
>> There should be no SNAPSHOT dependencies in any CI build. While it does build core beforehand, it might get overwritten by another CI run.
>> [org.wildfly.core:wildfly-core-parent] [INFO] Installing /opt/buildAgent/work/db872761b443af46/core/pom.xml to /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom
>> 
>> Would it be possible to use timed snapshots instead?
>> 
>> 
>> As Stuart said, whole point of this builds is to have snapshot builds.
>> Same build agent first builds core (clean install) and than builds full
>> with -Dversion.wildfly.core=<version of wildfly core previousily built>
>> 
>> snapshot used here are only build agent local, not publish on some outside nexus repository.
>> 
>> --
>> tomaz
>> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From hpehl at redhat.com  Mon Feb  1 06:12:31 2016
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 1 Feb 2016 12:12:31 +0100
Subject: [wildfly-dev] Test connection issues in management console
Message-ID: <98E2C108-892A-40D4-A5FE-9BD625F3E80B@redhat.com>

The management console currently has a feature to test a JDBC connection as the last step of the "Create Datasource" wizard. From an user's POV I clearly see a value to provide such a feature. 

However it comes at a price: In order to test a connection, the datasource must be created in advance. Now if the user decides to cancel the wizard, the tmp datasource must be removed again. 

Another issue occurs, if the test connection fails - say due to a typo in the password. In this case the user can go back one step to fix the wrong password. Now the tmp datasource needs to be modified. which in turn sets the process-state to reload-required. Further :test-connection-in-pool() operations will fail until the server is reloaded. Doing that in the middle of the "Create Datasource" wizard is neither user friendly nor obvious for the user. 

In domain mode there are even more things to consider. In order to create the datasource (when clicking on "Test connection") we need a running server in a group which matches the selected profile). 

Given all these issues I strongly recommend to remove the "Test connection" feature in the "Create Datasource" wizard at all. The user would still be able to test the connection once it was created. Currently this can be done in both the configuration and runtime section. When revisiting this feature, I would also like to remove the test connection feature in the configuration section as it clearly belong to the runtime section. 

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info



From hpehl at redhat.com  Mon Feb  1 06:21:09 2016
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 1 Feb 2016 12:21:09 +0100
Subject: [wildfly-dev] Blockers for WildFly 10 Final
In-Reply-To: <CAEBys6JqSzE2LPRZwt40WmjmWiNYSUTLvcvPp5GjWhwkCbc5xg@mail.gmail.com>
References: <CACmMjVmHvq9Zj7+_KkpGcSQv153JVYrKD=Mpx6_2jP4pF+xxDQ@mail.gmail.com>
	<CAEBys6+N6mHWgKgrYDkoDshJ36Obetc_TTkkkGnvLeRX+a1Hig@mail.gmail.com>
	<56AB2F38.3030300@jboss.com>
	<CAEBys6JqSzE2LPRZwt40WmjmWiNYSUTLvcvPp5GjWhwkCbc5xg@mail.gmail.com>
Message-ID: <19659ADA-38D9-4994-8B3B-26056B9917BC@redhat.com>

I can confirm the issue with the fixed password. Doing some more tests I come to the conclusion that the whole idea of testing the connection during the "Create Datasource" wizard is a bad idea. There are more issues related to this [1]. 

[1] http://wildfly-development.1055759.n5.nabble.com/Test-connection-issues-in-management-console-td5716696.html <http://wildfly-development.1055759.n5.nabble.com/Test-connection-issues-in-management-console-td5716696.html>
> Am 30.01.2016 um 22:46 schrieb Renann Prado <darkness.renann at gmail.com>:
> 
> I've just downloaded Wildfly 10.0.0.Final and it's still not working 100%.
> 
> 1 - Fill all the fields, but put some wrong information like password, ip, whatever
> 2 - Get to the last screen where you can test the connection
> 3 - Test the connection (and fails)
> 4 - Go back, fix the connection info with right information
> 5 - Test connection and still fails (it's using old credentials)
> 
> Btw I was also able to see org.jboss.msc.service.DuplicateServiceException when I was testing, though I don't have clear steps how to reproduce.
> I don't believe the problem is in the web UI.
> 
> Another minor issue is that when it fails to test, most of the times (if not always), regardless of the type of error I get in the server, in web UI I always get same generic error message:
> 
> 19:41:01,345 ERROR [org.jboss.as.controller.management-operation] (management task-5) WFLYCTL0013: Operation ("test-connection-in-pool") failed - address: ([
> 
>     ("subsystem" => "datasources"),
> 
>     ("data-source" => "MySqlDS")
> 
> ]) - failure description: "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid"
> 
> 
> 
> And when I went to look in the server log:
> 
> 
> Caused by: java.sql.SQLInvalidAuthorizationSpecException: Could not connect: Access denied for user 'admin'@'192.168.0.107' (using password: YES)
> 
> at org.mariadb.jdbc.internal.util.ExceptionMapper.get(ExceptionMapper.java:121)
> 
> at org.mariadb.jdbc.internal.util.ExceptionMapper.throwException(ExceptionMapper.java:69)
> 
> at org.mariadb.jdbc.Driver.connect(Driver.java:110)
> 
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319)
> 
> 
> ... 31 more
> 
> 
> It would be nice to propagete the correct error to the web UI.
> 
> Thanks
> 
> 
> 
> 
> 
> Renann Prado
> 
> On Fri, Jan 29, 2016 at 7:22 AM, Darran Lofthouse <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
> 
> 
> On 29/01/16 02:07, Renann Prado wrote:
> > I'm pretty sure I reported same issue as yours.
> >
> > See:
> > https://issues.jboss.org/browse/WFLY-6015 <https://issues.jboss.org/browse/WFLY-6015>
> >
> > Seems to be fixed, but it's not clear to me whether it will be part of
> > Wildfly 10 Final or not.
> 
> Apart from the occasional mistake in Jira if the status is 'Resolved'
> the 'Fix Version/s' field shows the release the fix is or will be
> included in.
> 
> > However you can easily work around: just add the datasource with with
> > your driver && config and DO NOT CLICK IN TEST CONNECTION, then while
> > EDITING the datasource you can test the connection as many times as you
> > want. I did that in Wildfly 10.0.0.CR5 and it worked just fine.
> >
> > I wouldn't call that a blocker as there are couple of ways to create a
> > datasource.
> >
> > Hope it helps.
> >
> > Renann Prado
> >
> > On Thu, Jan 28, 2016 at 11:58 PM, Danilo Cominotti Marques
> > <dcominottim at gmail.com <mailto:dcominottim at gmail.com> <mailto:dcominottim at gmail.com <mailto:dcominottim at gmail.com>>> wrote:
> >
> >     Hello there,
> >
> >     I have seen the e-mail that listed the following issues as blockers
> >     for WildFly 10 Final,
> >
> >     1. https://issues.jboss.org/browse/WFLY-5480 <https://issues.jboss.org/browse/WFLY-5480>
> >     2. https://issues.jboss.org/browse/WFCORE-1277 <https://issues.jboss.org/browse/WFCORE-1277>
> >
> >     but I would clearly add the following one to that list,
> >
> >     3. https://issues.jboss.org/browse/HAL-1030 <https://issues.jboss.org/browse/HAL-1030>
> >
> >     because my company certainly wouldn't deploy WildFly 10 Final before
> >     this issue is solved.
> >
> >     Any chances of having somebody look into it before the final release?
> >
> >     Thanks.
> >
> >     Danilo Cominotti Marques
> >
> >
> >     _______________________________________________
> >     wildfly-dev mailing list
> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org> <mailto:wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>>
> >     https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160201/ab690770/attachment.html 

From brian.stansberry at redhat.com  Mon Feb  1 09:05:35 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 1 Feb 2016 08:05:35 -0600
Subject: [wildfly-dev] Test connection issues in management console
In-Reply-To: <98E2C108-892A-40D4-A5FE-9BD625F3E80B@redhat.com>
References: <98E2C108-892A-40D4-A5FE-9BD625F3E80B@redhat.com>
Message-ID: <56AF662F.7060802@redhat.com>

I agree.

On 2/1/16 5:12 AM, Harald Pehl wrote:
> The management console currently has a feature to test a JDBC connection as the last step of the "Create Datasource" wizard. From an user's POV I clearly see a value to provide such a feature.
>
> However it comes at a price: In order to test a connection, the datasource must be created in advance. Now if the user decides to cancel the wizard, the tmp datasource must be removed again.
>
> Another issue occurs, if the test connection fails - say due to a typo in the password. In this case the user can go back one step to fix the wrong password. Now the tmp datasource needs to be modified. which in turn sets the process-state to reload-required. Further :test-connection-in-pool() operations will fail until the server is reloaded. Doing that in the middle of the "Create Datasource" wizard is neither user friendly nor obvious for the user.
>
> In domain mode there are even more things to consider. In order to create the datasource (when clicking on "Test connection") we need a running server in a group which matches the selected profile).
>
> Given all these issues I strongly recommend to remove the "Test connection" feature in the "Create Datasource" wizard at all. The user would still be able to test the connection once it was created. Currently this can be done in both the configuration and runtime section. When revisiting this feature, I would also like to remove the test connection feature in the configuration section as it clearly belong to the runtime section.
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From david.lloyd at redhat.com  Mon Feb  1 10:43:34 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 1 Feb 2016 09:43:34 -0600
Subject: [wildfly-dev] The EJB client and remote JTA transaction
 propagation
In-Reply-To: <56ABAF04.2070305@redhat.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com>
Message-ID: <56AF7D26.4030807@redhat.com>

I was thinking about this a bit.  It seems to me that there are two 
"levels" of this that could be explored:

1. A transaction was made available to the server, but the EJB on the 
server does not use the caller's transaction context, so the EJB code 
never actually has to inflow the transaction.  The EJB code would be 
able to make this determination without any help from the TM.

2. A transaction was made available, and the EJB resumed it, but no 
resources were actually enlisted, or perhaps resources were enlisted but 
not actually used, resulting in the same effect but relying on the TM to 
provide this information.

I guess when you refer to a callback from Narayana, (2) is what you're 
referring to?  When would this information be available?  Maybe as some 
special result of suspending the transaction?

On 01/29/2016 12:27 PM, David M. Lloyd wrote:
> That's an interesting idea.  So in effect, the remote EJB would tell the
> caller "you sent me a transaction ID, but in the end, I didn't use it"?
>   I would need to think about how this might work in the presence of
> multiple concurrent invocations on the same transaction.
>
> Either way though, I think it would still be beneficial for clients to
> be able to explicitly annotate a client method (or otherwise establish a
> policy) such that it causes transactions to be propagated (or not), or
> to enforce transaction-related preconditions.  The interceptor that
> implements this feature doesn't actually have protocol awareness: it
> just examines the current environment, and decides whether to attach the
> transaction to the invocation context.
>
> On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>> One option that I would favour is to go down the JTS route where the
>> subordinate calls back on the parent to tell it to register it in the
>> transaction. This could be a new JBoss Remoting API that I can invoke
>> from Narayana. The call would not necessarily be a remote call, it would
>> invoke back into the JBR transport to tell it that when it returns to
>> the parent it needs to enlist (or not).
>>
>> On 29 January 2016 at 15:47, David M. Lloyd <david.lloyd at redhat.com
>> <mailto:david.lloyd at redhat.com>> wrote:
>>
>>     As you may know, WildFly supports a feature wherein an EJB client
>> which
>>     is invoking an EJB on a remote server has the option to propagate its
>>     local transaction to the remote server, treating the remote server
>> as a
>>     subordinate and coordinating the transaction's two-phase commit among
>>     the resultant graph of servers.  This feature has always been
>> limited in
>>     that, when enabled, transactions are always propagated, regardless of
>>     the peer EJB's transaction policy, or of whether the peer even has a
>>     transaction manager.
>>
>>     So, for the invocation rework which I anticipate will be included in
>>     WildFly 11, I've introduced a new client-side annotation intended
>> to be
>>     associated with the EJB interface which informs the client library
>> what
>>     to do for transaction propagation for that interface.  In addition, I
>>     intend to configuration strategies which will allow the default
>> mode to
>>     be specified in various ways (per-thread, globally, and by target
>>     interface/method all come to mind), for cases where the EJB's remote
>>     interface cannot be easily modified for some reason.  I expect to
>> also
>>     broaden these configuration strategies to apply to all client-side
>> EJB
>>     interface/methods configuration items [3].
>>
>>     The first part of this change is the addition of a new annotation
>> called
>>     @ClientTransaction [1], which accepts as a value an enum called
>>     ClientTransactionPolicy [2].  The latter specifies whether a local
>>     transaction is required or forbidden for the method or interface, and
>>     also specifies whether the transaction is propagated or not
>> propagated.
>>
>>     I've added copious amounts of JavaDoc in order to establish
>> exactly what
>>     the behavior of each mode is, as well as to specify how each mode
>>     interacts with the various modules that are configured via the
>> standard
>>     javax.ejb.TransactionAttributeType enum.
>>
>>     [1]
>>
>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>
>>     [2]
>>
>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>
>>     [2] (raw)
>>
>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>
>>     [3] for a list, see:
>>
>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>
>>
>>     --
>>     - DML
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
>

-- 
- DML

From tomaz.cerar at gmail.com  Mon Feb  1 13:48:16 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 1 Feb 2016 19:48:16 +0100
Subject: [wildfly-dev] Is the BOM for 10.0.0.Final available already?
In-Reply-To: <CAEBys6KXN4np0N+x8TWrM4AXdc7a8KT6OhV+0OAANGRS4j0z7A@mail.gmail.com>
References: <CAEBys6KXN4np0N+x8TWrM4AXdc7a8KT6OhV+0OAANGRS4j0z7A@mail.gmail.com>
Message-ID: <CAMquZP6cqtgSC2xS5Gn=Oa_G1cjZHBi8wv12p1Qpg-Q1XLj6Kg@mail.gmail.com>

WildFly BOMs for 10.0.0.Final are released.

easiest way to use it is to have this in your pom

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.wildfly.bom</groupId>
            <artifactId>wildfly-javaee7</artifactId>
            <scope>import</scope>
            <type>pom</type>
            <version>10.0.0.Final</version>
        </dependency>
    </dependencies>
</dependencyManagement>

make sure that this is part of your <dependencyManagement> and not just
<dependencies>


--
toma?




On Sat, Jan 30, 2016 at 5:34 PM, Renann Prado <darkness.renann at gmail.com>
wrote:

> I tried to use
>
> <dependency>
>
>                 <groupId>org.wildfly.bom</groupId>
>
>                 <artifactId>jboss-javaee-7.0-wildfly</artifactId>
>
>                 <version>10.0.0.Final</version>
>
>                 <type>pom</type>
>
>                 <scope>import</scope>
>
> </dependency>
>
>
> But couldn't.
>
>
> Renann Prado
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160201/a13b4fb5/attachment.html 

From tdthakshi at gmail.com  Tue Feb  2 03:00:01 2016
From: tdthakshi at gmail.com (Thakshila Dilrukshi)
Date: Tue, 2 Feb 2016 13:30:01 +0530
Subject: [wildfly-dev] Contribute to Jboss development
Message-ID: <CAGxPjgc_B9Ti5EwzSMKwXL9198cpS-Yquy4uRBGD1QR0qBXo=w@mail.gmail.com>

Hi all,

I am Thakshila Dilrukshi, working as a software engineer as well as
following postgraduate degree. I prefer to involve with JBoss development.
I'm familiar with Java (J2SE, J2EE), JMS, Asynchronous message passing
(Future Tasks), Quartz schedulers, Web services (SOAP, RESTful), spring,
hibernate. EJB, JUnit, Oracle, MySQL, MAVEN, Infinispan.

Other than the given areas, I like to learn new technologies. Can anyone of
you guide my how I should proceed, which are the projects that I should
contribute with the knowledge I have?


Thanks & Regards,
Thakshila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160202/77603b5a/attachment.html 

From tom.jenkinson at redhat.com  Tue Feb  2 04:01:25 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 2 Feb 2016 09:01:25 +0000
Subject: [wildfly-dev] The EJB client and remote JTA transaction
	propagation
In-Reply-To: <56AF7D26.4030807@redhat.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
Message-ID: <CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>

Hi David,

I was referring to case 1 when the transaction is inflowed into a second
server. For JTS the type of transaction we create is a ServerTopLevelAction
and this in its ctor calls back to the remote server:
https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
If the transport can do that without the TMs assistance then that works for
me :)

I don't think we should optimize for case 2. The incidents where a
transaction is created and not used should be really low.

Thanks,
Tom



On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com> wrote:

> I was thinking about this a bit.  It seems to me that there are two
> "levels" of this that could be explored:
>
> 1. A transaction was made available to the server, but the EJB on the
> server does not use the caller's transaction context, so the EJB code never
> actually has to inflow the transaction.  The EJB code would be able to make
> this determination without any help from the TM.
>
> 2. A transaction was made available, and the EJB resumed it, but no
> resources were actually enlisted, or perhaps resources were enlisted but
> not actually used, resulting in the same effect but relying on the TM to
> provide this information.
>
> I guess when you refer to a callback from Narayana, (2) is what you're
> referring to?  When would this information be available?  Maybe as some
> special result of suspending the transaction?
>
>
> On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>
>> That's an interesting idea.  So in effect, the remote EJB would tell the
>> caller "you sent me a transaction ID, but in the end, I didn't use it"?
>>   I would need to think about how this might work in the presence of
>> multiple concurrent invocations on the same transaction.
>>
>> Either way though, I think it would still be beneficial for clients to
>> be able to explicitly annotate a client method (or otherwise establish a
>> policy) such that it causes transactions to be propagated (or not), or
>> to enforce transaction-related preconditions.  The interceptor that
>> implements this feature doesn't actually have protocol awareness: it
>> just examines the current environment, and decides whether to attach the
>> transaction to the invocation context.
>>
>> On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>
>>> One option that I would favour is to go down the JTS route where the
>>> subordinate calls back on the parent to tell it to register it in the
>>> transaction. This could be a new JBoss Remoting API that I can invoke
>>> from Narayana. The call would not necessarily be a remote call, it would
>>> invoke back into the JBR transport to tell it that when it returns to
>>> the parent it needs to enlist (or not).
>>>
>>> On 29 January 2016 at 15:47, David M. Lloyd <david.lloyd at redhat.com
>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>
>>>     As you may know, WildFly supports a feature wherein an EJB client
>>> which
>>>     is invoking an EJB on a remote server has the option to propagate its
>>>     local transaction to the remote server, treating the remote server
>>> as a
>>>     subordinate and coordinating the transaction's two-phase commit among
>>>     the resultant graph of servers.  This feature has always been
>>> limited in
>>>     that, when enabled, transactions are always propagated, regardless of
>>>     the peer EJB's transaction policy, or of whether the peer even has a
>>>     transaction manager.
>>>
>>>     So, for the invocation rework which I anticipate will be included in
>>>     WildFly 11, I've introduced a new client-side annotation intended
>>> to be
>>>     associated with the EJB interface which informs the client library
>>> what
>>>     to do for transaction propagation for that interface.  In addition, I
>>>     intend to configuration strategies which will allow the default
>>> mode to
>>>     be specified in various ways (per-thread, globally, and by target
>>>     interface/method all come to mind), for cases where the EJB's remote
>>>     interface cannot be easily modified for some reason.  I expect to
>>> also
>>>     broaden these configuration strategies to apply to all client-side
>>> EJB
>>>     interface/methods configuration items [3].
>>>
>>>     The first part of this change is the addition of a new annotation
>>> called
>>>     @ClientTransaction [1], which accepts as a value an enum called
>>>     ClientTransactionPolicy [2].  The latter specifies whether a local
>>>     transaction is required or forbidden for the method or interface, and
>>>     also specifies whether the transaction is propagated or not
>>> propagated.
>>>
>>>     I've added copious amounts of JavaDoc in order to establish
>>> exactly what
>>>     the behavior of each mode is, as well as to specify how each mode
>>>     interacts with the various modules that are configured via the
>>> standard
>>>     javax.ejb.TransactionAttributeType enum.
>>>
>>>     [1]
>>>
>>>
>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>>
>>>     [2]
>>>
>>>
>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>
>>>     [2] (raw)
>>>
>>>
>>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>
>>>     [3] for a list, see:
>>>
>>>
>>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>>
>>>
>>>     --
>>>     - DML
>>>     _______________________________________________
>>>     wildfly-dev mailing list
>>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>
>>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160202/7f48fec2/attachment.html 

From pierrick.hymbert at gmail.com  Tue Feb  2 04:22:07 2016
From: pierrick.hymbert at gmail.com (Pierrick HYMBERT)
Date: Tue, 2 Feb 2016 12:22:07 +0300
Subject: [wildfly-dev] Wildfly 10.0.0.Final and Infinispan subsystem
 model 4.0 - Got a local cache despite it is configured as distributed
In-Reply-To: <CAKh6_HY5ODQLm6-A9xk4CbSeq8bC6_baM8ryo2yrrUBwNf7Y4w@mail.gmail.com>
References: <CAKh6_HY5ODQLm6-A9xk4CbSeq8bC6_baM8ryo2yrrUBwNf7Y4w@mail.gmail.com>
Message-ID: <CAKh6_HZEsjptT1jGwhRe+qT0H4SADLLMfP0UGB=6Qn5nCgDPVQ@mail.gmail.com>

Answer was: configure cache programatically (that is unexpected, I guess
there is an issue in wildfly-clustering-infinispan-extension artifact...):

//    this.myAppCache = this.cacheContainer.getCache("myAppCache");
this.cacheContainer.defineConfiguration("dist", new ConfigurationBuilder()
    .clustering()
    .cacheMode(CacheMode.DIST_SYNC)
    .hash().numOwners(2)
    .build()
        );
this.myAppCache = this.cacheContainer.getCache("dist");

And now it works:

2016-02-02 12:20:25,925 INFO
 [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce
new cache entry 1454404825925 on node master:server-one
2016-02-02 12:20:26,008 INFO
 [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache
size on node master:server-one = 172

2016-02-02 12:20:26,009 INFO
 [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache
size on node master:server-two = 172



? ????????? / Cordialement / Best regards,

*Pierrick **HYMBERT*
*pierrick.hymbert at gmail.com <pierrick.hymbert at gmail.com>*
*(+7)916.301-89-13 / (+33)6.87-52-91-37*
*+Pierrick <https://plus.google.com/u/0/105713262389092625238> /
**Skype / **LinkedIn
<http://www.linkedin.com/pub/pierrick-hymbert/51/506/357>*

2016-01-31 14:59 GMT+03:00 Pierrick HYMBERT <pierrick.hymbert at gmail.com>:

> Dear Wildfly dev team,
>
> I am blocked to deploy a test app that use a distributed infinispan cache
> within 2 domain nodes and a cache entry producer deployed as clustered
> singleton service.
> Your feedback/advise are really appreciated!
>
> Cache definition:
>
>                 <cache-container name="my-cache-container">
>                     <transport lock-timeout="60000"/>
>                     <distributed-cache name="myAppCache" mode="SYNC">
>                         <transaction mode="NONE"/>
>                         <eviction strategy="NONE"/>
>                     </distributed-cache>
>                 </cache-container>
>
> Sample code:
>
>   @Resource(lookup = "java:jboss/infinispan/container/my-cache-container")
>   private EmbeddedCacheManager cacheContainer;
>
>   private Cache<Long, Long> myAppCache;
>
>   @PostConstruct
>   public void startNotClustered() throws NamingException {
>     this.myAppCache = this.cacheContainer.getCache("myAppCache");
>     ...
>   }
>
>   ...
>
>   @Schedule(hour = "*", minute = "*", second = "*")
>   public void consume() {
>     logger.info("Cache size on node {} = {}",
>         System.getProperty("jboss.node.name"), myAppCache.size());
>   }
>
>
> Server one sample logs:
> 2016-01-31 14:52:03,789 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce
> new cache entry 1454241123789 on node master:server-one
> 2016-01-31 14:52:04,005 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache
> size on node master:server-one = 35
> 2016-01-31 14:52:04,796 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Produce
> new cache entry 1454241124796 on node master:server-one
> 2016-01-31 14:52:05,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache
> size on node master:server-one = 36
> 2016-01-31 14:52:05,801 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Produce
> new cache entry 1454241125801 on node master:server-one
> 2016-01-31 14:52:06,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache
> size on node master:server-one = 37
> 2016-01-31 14:52:06,807 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce
> new cache entry 1454241126807 on node master:server-one
> 2016-01-31 14:52:07,005 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache
> size on node master:server-one = 38
> 2016-01-31 14:52:07,813 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Produce
> new cache entry 1454241127813 on node master:server-one
> 2016-01-31 14:52:08,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache
> size on node master:server-one = 39
> 2016-01-31 14:52:08,817 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce
> new cache entry 1454241128817 on node master:server-one
> 2016-01-31 14:52:09,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) *Cache
> size on node master:server-one = 40*
>
> Server two logs:
> 2016-01-31 14:51:56,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache
> size on node master:server-two = 0
> 2016-01-31 14:51:57,008 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache
> size on node master:server-two = 0
> 2016-01-31 14:51:58,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache
> size on node master:server-two = 0
> 2016-01-31 14:51:59,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:00,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:01,008 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:02,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:03,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:04,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:05,008 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:06,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:07,006 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:08,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache
> size on node master:server-two = 0
> 2016-01-31 14:52:09,007 INFO
>  [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) *Cache
> size on node master:server-two = 0*
>
>
> I have attached all necessary info to investigate, but I am not sure
> attachement is allowed, so you can see source and logs here:
>
> https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0
>
>
> ? ????????? / Cordialement / Best regards,
>
> *Pierrick **HYMBERT*
> *pierrick.hymbert at gmail.com <pierrick.hymbert at gmail.com>*
> *(+7)916.301-89-13 <%28%2B7%29916.301-89-13> / (+33)6.87-52-91-37
> <%2B33%296.87-52-91-37>*
> *+Pierrick <https://plus.google.com/u/0/105713262389092625238> / *
> *Skype / **LinkedIn
> <http://www.linkedin.com/pub/pierrick-hymbert/51/506/357>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160202/d84e1494/attachment-0001.html 

From darran.lofthouse at jboss.com  Tue Feb  2 05:11:40 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 2 Feb 2016 10:11:40 +0000
Subject: [wildfly-dev] Contribute to Jboss development
In-Reply-To: <CAGxPjgc_B9Ti5EwzSMKwXL9198cpS-Yquy4uRBGD1QR0qBXo=w@mail.gmail.com>
References: <CAGxPjgc_B9Ti5EwzSMKwXL9198cpS-Yquy4uRBGD1QR0qBXo=w@mail.gmail.com>
Message-ID: <56B080DC.4060806@jboss.com>

I would suggest starting by looking into how to checkout and build the 
application server as this is the foundation for our EE distribution: -

https://developer.jboss.org/wiki/HackingOnWildFly

After that a number of the containers you list are developed as their 
own projects so if you have a more in-depth interest in any of those 
maybe you would look at those in more detail.

Ideally if you have a problem you are already experiencing that may be a 
place to start to solve something, or have a look in Jira and see if 
there are any issues there that interest you.  If something interests 
you just add a comment to check it is still applicable and not currently 
being worked on.

On 02/02/16 08:00, Thakshila Dilrukshi wrote:
> Hi all,
>
> I am Thakshila Dilrukshi, working as a software engineer as well as
> following postgraduate degree. I prefer to involve with JBoss
> development. I'm familiar with Java (J2SE, J2EE), JMS, Asynchronous
> message passing (Future Tasks), Quartz schedulers, Web services (SOAP,
> RESTful), spring, hibernate. EJB, JUnit, Oracle, MySQL, MAVEN, Infinispan.
>
> Other than the given areas, I like to learn new technologies. Can anyone
> of you guide my how I should proceed, which are the projects that I
> should contribute with the knowledge I have?
>
>
> Thanks & Regards,
> Thakshila
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From david.lloyd at redhat.com  Tue Feb  2 08:49:57 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 2 Feb 2016 07:49:57 -0600
Subject: [wildfly-dev] The EJB client and remote JTA transaction
 propagation
In-Reply-To: <CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
Message-ID: <56B0B405.40600@redhat.com>

Ah okay, cool.  This is an easy (and, in hindsight, rather obvious) 
enhancement that I can build into the new protocol with a minimum of effort.

Thanks!

On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
> Hi David,
>
> I was referring to case 1 when the transaction is inflowed into a second
> server. For JTS the type of transaction we create is a
> ServerTopLevelAction and this in its ctor calls back to the remote server:
> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
> If the transport can do that without the TMs assistance then that works
> for me :)
>
> I don't think we should optimize for case 2. The incidents where a
> transaction is created and not used should be really low.
>
> Thanks,
> Tom
>
>
>
> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     I was thinking about this a bit.  It seems to me that there are two
>     "levels" of this that could be explored:
>
>     1. A transaction was made available to the server, but the EJB on
>     the server does not use the caller's transaction context, so the EJB
>     code never actually has to inflow the transaction.  The EJB code
>     would be able to make this determination without any help from the TM.
>
>     2. A transaction was made available, and the EJB resumed it, but no
>     resources were actually enlisted, or perhaps resources were enlisted
>     but not actually used, resulting in the same effect but relying on
>     the TM to provide this information.
>
>     I guess when you refer to a callback from Narayana, (2) is what
>     you're referring to?  When would this information be available?
>     Maybe as some special result of suspending the transaction?
>
>
>     On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>
>         That's an interesting idea.  So in effect, the remote EJB would
>         tell the
>         caller "you sent me a transaction ID, but in the end, I didn't
>         use it"?
>            I would need to think about how this might work in the
>         presence of
>         multiple concurrent invocations on the same transaction.
>
>         Either way though, I think it would still be beneficial for
>         clients to
>         be able to explicitly annotate a client method (or otherwise
>         establish a
>         policy) such that it causes transactions to be propagated (or
>         not), or
>         to enforce transaction-related preconditions.  The interceptor that
>         implements this feature doesn't actually have protocol awareness: it
>         just examines the current environment, and decides whether to
>         attach the
>         transaction to the invocation context.
>
>         On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>
>             One option that I would favour is to go down the JTS route
>             where the
>             subordinate calls back on the parent to tell it to register
>             it in the
>             transaction. This could be a new JBoss Remoting API that I
>             can invoke
>             from Narayana. The call would not necessarily be a remote
>             call, it would
>             invoke back into the JBR transport to tell it that when it
>             returns to
>             the parent it needs to enlist (or not).
>
>             On 29 January 2016 at 15:47, David M. Lloyd
>             <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>             <mailto:david.lloyd at redhat.com
>             <mailto:david.lloyd at redhat.com>>> wrote:
>
>                  As you may know, WildFly supports a feature wherein an
>             EJB client
>             which
>                  is invoking an EJB on a remote server has the option to
>             propagate its
>                  local transaction to the remote server, treating the
>             remote server
>             as a
>                  subordinate and coordinating the transaction's
>             two-phase commit among
>                  the resultant graph of servers.  This feature has
>             always been
>             limited in
>                  that, when enabled, transactions are always propagated,
>             regardless of
>                  the peer EJB's transaction policy, or of whether the
>             peer even has a
>                  transaction manager.
>
>                  So, for the invocation rework which I anticipate will
>             be included in
>                  WildFly 11, I've introduced a new client-side
>             annotation intended
>             to be
>                  associated with the EJB interface which informs the
>             client library
>             what
>                  to do for transaction propagation for that interface.
>             In addition, I
>                  intend to configuration strategies which will allow the
>             default
>             mode to
>                  be specified in various ways (per-thread, globally, and
>             by target
>                  interface/method all come to mind), for cases where the
>             EJB's remote
>                  interface cannot be easily modified for some reason.  I
>             expect to
>             also
>                  broaden these configuration strategies to apply to all
>             client-side
>             EJB
>                  interface/methods configuration items [3].
>
>                  The first part of this change is the addition of a new
>             annotation
>             called
>                  @ClientTransaction [1], which accepts as a value an
>             enum called
>                  ClientTransactionPolicy [2].  The latter specifies
>             whether a local
>                  transaction is required or forbidden for the method or
>             interface, and
>                  also specifies whether the transaction is propagated or not
>             propagated.
>
>                  I've added copious amounts of JavaDoc in order to establish
>             exactly what
>                  the behavior of each mode is, as well as to specify how
>             each mode
>                  interacts with the various modules that are configured
>             via the
>             standard
>                  javax.ejb.TransactionAttributeType enum.
>
>                  [1]
>
>             https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>
>                  [2]
>
>             https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>
>                  [2] (raw)
>
>             https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>
>                  [3] for a list, see:
>
>             https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>
>
>                  --
>                  - DML
>                  _______________________________________________
>                  wildfly-dev mailing list
>             wildfly-dev at lists.jboss.org
>             <mailto:wildfly-dev at lists.jboss.org>
>             <mailto:wildfly-dev at lists.jboss.org
>             <mailto:wildfly-dev at lists.jboss.org>>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
>     --
>     - DML
>
>

-- 
- DML

From tom.jenkinson at redhat.com  Tue Feb  2 09:27:45 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 2 Feb 2016 14:27:45 +0000
Subject: [wildfly-dev] The EJB client and remote JTA transaction
	propagation
In-Reply-To: <56B0B405.40600@redhat.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
	<56B0B405.40600@redhat.com>
Message-ID: <CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>

No problem :)

On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com> wrote:

> Ah okay, cool.  This is an easy (and, in hindsight, rather obvious)
> enhancement that I can build into the new protocol with a minimum of effort.
>
> Thanks!
>
> On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
>
>> Hi David,
>>
>> I was referring to case 1 when the transaction is inflowed into a second
>> server. For JTS the type of transaction we create is a
>> ServerTopLevelAction and this in its ctor calls back to the remote server:
>>
>> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
>> If the transport can do that without the TMs assistance then that works
>> for me :)
>>
>> I don't think we should optimize for case 2. The incidents where a
>> transaction is created and not used should be really low.
>>
>> Thanks,
>> Tom
>>
>>
>>
>> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
>> <mailto:david.lloyd at redhat.com>> wrote:
>>
>>     I was thinking about this a bit.  It seems to me that there are two
>>     "levels" of this that could be explored:
>>
>>     1. A transaction was made available to the server, but the EJB on
>>     the server does not use the caller's transaction context, so the EJB
>>     code never actually has to inflow the transaction.  The EJB code
>>     would be able to make this determination without any help from the TM.
>>
>>     2. A transaction was made available, and the EJB resumed it, but no
>>     resources were actually enlisted, or perhaps resources were enlisted
>>     but not actually used, resulting in the same effect but relying on
>>     the TM to provide this information.
>>
>>     I guess when you refer to a callback from Narayana, (2) is what
>>     you're referring to?  When would this information be available?
>>     Maybe as some special result of suspending the transaction?
>>
>>
>>     On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>>
>>         That's an interesting idea.  So in effect, the remote EJB would
>>         tell the
>>         caller "you sent me a transaction ID, but in the end, I didn't
>>         use it"?
>>            I would need to think about how this might work in the
>>         presence of
>>         multiple concurrent invocations on the same transaction.
>>
>>         Either way though, I think it would still be beneficial for
>>         clients to
>>         be able to explicitly annotate a client method (or otherwise
>>         establish a
>>         policy) such that it causes transactions to be propagated (or
>>         not), or
>>         to enforce transaction-related preconditions.  The interceptor
>> that
>>         implements this feature doesn't actually have protocol awareness:
>> it
>>         just examines the current environment, and decides whether to
>>         attach the
>>         transaction to the invocation context.
>>
>>         On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>
>>             One option that I would favour is to go down the JTS route
>>             where the
>>             subordinate calls back on the parent to tell it to register
>>             it in the
>>             transaction. This could be a new JBoss Remoting API that I
>>             can invoke
>>             from Narayana. The call would not necessarily be a remote
>>             call, it would
>>             invoke back into the JBR transport to tell it that when it
>>             returns to
>>             the parent it needs to enlist (or not).
>>
>>             On 29 January 2016 at 15:47, David M. Lloyd
>>             <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>>             <mailto:david.lloyd at redhat.com
>>
>>             <mailto:david.lloyd at redhat.com>>> wrote:
>>
>>                  As you may know, WildFly supports a feature wherein an
>>             EJB client
>>             which
>>                  is invoking an EJB on a remote server has the option to
>>             propagate its
>>                  local transaction to the remote server, treating the
>>             remote server
>>             as a
>>                  subordinate and coordinating the transaction's
>>             two-phase commit among
>>                  the resultant graph of servers.  This feature has
>>             always been
>>             limited in
>>                  that, when enabled, transactions are always propagated,
>>             regardless of
>>                  the peer EJB's transaction policy, or of whether the
>>             peer even has a
>>                  transaction manager.
>>
>>                  So, for the invocation rework which I anticipate will
>>             be included in
>>                  WildFly 11, I've introduced a new client-side
>>             annotation intended
>>             to be
>>                  associated with the EJB interface which informs the
>>             client library
>>             what
>>                  to do for transaction propagation for that interface.
>>             In addition, I
>>                  intend to configuration strategies which will allow the
>>             default
>>             mode to
>>                  be specified in various ways (per-thread, globally, and
>>             by target
>>                  interface/method all come to mind), for cases where the
>>             EJB's remote
>>                  interface cannot be easily modified for some reason.  I
>>             expect to
>>             also
>>                  broaden these configuration strategies to apply to all
>>             client-side
>>             EJB
>>                  interface/methods configuration items [3].
>>
>>                  The first part of this change is the addition of a new
>>             annotation
>>             called
>>                  @ClientTransaction [1], which accepts as a value an
>>             enum called
>>                  ClientTransactionPolicy [2].  The latter specifies
>>             whether a local
>>                  transaction is required or forbidden for the method or
>>             interface, and
>>                  also specifies whether the transaction is propagated or
>> not
>>             propagated.
>>
>>                  I've added copious amounts of JavaDoc in order to
>> establish
>>             exactly what
>>                  the behavior of each mode is, as well as to specify how
>>             each mode
>>                  interacts with the various modules that are configured
>>             via the
>>             standard
>>                  javax.ejb.TransactionAttributeType enum.
>>
>>                  [1]
>>
>>
>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>
>>                  [2]
>>
>>
>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>
>>                  [2] (raw)
>>
>>
>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>
>>                  [3] for a list, see:
>>
>>
>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>
>>
>>                  --
>>                  - DML
>>                  _______________________________________________
>>                  wildfly-dev mailing list
>>             wildfly-dev at lists.jboss.org
>>             <mailto:wildfly-dev at lists.jboss.org>
>>             <mailto:wildfly-dev at lists.jboss.org
>>             <mailto:wildfly-dev at lists.jboss.org>>
>>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>>
>>     --
>>     - DML
>>
>>
>>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160202/4320a736/attachment-0001.html 

From darkness.renann at gmail.com  Wed Feb  3 18:38:16 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Wed, 3 Feb 2016 21:38:16 -0200
Subject: [wildfly-dev] Error response handling from bean validation ignores
	Accept header
Message-ID: <CAEBys6+-cf7LU1-wqVQbZGsfjgXN9naLJYVh5cJwuh057zAGBQ@mail.gmail.com>

Hi, guys.

I'd like to know if there is any workaround for this issue:

https://issues.jboss.org/browse/WFLY-6097

Thanks!

Renann Prado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160203/4c6adbae/attachment.html 

From gunnar at hibernate.org  Thu Feb  4 06:24:44 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 4 Feb 2016 12:24:44 +0100
Subject: [wildfly-dev] Error response handling from bean validation
 ignores Accept header
In-Reply-To: <CAEBys6+-cf7LU1-wqVQbZGsfjgXN9naLJYVh5cJwuh057zAGBQ@mail.gmail.com>
References: <CAEBys6+-cf7LU1-wqVQbZGsfjgXN9naLJYVh5cJwuh057zAGBQ@mail.gmail.com>
Message-ID: <CADGJaX8dzHeOgoMA0L+nTP8mQbNFXWg720tUUJNVhAcp-4xdFA@mail.gmail.com>

I've replied at the issue; I think you are running into
https://issues.jboss.org/browse/RESTEASY-1264 which also describes a
work-around.

--Gunnar


2016-02-04 0:38 GMT+01:00 Renann Prado <darkness.renann at gmail.com>:
> Hi, guys.
>
> I'd like to know if there is any workaround for this issue:
>
> https://issues.jboss.org/browse/WFLY-6097
>
> Thanks!
>
> Renann Prado
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From darkness.renann at gmail.com  Thu Feb  4 07:49:09 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Thu, 4 Feb 2016 10:49:09 -0200
Subject: [wildfly-dev] Error response handling from bean validation
 ignores Accept header
In-Reply-To: <CADGJaX8dzHeOgoMA0L+nTP8mQbNFXWg720tUUJNVhAcp-4xdFA@mail.gmail.com>
References: <CAEBys6+-cf7LU1-wqVQbZGsfjgXN9naLJYVh5cJwuh057zAGBQ@mail.gmail.com>
	<CADGJaX8dzHeOgoMA0L+nTP8mQbNFXWg720tUUJNVhAcp-4xdFA@mail.gmail.com>
Message-ID: <CAEBys6+kF6mjf8x8cvWnnHo1HwNkNWoyXBbuCqN0tWjKi_sXrw@mail.gmail.com>

I'll try the workaround. I do not believe I'm missing the headers.

Thanks a lot!

Renann Prado

On Thu, Feb 4, 2016 at 9:24 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> I've replied at the issue; I think you are running into
> https://issues.jboss.org/browse/RESTEASY-1264 which also describes a
> work-around.
>
> --Gunnar
>
>
> 2016-02-04 0:38 GMT+01:00 Renann Prado <darkness.renann at gmail.com>:
> > Hi, guys.
> >
> > I'd like to know if there is any workaround for this issue:
> >
> > https://issues.jboss.org/browse/WFLY-6097
> >
> > Thanks!
> >
> > Renann Prado
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160204/38c93c3d/attachment.html 

From rory.odonnell at oracle.com  Mon Feb  8 07:44:06 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 8 Feb 2016 12:44:06 +0000
Subject: [wildfly-dev] Early Access builds of JDK 8u76 b04,
 JDK 9 & JDK 9 with Project Jigsaw b104 are available on java.net
Message-ID: <56B88D96.3070703@oracle.com>


Hi Jason/Tomaz,

Early Access b04 <https://jdk8.java.net/download.html> for JDK 8u76 is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/jdk8u76/changes/jdk8u76-b04.html>.

Early Access b104 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/jdk9/changes/jdk-9+104.html>.

JEP 280: Indify String Concatenation [0]

This JEP proposed to change the static |String|-concatenation bytecode 
sequence generated by |javac| to use |invokedynamic| calls to JDK 
library functions. This will enable future optimizations of |String| 
concatenation without requiring further changes to the bytecode emitted 
by |javac|.

Early Access b104 <https://jdk9.java.net/jigsaw/> for JDK 9 with Project 
Jigsaw is available on java.net.

Great to meet so many of you at FOSDEM this year,  videos of some of the 
presentations are available [1]

Rgds,Rory

[0] http://openjdk.java.net/jeps/280
[1] http://video.fosdem.org/2016/h1301

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160208/f3937994/attachment.html 

From david.lloyd at redhat.com  Tue Feb  9 09:41:24 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 9 Feb 2016 08:41:24 -0600
Subject: [wildfly-dev] The EJB client and remote JTA transaction
 propagation
In-Reply-To: <CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
	<56B0B405.40600@redhat.com>
	<CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>
Message-ID: <56B9FA94.4070405@redhat.com>

I have a follow-up question about delaying enlistment (I'm getting to 
this point in the code).

I'm worried about a scenario wherein the subordinate server begins the 
transaction, does some work in the EJB, and then tries to return, but 
the connection to the server has been partitioned indefinitely.  The 
server *may* opt to continue and commit the transaction despite the 
subordinate failure, in which case the subordinate, not receiving any 
control messages from the root coordinator, would roll back the 
transaction at the timeout, while the server (not knowing about the 
subordinate server) would continue and commit the transaction, not 
knowing what work (if any) the subordinate server had performed.

Is this a real problem?  Perhaps I do need an "enlist me" callback to 
the server after all, which executes before the EJB imports and resumes 
the subordinate transaction?

On 02/02/2016 08:27 AM, Tom Jenkinson wrote:
> No problem :)
>
> On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com> wrote:
>
>> Ah okay, cool.  This is an easy (and, in hindsight, rather obvious)
>> enhancement that I can build into the new protocol with a minimum of effort.
>>
>> Thanks!
>>
>> On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
>>
>>> Hi David,
>>>
>>> I was referring to case 1 when the transaction is inflowed into a second
>>> server. For JTS the type of transaction we create is a
>>> ServerTopLevelAction and this in its ctor calls back to the remote server:
>>>
>>> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
>>> If the transport can do that without the TMs assistance then that works
>>> for me :)
>>>
>>> I don't think we should optimize for case 2. The incidents where a
>>> transaction is created and not used should be really low.
>>>
>>> Thanks,
>>> Tom
>>>
>>>
>>>
>>> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>
>>>      I was thinking about this a bit.  It seems to me that there are two
>>>      "levels" of this that could be explored:
>>>
>>>      1. A transaction was made available to the server, but the EJB on
>>>      the server does not use the caller's transaction context, so the EJB
>>>      code never actually has to inflow the transaction.  The EJB code
>>>      would be able to make this determination without any help from the TM.
>>>
>>>      2. A transaction was made available, and the EJB resumed it, but no
>>>      resources were actually enlisted, or perhaps resources were enlisted
>>>      but not actually used, resulting in the same effect but relying on
>>>      the TM to provide this information.
>>>
>>>      I guess when you refer to a callback from Narayana, (2) is what
>>>      you're referring to?  When would this information be available?
>>>      Maybe as some special result of suspending the transaction?
>>>
>>>
>>>      On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>>>
>>>          That's an interesting idea.  So in effect, the remote EJB would
>>>          tell the
>>>          caller "you sent me a transaction ID, but in the end, I didn't
>>>          use it"?
>>>             I would need to think about how this might work in the
>>>          presence of
>>>          multiple concurrent invocations on the same transaction.
>>>
>>>          Either way though, I think it would still be beneficial for
>>>          clients to
>>>          be able to explicitly annotate a client method (or otherwise
>>>          establish a
>>>          policy) such that it causes transactions to be propagated (or
>>>          not), or
>>>          to enforce transaction-related preconditions.  The interceptor
>>> that
>>>          implements this feature doesn't actually have protocol awareness:
>>> it
>>>          just examines the current environment, and decides whether to
>>>          attach the
>>>          transaction to the invocation context.
>>>
>>>          On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>>
>>>              One option that I would favour is to go down the JTS route
>>>              where the
>>>              subordinate calls back on the parent to tell it to register
>>>              it in the
>>>              transaction. This could be a new JBoss Remoting API that I
>>>              can invoke
>>>              from Narayana. The call would not necessarily be a remote
>>>              call, it would
>>>              invoke back into the JBR transport to tell it that when it
>>>              returns to
>>>              the parent it needs to enlist (or not).
>>>
>>>              On 29 January 2016 at 15:47, David M. Lloyd
>>>              <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>>>              <mailto:david.lloyd at redhat.com
>>>
>>>              <mailto:david.lloyd at redhat.com>>> wrote:
>>>
>>>                   As you may know, WildFly supports a feature wherein an
>>>              EJB client
>>>              which
>>>                   is invoking an EJB on a remote server has the option to
>>>              propagate its
>>>                   local transaction to the remote server, treating the
>>>              remote server
>>>              as a
>>>                   subordinate and coordinating the transaction's
>>>              two-phase commit among
>>>                   the resultant graph of servers.  This feature has
>>>              always been
>>>              limited in
>>>                   that, when enabled, transactions are always propagated,
>>>              regardless of
>>>                   the peer EJB's transaction policy, or of whether the
>>>              peer even has a
>>>                   transaction manager.
>>>
>>>                   So, for the invocation rework which I anticipate will
>>>              be included in
>>>                   WildFly 11, I've introduced a new client-side
>>>              annotation intended
>>>              to be
>>>                   associated with the EJB interface which informs the
>>>              client library
>>>              what
>>>                   to do for transaction propagation for that interface.
>>>              In addition, I
>>>                   intend to configuration strategies which will allow the
>>>              default
>>>              mode to
>>>                   be specified in various ways (per-thread, globally, and
>>>              by target
>>>                   interface/method all come to mind), for cases where the
>>>              EJB's remote
>>>                   interface cannot be easily modified for some reason.  I
>>>              expect to
>>>              also
>>>                   broaden these configuration strategies to apply to all
>>>              client-side
>>>              EJB
>>>                   interface/methods configuration items [3].
>>>
>>>                   The first part of this change is the addition of a new
>>>              annotation
>>>              called
>>>                   @ClientTransaction [1], which accepts as a value an
>>>              enum called
>>>                   ClientTransactionPolicy [2].  The latter specifies
>>>              whether a local
>>>                   transaction is required or forbidden for the method or
>>>              interface, and
>>>                   also specifies whether the transaction is propagated or
>>> not
>>>              propagated.
>>>
>>>                   I've added copious amounts of JavaDoc in order to
>>> establish
>>>              exactly what
>>>                   the behavior of each mode is, as well as to specify how
>>>              each mode
>>>                   interacts with the various modules that are configured
>>>              via the
>>>              standard
>>>                   javax.ejb.TransactionAttributeType enum.
>>>
>>>                   [1]
>>>
>>>
>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>>
>>>                   [2]
>>>
>>>
>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>
>>>                   [2] (raw)
>>>
>>>
>>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>
>>>                   [3] for a list, see:
>>>
>>>
>>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>>
>>>
>>>                   --
>>>                   - DML
>>>                   _______________________________________________
>>>                   wildfly-dev mailing list
>>>              wildfly-dev at lists.jboss.org
>>>              <mailto:wildfly-dev at lists.jboss.org>
>>>              <mailto:wildfly-dev at lists.jboss.org
>>>              <mailto:wildfly-dev at lists.jboss.org>>
>>>              https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>>
>>>      --
>>>      - DML
>>>
>>>
>>>
>> --
>> - DML
>>
>

-- 
- DML

From tom.jenkinson at redhat.com  Tue Feb  9 11:41:42 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 9 Feb 2016 16:41:42 +0000
Subject: [wildfly-dev] The EJB client and remote JTA transaction
	propagation
In-Reply-To: <56B9FA94.4070405@redhat.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
	<56B0B405.40600@redhat.com>
	<CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>
	<56B9FA94.4070405@redhat.com>
Message-ID: <CALaezvXc5_cRb-MjfGG_L7EwsgftjFZUEZVo7yryUSsWp2jjCQ@mail.gmail.com>

My understanding would be that the EJB transport would detect the
transaction.commit call (although it should have an outstanding EJB call so
I don't think that it would be possible for a client to call commit) and
throw an exception. It could be that EJB transport would register a
synchronization beforeCompletion to do this.

On 9 February 2016 at 14:41, David M. Lloyd <david.lloyd at redhat.com> wrote:

> I have a follow-up question about delaying enlistment (I'm getting to this
> point in the code).
>
> I'm worried about a scenario wherein the subordinate server begins the
> transaction, does some work in the EJB, and then tries to return, but the
> connection to the server has been partitioned indefinitely.  The server
> *may* opt to continue and commit the transaction despite the subordinate
> failure, in which case the subordinate, not receiving any control messages
> from the root coordinator, would roll back the transaction at the timeout,
> while the server (not knowing about the subordinate server) would continue
> and commit the transaction, not knowing what work (if any) the subordinate
> server had performed.
>
> Is this a real problem?  Perhaps I do need an "enlist me" callback to the
> server after all, which executes before the EJB imports and resumes the
> subordinate transaction?
>
>
> On 02/02/2016 08:27 AM, Tom Jenkinson wrote:
>
>> No problem :)
>>
>> On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>> Ah okay, cool.  This is an easy (and, in hindsight, rather obvious)
>>> enhancement that I can build into the new protocol with a minimum of
>>> effort.
>>>
>>> Thanks!
>>>
>>> On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
>>>
>>> Hi David,
>>>>
>>>> I was referring to case 1 when the transaction is inflowed into a second
>>>> server. For JTS the type of transaction we create is a
>>>> ServerTopLevelAction and this in its ctor calls back to the remote
>>>> server:
>>>>
>>>>
>>>> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
>>>> If the transport can do that without the TMs assistance then that works
>>>> for me :)
>>>>
>>>> I don't think we should optimize for case 2. The incidents where a
>>>> transaction is created and not used should be really low.
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>>
>>>>
>>>> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
>>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>>
>>>>      I was thinking about this a bit.  It seems to me that there are two
>>>>      "levels" of this that could be explored:
>>>>
>>>>      1. A transaction was made available to the server, but the EJB on
>>>>      the server does not use the caller's transaction context, so the
>>>> EJB
>>>>      code never actually has to inflow the transaction.  The EJB code
>>>>      would be able to make this determination without any help from the
>>>> TM.
>>>>
>>>>      2. A transaction was made available, and the EJB resumed it, but no
>>>>      resources were actually enlisted, or perhaps resources were
>>>> enlisted
>>>>      but not actually used, resulting in the same effect but relying on
>>>>      the TM to provide this information.
>>>>
>>>>      I guess when you refer to a callback from Narayana, (2) is what
>>>>      you're referring to?  When would this information be available?
>>>>      Maybe as some special result of suspending the transaction?
>>>>
>>>>
>>>>      On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>>>>
>>>>          That's an interesting idea.  So in effect, the remote EJB would
>>>>          tell the
>>>>          caller "you sent me a transaction ID, but in the end, I didn't
>>>>          use it"?
>>>>             I would need to think about how this might work in the
>>>>          presence of
>>>>          multiple concurrent invocations on the same transaction.
>>>>
>>>>          Either way though, I think it would still be beneficial for
>>>>          clients to
>>>>          be able to explicitly annotate a client method (or otherwise
>>>>          establish a
>>>>          policy) such that it causes transactions to be propagated (or
>>>>          not), or
>>>>          to enforce transaction-related preconditions.  The interceptor
>>>> that
>>>>          implements this feature doesn't actually have protocol
>>>> awareness:
>>>> it
>>>>          just examines the current environment, and decides whether to
>>>>          attach the
>>>>          transaction to the invocation context.
>>>>
>>>>          On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>>>
>>>>              One option that I would favour is to go down the JTS route
>>>>              where the
>>>>              subordinate calls back on the parent to tell it to register
>>>>              it in the
>>>>              transaction. This could be a new JBoss Remoting API that I
>>>>              can invoke
>>>>              from Narayana. The call would not necessarily be a remote
>>>>              call, it would
>>>>              invoke back into the JBR transport to tell it that when it
>>>>              returns to
>>>>              the parent it needs to enlist (or not).
>>>>
>>>>              On 29 January 2016 at 15:47, David M. Lloyd
>>>>              <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>>>>              <mailto:david.lloyd at redhat.com
>>>>
>>>>              <mailto:david.lloyd at redhat.com>>> wrote:
>>>>
>>>>                   As you may know, WildFly supports a feature wherein an
>>>>              EJB client
>>>>              which
>>>>                   is invoking an EJB on a remote server has the option
>>>> to
>>>>              propagate its
>>>>                   local transaction to the remote server, treating the
>>>>              remote server
>>>>              as a
>>>>                   subordinate and coordinating the transaction's
>>>>              two-phase commit among
>>>>                   the resultant graph of servers.  This feature has
>>>>              always been
>>>>              limited in
>>>>                   that, when enabled, transactions are always
>>>> propagated,
>>>>              regardless of
>>>>                   the peer EJB's transaction policy, or of whether the
>>>>              peer even has a
>>>>                   transaction manager.
>>>>
>>>>                   So, for the invocation rework which I anticipate will
>>>>              be included in
>>>>                   WildFly 11, I've introduced a new client-side
>>>>              annotation intended
>>>>              to be
>>>>                   associated with the EJB interface which informs the
>>>>              client library
>>>>              what
>>>>                   to do for transaction propagation for that interface.
>>>>              In addition, I
>>>>                   intend to configuration strategies which will allow
>>>> the
>>>>              default
>>>>              mode to
>>>>                   be specified in various ways (per-thread, globally,
>>>> and
>>>>              by target
>>>>                   interface/method all come to mind), for cases where
>>>> the
>>>>              EJB's remote
>>>>                   interface cannot be easily modified for some reason.
>>>> I
>>>>              expect to
>>>>              also
>>>>                   broaden these configuration strategies to apply to all
>>>>              client-side
>>>>              EJB
>>>>                   interface/methods configuration items [3].
>>>>
>>>>                   The first part of this change is the addition of a new
>>>>              annotation
>>>>              called
>>>>                   @ClientTransaction [1], which accepts as a value an
>>>>              enum called
>>>>                   ClientTransactionPolicy [2].  The latter specifies
>>>>              whether a local
>>>>                   transaction is required or forbidden for the method or
>>>>              interface, and
>>>>                   also specifies whether the transaction is propagated
>>>> or
>>>> not
>>>>              propagated.
>>>>
>>>>                   I've added copious amounts of JavaDoc in order to
>>>> establish
>>>>              exactly what
>>>>                   the behavior of each mode is, as well as to specify
>>>> how
>>>>              each mode
>>>>                   interacts with the various modules that are configured
>>>>              via the
>>>>              standard
>>>>                   javax.ejb.TransactionAttributeType enum.
>>>>
>>>>                   [1]
>>>>
>>>>
>>>>
>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>>>
>>>>                   [2]
>>>>
>>>>
>>>>
>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>
>>>>                   [2] (raw)
>>>>
>>>>
>>>>
>>>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>
>>>>                   [3] for a list, see:
>>>>
>>>>
>>>>
>>>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>>>
>>>>
>>>>                   --
>>>>                   - DML
>>>>                   _______________________________________________
>>>>                   wildfly-dev mailing list
>>>>              wildfly-dev at lists.jboss.org
>>>>              <mailto:wildfly-dev at lists.jboss.org>
>>>>              <mailto:wildfly-dev at lists.jboss.org
>>>>              <mailto:wildfly-dev at lists.jboss.org>>
>>>>              https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>      --
>>>>      - DML
>>>>
>>>>
>>>>
>>>> --
>>> - DML
>>>
>>>
>>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160209/3a776901/attachment-0001.html 

From david.lloyd at redhat.com  Tue Feb  9 11:50:18 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 9 Feb 2016 10:50:18 -0600
Subject: [wildfly-dev] The EJB client and remote JTA transaction
 propagation
In-Reply-To: <CALaezvXc5_cRb-MjfGG_L7EwsgftjFZUEZVo7yryUSsWp2jjCQ@mail.gmail.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
	<56B0B405.40600@redhat.com>
	<CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>
	<56B9FA94.4070405@redhat.com>
	<CALaezvXc5_cRb-MjfGG_L7EwsgftjFZUEZVo7yryUSsWp2jjCQ@mail.gmail.com>
Message-ID: <56BA18CA.5030008@redhat.com>

I think you misunderstood what I"m getting at.  Consider this normal 
sequence of events under the proposed enlistment strategy:

System1 creates a new transaction
System1 invokes EJB1 on System2 with XID1
System2 examines EJB1's transaction mode
System2 inflows XID1
System2 executes EJB1
System2 returns with "EnlistMe" flag
System1 enlists System2
...other work happens...
System1 prepares XID1
System2 prepares XID1 & returns XA_OK
System1 commits
System2 commits

Now what happens if the System1-System2 connection is broken before EJB1 
returns?  System2 is never enlisted, System1 may prepare & commit the 
XID1 transaction without ever knowing about System2, which now has an 
orphaned transaction which has performed some unknown amount of work 
under the same GTID as the now-committed transaction.  System2's 
transaction times out, the work is rolled back, and chaos ensues.

So this means that I have to have System2 tell System1 to enlist 
*before* "System2 executes EJB1" rather than after, right?

On 02/09/2016 10:41 AM, Tom Jenkinson wrote:
> My understanding would be that the EJB transport would detect the
> transaction.commit call (although it should have an outstanding EJB call so
> I don't think that it would be possible for a client to call commit) and
> throw an exception. It could be that EJB transport would register a
> synchronization beforeCompletion to do this.
>
> On 9 February 2016 at 14:41, David M. Lloyd <david.lloyd at redhat.com> wrote:
>
>> I have a follow-up question about delaying enlistment (I'm getting to this
>> point in the code).
>>
>> I'm worried about a scenario wherein the subordinate server begins the
>> transaction, does some work in the EJB, and then tries to return, but the
>> connection to the server has been partitioned indefinitely.  The server
>> *may* opt to continue and commit the transaction despite the subordinate
>> failure, in which case the subordinate, not receiving any control messages
>> from the root coordinator, would roll back the transaction at the timeout,
>> while the server (not knowing about the subordinate server) would continue
>> and commit the transaction, not knowing what work (if any) the subordinate
>> server had performed.
>>
>> Is this a real problem?  Perhaps I do need an "enlist me" callback to the
>> server after all, which executes before the EJB imports and resumes the
>> subordinate transaction?
>>
>>
>> On 02/02/2016 08:27 AM, Tom Jenkinson wrote:
>>
>>> No problem :)
>>>
>>> On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com>
>>> wrote:
>>>
>>> Ah okay, cool.  This is an easy (and, in hindsight, rather obvious)
>>>> enhancement that I can build into the new protocol with a minimum of
>>>> effort.
>>>>
>>>> Thanks!
>>>>
>>>> On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
>>>>
>>>> Hi David,
>>>>>
>>>>> I was referring to case 1 when the transaction is inflowed into a second
>>>>> server. For JTS the type of transaction we create is a
>>>>> ServerTopLevelAction and this in its ctor calls back to the remote
>>>>> server:
>>>>>
>>>>>
>>>>> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
>>>>> If the transport can do that without the TMs assistance then that works
>>>>> for me :)
>>>>>
>>>>> I don't think we should optimize for case 2. The incidents where a
>>>>> transaction is created and not used should be really low.
>>>>>
>>>>> Thanks,
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
>>>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>>>
>>>>>       I was thinking about this a bit.  It seems to me that there are two
>>>>>       "levels" of this that could be explored:
>>>>>
>>>>>       1. A transaction was made available to the server, but the EJB on
>>>>>       the server does not use the caller's transaction context, so the
>>>>> EJB
>>>>>       code never actually has to inflow the transaction.  The EJB code
>>>>>       would be able to make this determination without any help from the
>>>>> TM.
>>>>>
>>>>>       2. A transaction was made available, and the EJB resumed it, but no
>>>>>       resources were actually enlisted, or perhaps resources were
>>>>> enlisted
>>>>>       but not actually used, resulting in the same effect but relying on
>>>>>       the TM to provide this information.
>>>>>
>>>>>       I guess when you refer to a callback from Narayana, (2) is what
>>>>>       you're referring to?  When would this information be available?
>>>>>       Maybe as some special result of suspending the transaction?
>>>>>
>>>>>
>>>>>       On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>>>>>
>>>>>           That's an interesting idea.  So in effect, the remote EJB would
>>>>>           tell the
>>>>>           caller "you sent me a transaction ID, but in the end, I didn't
>>>>>           use it"?
>>>>>              I would need to think about how this might work in the
>>>>>           presence of
>>>>>           multiple concurrent invocations on the same transaction.
>>>>>
>>>>>           Either way though, I think it would still be beneficial for
>>>>>           clients to
>>>>>           be able to explicitly annotate a client method (or otherwise
>>>>>           establish a
>>>>>           policy) such that it causes transactions to be propagated (or
>>>>>           not), or
>>>>>           to enforce transaction-related preconditions.  The interceptor
>>>>> that
>>>>>           implements this feature doesn't actually have protocol
>>>>> awareness:
>>>>> it
>>>>>           just examines the current environment, and decides whether to
>>>>>           attach the
>>>>>           transaction to the invocation context.
>>>>>
>>>>>           On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>>>>
>>>>>               One option that I would favour is to go down the JTS route
>>>>>               where the
>>>>>               subordinate calls back on the parent to tell it to register
>>>>>               it in the
>>>>>               transaction. This could be a new JBoss Remoting API that I
>>>>>               can invoke
>>>>>               from Narayana. The call would not necessarily be a remote
>>>>>               call, it would
>>>>>               invoke back into the JBR transport to tell it that when it
>>>>>               returns to
>>>>>               the parent it needs to enlist (or not).
>>>>>
>>>>>               On 29 January 2016 at 15:47, David M. Lloyd
>>>>>               <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>>>>>               <mailto:david.lloyd at redhat.com
>>>>>
>>>>>               <mailto:david.lloyd at redhat.com>>> wrote:
>>>>>
>>>>>                    As you may know, WildFly supports a feature wherein an
>>>>>               EJB client
>>>>>               which
>>>>>                    is invoking an EJB on a remote server has the option
>>>>> to
>>>>>               propagate its
>>>>>                    local transaction to the remote server, treating the
>>>>>               remote server
>>>>>               as a
>>>>>                    subordinate and coordinating the transaction's
>>>>>               two-phase commit among
>>>>>                    the resultant graph of servers.  This feature has
>>>>>               always been
>>>>>               limited in
>>>>>                    that, when enabled, transactions are always
>>>>> propagated,
>>>>>               regardless of
>>>>>                    the peer EJB's transaction policy, or of whether the
>>>>>               peer even has a
>>>>>                    transaction manager.
>>>>>
>>>>>                    So, for the invocation rework which I anticipate will
>>>>>               be included in
>>>>>                    WildFly 11, I've introduced a new client-side
>>>>>               annotation intended
>>>>>               to be
>>>>>                    associated with the EJB interface which informs the
>>>>>               client library
>>>>>               what
>>>>>                    to do for transaction propagation for that interface.
>>>>>               In addition, I
>>>>>                    intend to configuration strategies which will allow
>>>>> the
>>>>>               default
>>>>>               mode to
>>>>>                    be specified in various ways (per-thread, globally,
>>>>> and
>>>>>               by target
>>>>>                    interface/method all come to mind), for cases where
>>>>> the
>>>>>               EJB's remote
>>>>>                    interface cannot be easily modified for some reason.
>>>>> I
>>>>>               expect to
>>>>>               also
>>>>>                    broaden these configuration strategies to apply to all
>>>>>               client-side
>>>>>               EJB
>>>>>                    interface/methods configuration items [3].
>>>>>
>>>>>                    The first part of this change is the addition of a new
>>>>>               annotation
>>>>>               called
>>>>>                    @ClientTransaction [1], which accepts as a value an
>>>>>               enum called
>>>>>                    ClientTransactionPolicy [2].  The latter specifies
>>>>>               whether a local
>>>>>                    transaction is required or forbidden for the method or
>>>>>               interface, and
>>>>>                    also specifies whether the transaction is propagated
>>>>> or
>>>>> not
>>>>>               propagated.
>>>>>
>>>>>                    I've added copious amounts of JavaDoc in order to
>>>>> establish
>>>>>               exactly what
>>>>>                    the behavior of each mode is, as well as to specify
>>>>> how
>>>>>               each mode
>>>>>                    interacts with the various modules that are configured
>>>>>               via the
>>>>>               standard
>>>>>                    javax.ejb.TransactionAttributeType enum.
>>>>>
>>>>>                    [1]
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>>>>
>>>>>                    [2]
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>>
>>>>>                    [2] (raw)
>>>>>
>>>>>
>>>>>
>>>>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>>
>>>>>                    [3] for a list, see:
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>>>>
>>>>>
>>>>>                    --
>>>>>                    - DML
>>>>>                    _______________________________________________
>>>>>                    wildfly-dev mailing list
>>>>>               wildfly-dev at lists.jboss.org
>>>>>               <mailto:wildfly-dev at lists.jboss.org>
>>>>>               <mailto:wildfly-dev at lists.jboss.org
>>>>>               <mailto:wildfly-dev at lists.jboss.org>>
>>>>>               https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       --
>>>>>       - DML
>>>>>
>>>>>
>>>>>
>>>>> --
>>>> - DML
>>>>
>>>>
>>>
>> --
>> - DML
>>
>

-- 
- DML

From tom.jenkinson at redhat.com  Tue Feb  9 12:07:58 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 9 Feb 2016 17:07:58 +0000
Subject: [wildfly-dev] The EJB client and remote JTA transaction
	propagation
In-Reply-To: <56BA18CA.5030008@redhat.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
	<56B0B405.40600@redhat.com>
	<CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>
	<56B9FA94.4070405@redhat.com>
	<CALaezvXc5_cRb-MjfGG_L7EwsgftjFZUEZVo7yryUSsWp2jjCQ@mail.gmail.com>
	<56BA18CA.5030008@redhat.com>
Message-ID: <CALaezvVd5Wp7dRbH7Bqcf7esRY_9scmuaZ1C_Ky_J9Ys5kk4VA@mail.gmail.com>

I understood what you said but didn't communicate my suggestion clearly
enough sorry.

System1 creates a new transaction
System1 registers a synchronization SYNC1 on transaction to record soon to
be pending request for System2 *** NEW BIT
System1 invokes EJB1 on System2 with XID1
System2 examines EJB1's transaction mode
System2 inflows XID1
System2 executes EJB1
System2 returns with "EnlistMe" flag
System1 updates SYNC1 to say the call returned *** NEW BIT
System1 enlists System2
...other work happens...
System1 prepares XID1
System2 prepares XID1 & returns XA_OK
System1 commits
System2 commits

If the failure happens before EJB1 returns then SYNC1 throws an exception
during beforeCompletion.

On 9 February 2016 at 16:50, David M. Lloyd <david.lloyd at redhat.com> wrote:

> I think you misunderstood what I"m getting at.  Consider this normal
> sequence of events under the proposed enlistment strategy:
>
> System1 creates a new transaction
> System1 invokes EJB1 on System2 with XID1
> System2 examines EJB1's transaction mode
> System2 inflows XID1
> System2 executes EJB1
> System2 returns with "EnlistMe" flag
> System1 enlists System2
> ...other work happens...
> System1 prepares XID1
> System2 prepares XID1 & returns XA_OK
> System1 commits
> System2 commits
>
> Now what happens if the System1-System2 connection is broken before EJB1
> returns?  System2 is never enlisted, System1 may prepare & commit the XID1
> transaction without ever knowing about System2, which now has an orphaned
> transaction which has performed some unknown amount of work under the same
> GTID as the now-committed transaction.  System2's transaction times out,
> the work is rolled back, and chaos ensues.
>
> So this means that I have to have System2 tell System1 to enlist *before*
> "System2 executes EJB1" rather than after, right?
>
>
> On 02/09/2016 10:41 AM, Tom Jenkinson wrote:
>
>> My understanding would be that the EJB transport would detect the
>> transaction.commit call (although it should have an outstanding EJB call
>> so
>> I don't think that it would be possible for a client to call commit) and
>> throw an exception. It could be that EJB transport would register a
>> synchronization beforeCompletion to do this.
>>
>> On 9 February 2016 at 14:41, David M. Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>> I have a follow-up question about delaying enlistment (I'm getting to this
>>> point in the code).
>>>
>>> I'm worried about a scenario wherein the subordinate server begins the
>>> transaction, does some work in the EJB, and then tries to return, but the
>>> connection to the server has been partitioned indefinitely.  The server
>>> *may* opt to continue and commit the transaction despite the subordinate
>>> failure, in which case the subordinate, not receiving any control
>>> messages
>>> from the root coordinator, would roll back the transaction at the
>>> timeout,
>>> while the server (not knowing about the subordinate server) would
>>> continue
>>> and commit the transaction, not knowing what work (if any) the
>>> subordinate
>>> server had performed.
>>>
>>> Is this a real problem?  Perhaps I do need an "enlist me" callback to the
>>> server after all, which executes before the EJB imports and resumes the
>>> subordinate transaction?
>>>
>>>
>>> On 02/02/2016 08:27 AM, Tom Jenkinson wrote:
>>>
>>> No problem :)
>>>>
>>>> On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com>
>>>> wrote:
>>>>
>>>> Ah okay, cool.  This is an easy (and, in hindsight, rather obvious)
>>>>
>>>>> enhancement that I can build into the new protocol with a minimum of
>>>>> effort.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
>>>>>
>>>>> Hi David,
>>>>>
>>>>>>
>>>>>> I was referring to case 1 when the transaction is inflowed into a
>>>>>> second
>>>>>> server. For JTS the type of transaction we create is a
>>>>>> ServerTopLevelAction and this in its ctor calls back to the remote
>>>>>> server:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
>>>>>> If the transport can do that without the TMs assistance then that
>>>>>> works
>>>>>> for me :)
>>>>>>
>>>>>> I don't think we should optimize for case 2. The incidents where a
>>>>>> transaction is created and not used should be really low.
>>>>>>
>>>>>> Thanks,
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
>>>>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>>>>
>>>>>>       I was thinking about this a bit.  It seems to me that there are
>>>>>> two
>>>>>>       "levels" of this that could be explored:
>>>>>>
>>>>>>       1. A transaction was made available to the server, but the EJB
>>>>>> on
>>>>>>       the server does not use the caller's transaction context, so the
>>>>>> EJB
>>>>>>       code never actually has to inflow the transaction.  The EJB code
>>>>>>       would be able to make this determination without any help from
>>>>>> the
>>>>>> TM.
>>>>>>
>>>>>>       2. A transaction was made available, and the EJB resumed it,
>>>>>> but no
>>>>>>       resources were actually enlisted, or perhaps resources were
>>>>>> enlisted
>>>>>>       but not actually used, resulting in the same effect but relying
>>>>>> on
>>>>>>       the TM to provide this information.
>>>>>>
>>>>>>       I guess when you refer to a callback from Narayana, (2) is what
>>>>>>       you're referring to?  When would this information be available?
>>>>>>       Maybe as some special result of suspending the transaction?
>>>>>>
>>>>>>
>>>>>>       On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>>>>>>
>>>>>>           That's an interesting idea.  So in effect, the remote EJB
>>>>>> would
>>>>>>           tell the
>>>>>>           caller "you sent me a transaction ID, but in the end, I
>>>>>> didn't
>>>>>>           use it"?
>>>>>>              I would need to think about how this might work in the
>>>>>>           presence of
>>>>>>           multiple concurrent invocations on the same transaction.
>>>>>>
>>>>>>           Either way though, I think it would still be beneficial for
>>>>>>           clients to
>>>>>>           be able to explicitly annotate a client method (or otherwise
>>>>>>           establish a
>>>>>>           policy) such that it causes transactions to be propagated
>>>>>> (or
>>>>>>           not), or
>>>>>>           to enforce transaction-related preconditions.  The
>>>>>> interceptor
>>>>>> that
>>>>>>           implements this feature doesn't actually have protocol
>>>>>> awareness:
>>>>>> it
>>>>>>           just examines the current environment, and decides whether
>>>>>> to
>>>>>>           attach the
>>>>>>           transaction to the invocation context.
>>>>>>
>>>>>>           On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>>>>>
>>>>>>               One option that I would favour is to go down the JTS
>>>>>> route
>>>>>>               where the
>>>>>>               subordinate calls back on the parent to tell it to
>>>>>> register
>>>>>>               it in the
>>>>>>               transaction. This could be a new JBoss Remoting API
>>>>>> that I
>>>>>>               can invoke
>>>>>>               from Narayana. The call would not necessarily be a
>>>>>> remote
>>>>>>               call, it would
>>>>>>               invoke back into the JBR transport to tell it that when
>>>>>> it
>>>>>>               returns to
>>>>>>               the parent it needs to enlist (or not).
>>>>>>
>>>>>>               On 29 January 2016 at 15:47, David M. Lloyd
>>>>>>               <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>>>>>>               <mailto:david.lloyd at redhat.com
>>>>>>
>>>>>>               <mailto:david.lloyd at redhat.com>>> wrote:
>>>>>>
>>>>>>                    As you may know, WildFly supports a feature
>>>>>> wherein an
>>>>>>               EJB client
>>>>>>               which
>>>>>>                    is invoking an EJB on a remote server has the
>>>>>> option
>>>>>> to
>>>>>>               propagate its
>>>>>>                    local transaction to the remote server, treating
>>>>>> the
>>>>>>               remote server
>>>>>>               as a
>>>>>>                    subordinate and coordinating the transaction's
>>>>>>               two-phase commit among
>>>>>>                    the resultant graph of servers.  This feature has
>>>>>>               always been
>>>>>>               limited in
>>>>>>                    that, when enabled, transactions are always
>>>>>> propagated,
>>>>>>               regardless of
>>>>>>                    the peer EJB's transaction policy, or of whether
>>>>>> the
>>>>>>               peer even has a
>>>>>>                    transaction manager.
>>>>>>
>>>>>>                    So, for the invocation rework which I anticipate
>>>>>> will
>>>>>>               be included in
>>>>>>                    WildFly 11, I've introduced a new client-side
>>>>>>               annotation intended
>>>>>>               to be
>>>>>>                    associated with the EJB interface which informs the
>>>>>>               client library
>>>>>>               what
>>>>>>                    to do for transaction propagation for that
>>>>>> interface.
>>>>>>               In addition, I
>>>>>>                    intend to configuration strategies which will allow
>>>>>> the
>>>>>>               default
>>>>>>               mode to
>>>>>>                    be specified in various ways (per-thread, globally,
>>>>>> and
>>>>>>               by target
>>>>>>                    interface/method all come to mind), for cases where
>>>>>> the
>>>>>>               EJB's remote
>>>>>>                    interface cannot be easily modified for some
>>>>>> reason.
>>>>>> I
>>>>>>               expect to
>>>>>>               also
>>>>>>                    broaden these configuration strategies to apply to
>>>>>> all
>>>>>>               client-side
>>>>>>               EJB
>>>>>>                    interface/methods configuration items [3].
>>>>>>
>>>>>>                    The first part of this change is the addition of a
>>>>>> new
>>>>>>               annotation
>>>>>>               called
>>>>>>                    @ClientTransaction [1], which accepts as a value an
>>>>>>               enum called
>>>>>>                    ClientTransactionPolicy [2].  The latter specifies
>>>>>>               whether a local
>>>>>>                    transaction is required or forbidden for the
>>>>>> method or
>>>>>>               interface, and
>>>>>>                    also specifies whether the transaction is
>>>>>> propagated
>>>>>> or
>>>>>> not
>>>>>>               propagated.
>>>>>>
>>>>>>                    I've added copious amounts of JavaDoc in order to
>>>>>> establish
>>>>>>               exactly what
>>>>>>                    the behavior of each mode is, as well as to specify
>>>>>> how
>>>>>>               each mode
>>>>>>                    interacts with the various modules that are
>>>>>> configured
>>>>>>               via the
>>>>>>               standard
>>>>>>                    javax.ejb.TransactionAttributeType enum.
>>>>>>
>>>>>>                    [1]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>>>>>
>>>>>>                    [2]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>>>
>>>>>>                    [2] (raw)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>>>
>>>>>>                    [3] for a list, see:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>>>>>
>>>>>>
>>>>>>                    --
>>>>>>                    - DML
>>>>>>                    _______________________________________________
>>>>>>                    wildfly-dev mailing list
>>>>>>               wildfly-dev at lists.jboss.org
>>>>>>               <mailto:wildfly-dev at lists.jboss.org>
>>>>>>               <mailto:wildfly-dev at lists.jboss.org
>>>>>>               <mailto:wildfly-dev at lists.jboss.org>>
>>>>>>               https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>       --
>>>>>>       - DML
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> - DML
>>>>>
>>>>>
>>>>>
>>>> --
>>> - DML
>>>
>>>
>>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160209/d6fdebc7/attachment-0001.html 

From david.lloyd at redhat.com  Tue Feb  9 12:25:15 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 9 Feb 2016 11:25:15 -0600
Subject: [wildfly-dev] The EJB client and remote JTA transaction
 propagation
In-Reply-To: <CALaezvVd5Wp7dRbH7Bqcf7esRY_9scmuaZ1C_Ky_J9Ys5kk4VA@mail.gmail.com>
References: <56AB899A.1050000@redhat.com>
	<CALaezvU8L3TBAHWrWRm7yc261atRbo=F8WWozEWzvgM5W1L-sg@mail.gmail.com>
	<56ABAF04.2070305@redhat.com> <56AF7D26.4030807@redhat.com>
	<CALaezvXsci8BxFnvUizQ6Foj23RVP3gLOXoOdN=SAazckWvm7g@mail.gmail.com>
	<56B0B405.40600@redhat.com>
	<CALaezvUn0oESh1JOsjoEj_gMLdw7URttXpxESJpiNYCh-M+Agw@mail.gmail.com>
	<56B9FA94.4070405@redhat.com>
	<CALaezvXc5_cRb-MjfGG_L7EwsgftjFZUEZVo7yryUSsWp2jjCQ@mail.gmail.com>
	<56BA18CA.5030008@redhat.com>
	<CALaezvVd5Wp7dRbH7Bqcf7esRY_9scmuaZ1C_Ky_J9Ys5kk4VA@mail.gmail.com>
Message-ID: <56BA20FB.2000605@redhat.com>

Ah, interesting! I will think some more about this.

On 02/09/2016 11:07 AM, Tom Jenkinson wrote:
> I understood what you said but didn't communicate my suggestion clearly
> enough sorry.
>
> System1 creates a new transaction
> System1 registers a synchronization SYNC1 on transaction to record soon to
> be pending request for System2 *** NEW BIT
> System1 invokes EJB1 on System2 with XID1
> System2 examines EJB1's transaction mode
> System2 inflows XID1
> System2 executes EJB1
> System2 returns with "EnlistMe" flag
> System1 updates SYNC1 to say the call returned *** NEW BIT
> System1 enlists System2
> ...other work happens...
> System1 prepares XID1
> System2 prepares XID1 & returns XA_OK
> System1 commits
> System2 commits
>
> If the failure happens before EJB1 returns then SYNC1 throws an exception
> during beforeCompletion.
>
> On 9 February 2016 at 16:50, David M. Lloyd <david.lloyd at redhat.com> wrote:
>
>> I think you misunderstood what I"m getting at.  Consider this normal
>> sequence of events under the proposed enlistment strategy:
>>
>> System1 creates a new transaction
>> System1 invokes EJB1 on System2 with XID1
>> System2 examines EJB1's transaction mode
>> System2 inflows XID1
>> System2 executes EJB1
>> System2 returns with "EnlistMe" flag
>> System1 enlists System2
>> ...other work happens...
>> System1 prepares XID1
>> System2 prepares XID1 & returns XA_OK
>> System1 commits
>> System2 commits
>>
>> Now what happens if the System1-System2 connection is broken before EJB1
>> returns?  System2 is never enlisted, System1 may prepare & commit the XID1
>> transaction without ever knowing about System2, which now has an orphaned
>> transaction which has performed some unknown amount of work under the same
>> GTID as the now-committed transaction.  System2's transaction times out,
>> the work is rolled back, and chaos ensues.
>>
>> So this means that I have to have System2 tell System1 to enlist *before*
>> "System2 executes EJB1" rather than after, right?
>>
>>
>> On 02/09/2016 10:41 AM, Tom Jenkinson wrote:
>>
>>> My understanding would be that the EJB transport would detect the
>>> transaction.commit call (although it should have an outstanding EJB call
>>> so
>>> I don't think that it would be possible for a client to call commit) and
>>> throw an exception. It could be that EJB transport would register a
>>> synchronization beforeCompletion to do this.
>>>
>>> On 9 February 2016 at 14:41, David M. Lloyd <david.lloyd at redhat.com>
>>> wrote:
>>>
>>> I have a follow-up question about delaying enlistment (I'm getting to this
>>>> point in the code).
>>>>
>>>> I'm worried about a scenario wherein the subordinate server begins the
>>>> transaction, does some work in the EJB, and then tries to return, but the
>>>> connection to the server has been partitioned indefinitely.  The server
>>>> *may* opt to continue and commit the transaction despite the subordinate
>>>> failure, in which case the subordinate, not receiving any control
>>>> messages
>>>> from the root coordinator, would roll back the transaction at the
>>>> timeout,
>>>> while the server (not knowing about the subordinate server) would
>>>> continue
>>>> and commit the transaction, not knowing what work (if any) the
>>>> subordinate
>>>> server had performed.
>>>>
>>>> Is this a real problem?  Perhaps I do need an "enlist me" callback to the
>>>> server after all, which executes before the EJB imports and resumes the
>>>> subordinate transaction?
>>>>
>>>>
>>>> On 02/02/2016 08:27 AM, Tom Jenkinson wrote:
>>>>
>>>> No problem :)
>>>>>
>>>>> On 2 February 2016 at 13:49, David M. Lloyd <david.lloyd at redhat.com>
>>>>> wrote:
>>>>>
>>>>> Ah okay, cool.  This is an easy (and, in hindsight, rather obvious)
>>>>>
>>>>>> enhancement that I can build into the new protocol with a minimum of
>>>>>> effort.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On 02/02/2016 03:01 AM, Tom Jenkinson wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>>>
>>>>>>> I was referring to case 1 when the transaction is inflowed into a
>>>>>>> second
>>>>>>> server. For JTS the type of transaction we create is a
>>>>>>> ServerTopLevelAction and this in its ctor calls back to the remote
>>>>>>> server:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/resources/arjuna/ServerTopLevelAction.java#L121
>>>>>>> If the transport can do that without the TMs assistance then that
>>>>>>> works
>>>>>>> for me :)
>>>>>>>
>>>>>>> I don't think we should optimize for case 2. The incidents where a
>>>>>>> transaction is created and not used should be really low.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1 February 2016 at 15:43, David M. Lloyd <david.lloyd at redhat.com
>>>>>>> <mailto:david.lloyd at redhat.com>> wrote:
>>>>>>>
>>>>>>>        I was thinking about this a bit.  It seems to me that there are
>>>>>>> two
>>>>>>>        "levels" of this that could be explored:
>>>>>>>
>>>>>>>        1. A transaction was made available to the server, but the EJB
>>>>>>> on
>>>>>>>        the server does not use the caller's transaction context, so the
>>>>>>> EJB
>>>>>>>        code never actually has to inflow the transaction.  The EJB code
>>>>>>>        would be able to make this determination without any help from
>>>>>>> the
>>>>>>> TM.
>>>>>>>
>>>>>>>        2. A transaction was made available, and the EJB resumed it,
>>>>>>> but no
>>>>>>>        resources were actually enlisted, or perhaps resources were
>>>>>>> enlisted
>>>>>>>        but not actually used, resulting in the same effect but relying
>>>>>>> on
>>>>>>>        the TM to provide this information.
>>>>>>>
>>>>>>>        I guess when you refer to a callback from Narayana, (2) is what
>>>>>>>        you're referring to?  When would this information be available?
>>>>>>>        Maybe as some special result of suspending the transaction?
>>>>>>>
>>>>>>>
>>>>>>>        On 01/29/2016 12:27 PM, David M. Lloyd wrote:
>>>>>>>
>>>>>>>            That's an interesting idea.  So in effect, the remote EJB
>>>>>>> would
>>>>>>>            tell the
>>>>>>>            caller "you sent me a transaction ID, but in the end, I
>>>>>>> didn't
>>>>>>>            use it"?
>>>>>>>               I would need to think about how this might work in the
>>>>>>>            presence of
>>>>>>>            multiple concurrent invocations on the same transaction.
>>>>>>>
>>>>>>>            Either way though, I think it would still be beneficial for
>>>>>>>            clients to
>>>>>>>            be able to explicitly annotate a client method (or otherwise
>>>>>>>            establish a
>>>>>>>            policy) such that it causes transactions to be propagated
>>>>>>> (or
>>>>>>>            not), or
>>>>>>>            to enforce transaction-related preconditions.  The
>>>>>>> interceptor
>>>>>>> that
>>>>>>>            implements this feature doesn't actually have protocol
>>>>>>> awareness:
>>>>>>> it
>>>>>>>            just examines the current environment, and decides whether
>>>>>>> to
>>>>>>>            attach the
>>>>>>>            transaction to the invocation context.
>>>>>>>
>>>>>>>            On 1/29/16 10:42 AM, Tom Jenkinson wrote:
>>>>>>>
>>>>>>>                One option that I would favour is to go down the JTS
>>>>>>> route
>>>>>>>                where the
>>>>>>>                subordinate calls back on the parent to tell it to
>>>>>>> register
>>>>>>>                it in the
>>>>>>>                transaction. This could be a new JBoss Remoting API
>>>>>>> that I
>>>>>>>                can invoke
>>>>>>>                from Narayana. The call would not necessarily be a
>>>>>>> remote
>>>>>>>                call, it would
>>>>>>>                invoke back into the JBR transport to tell it that when
>>>>>>> it
>>>>>>>                returns to
>>>>>>>                the parent it needs to enlist (or not).
>>>>>>>
>>>>>>>                On 29 January 2016 at 15:47, David M. Lloyd
>>>>>>>                <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>>>>>>>                <mailto:david.lloyd at redhat.com
>>>>>>>
>>>>>>>                <mailto:david.lloyd at redhat.com>>> wrote:
>>>>>>>
>>>>>>>                     As you may know, WildFly supports a feature
>>>>>>> wherein an
>>>>>>>                EJB client
>>>>>>>                which
>>>>>>>                     is invoking an EJB on a remote server has the
>>>>>>> option
>>>>>>> to
>>>>>>>                propagate its
>>>>>>>                     local transaction to the remote server, treating
>>>>>>> the
>>>>>>>                remote server
>>>>>>>                as a
>>>>>>>                     subordinate and coordinating the transaction's
>>>>>>>                two-phase commit among
>>>>>>>                     the resultant graph of servers.  This feature has
>>>>>>>                always been
>>>>>>>                limited in
>>>>>>>                     that, when enabled, transactions are always
>>>>>>> propagated,
>>>>>>>                regardless of
>>>>>>>                     the peer EJB's transaction policy, or of whether
>>>>>>> the
>>>>>>>                peer even has a
>>>>>>>                     transaction manager.
>>>>>>>
>>>>>>>                     So, for the invocation rework which I anticipate
>>>>>>> will
>>>>>>>                be included in
>>>>>>>                     WildFly 11, I've introduced a new client-side
>>>>>>>                annotation intended
>>>>>>>                to be
>>>>>>>                     associated with the EJB interface which informs the
>>>>>>>                client library
>>>>>>>                what
>>>>>>>                     to do for transaction propagation for that
>>>>>>> interface.
>>>>>>>                In addition, I
>>>>>>>                     intend to configuration strategies which will allow
>>>>>>> the
>>>>>>>                default
>>>>>>>                mode to
>>>>>>>                     be specified in various ways (per-thread, globally,
>>>>>>> and
>>>>>>>                by target
>>>>>>>                     interface/method all come to mind), for cases where
>>>>>>> the
>>>>>>>                EJB's remote
>>>>>>>                     interface cannot be easily modified for some
>>>>>>> reason.
>>>>>>> I
>>>>>>>                expect to
>>>>>>>                also
>>>>>>>                     broaden these configuration strategies to apply to
>>>>>>> all
>>>>>>>                client-side
>>>>>>>                EJB
>>>>>>>                     interface/methods configuration items [3].
>>>>>>>
>>>>>>>                     The first part of this change is the addition of a
>>>>>>> new
>>>>>>>                annotation
>>>>>>>                called
>>>>>>>                     @ClientTransaction [1], which accepts as a value an
>>>>>>>                enum called
>>>>>>>                     ClientTransactionPolicy [2].  The latter specifies
>>>>>>>                whether a local
>>>>>>>                     transaction is required or forbidden for the
>>>>>>> method or
>>>>>>>                interface, and
>>>>>>>                     also specifies whether the transaction is
>>>>>>> propagated
>>>>>>> or
>>>>>>> not
>>>>>>>                propagated.
>>>>>>>
>>>>>>>                     I've added copious amounts of JavaDoc in order to
>>>>>>> establish
>>>>>>>                exactly what
>>>>>>>                     the behavior of each mode is, as well as to specify
>>>>>>> how
>>>>>>>                each mode
>>>>>>>                     interacts with the various modules that are
>>>>>>> configured
>>>>>>>                via the
>>>>>>>                standard
>>>>>>>                     javax.ejb.TransactionAttributeType enum.
>>>>>>>
>>>>>>>                     [1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java
>>>>>>>
>>>>>>>                     [2]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>>>>
>>>>>>>                     [2] (raw)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java
>>>>>>>
>>>>>>>                     [3] for a list, see:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation
>>>>>>>
>>>>>>>
>>>>>>>                     --
>>>>>>>                     - DML
>>>>>>>                     _______________________________________________
>>>>>>>                     wildfly-dev mailing list
>>>>>>>                wildfly-dev at lists.jboss.org
>>>>>>>                <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>                <mailto:wildfly-dev at lists.jboss.org
>>>>>>>                <mailto:wildfly-dev at lists.jboss.org>>
>>>>>>>                https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>        --
>>>>>>>        - DML
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>> - DML
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>> - DML
>>>>
>>>>
>>>
>> --
>> - DML
>>
>

-- 
- DML

From smarlow at redhat.com  Thu Feb 11 11:03:39 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Feb 2016 11:03:39 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
Message-ID: <56BCB0DB.8030102@redhat.com>

As previously discussed, Hibernate applications need access to the 
Javassist runtime classes (see example [1] enhanced application entity 
if you didn't know this :).  A proposal was discussed on the 
hibernate-dev mailing list that I think is the best short term solution. 
  I wanted to raise this issue here also, as I would like to later 
create a pull request to bring in a new Hibernate ORM that includes this 
change.  So, getting early feedback before we create JIRAs for the work, 
is important.

The proposal is to private package (or shade), the Javassist classes, so 
that Hibernate ORM has its own copy of the Javassist classes.  On 
WildFly, we still would include Javassist for the other components that 
use it and for Hibernate applications that have "build-time enhanced 
entity classes" by an earlier Hibernate release.

One downside of this change is that Hibernate applications cannot easily 
switch to a different version of the Javassist classes.

Another downside is that applications that depend on an older Hibernate 
ORM version that includes "build-time enhanced entity classes", will 
need to be cracked open, to add dependencies on the Javassist module 
(since we will stop automatically adding Javassist to JPA application 
deployments).

The advantage of this change, is that Hibernate applications can include 
their own version of Javassist.

This will also have an impact on Hibernate build-time enhancing of 
entity classes (e.g. enhanced bytecode will no longer depend on the 
public Javassist classes).

Scott

[1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e

From jperkins at redhat.com  Thu Feb 11 14:42:18 2016
From: jperkins at redhat.com (James Perkins)
Date: Thu, 11 Feb 2016 11:42:18 -0800
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BCB0DB.8030102@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
Message-ID: <CADGwLpiQjO_hkvFJeTPue0S1KZ9fqShS7PbF6eT0Y2hiaxt4VQ@mail.gmail.com>

I don't recall the previous discussion, but is there a reason we couldn't
just use a JBoss module with a different slot?

On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow <smarlow at redhat.com> wrote:

> As previously discussed, Hibernate applications need access to the
> Javassist runtime classes (see example [1] enhanced application entity
> if you didn't know this :).  A proposal was discussed on the
> hibernate-dev mailing list that I think is the best short term solution.
>   I wanted to raise this issue here also, as I would like to later
> create a pull request to bring in a new Hibernate ORM that includes this
> change.  So, getting early feedback before we create JIRAs for the work,
> is important.
>
> The proposal is to private package (or shade), the Javassist classes, so
> that Hibernate ORM has its own copy of the Javassist classes.  On
> WildFly, we still would include Javassist for the other components that
> use it and for Hibernate applications that have "build-time enhanced
> entity classes" by an earlier Hibernate release.
>
> One downside of this change is that Hibernate applications cannot easily
> switch to a different version of the Javassist classes.
>
> Another downside is that applications that depend on an older Hibernate
> ORM version that includes "build-time enhanced entity classes", will
> need to be cracked open, to add dependencies on the Javassist module
> (since we will stop automatically adding Javassist to JPA application
> deployments).
>
> The advantage of this change, is that Hibernate applications can include
> their own version of Javassist.
>
> This will also have an impact on Hibernate build-time enhancing of
> entity classes (e.g. enhanced bytecode will no longer depend on the
> public Javassist classes).
>
> Scott
>
> [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/b00fb994/attachment.html 

From stuart.w.douglas at gmail.com  Thu Feb 11 14:55:49 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 11 Feb 2016 19:55:49 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CADGwLpiQjO_hkvFJeTPue0S1KZ9fqShS7PbF6eT0Y2hiaxt4VQ@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CADGwLpiQjO_hkvFJeTPue0S1KZ9fqShS7PbF6eT0Y2hiaxt4VQ@mail.gmail.com>
Message-ID: <CAAoo=c6kmjhxu=_7fTBuxExRpuST9a4bywxbeL+X2uA04U3Skg@mail.gmail.com>

On Fri, 12 Feb 2016 at 06:42 James Perkins <jperkins at redhat.com> wrote:

> I don't recall the previous discussion, but is there a reason we couldn't
> just use a JBoss module with a different slot?
>

Nah, the issue is that these classes need to be referenced by the
deployment and hibernate, so whatever version hibernate uses has to be the
one exposed to the deployment.

Stuart


>
> On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> As previously discussed, Hibernate applications need access to the
>> Javassist runtime classes (see example [1] enhanced application entity
>> if you didn't know this :).  A proposal was discussed on the
>> hibernate-dev mailing list that I think is the best short term solution.
>>   I wanted to raise this issue here also, as I would like to later
>> create a pull request to bring in a new Hibernate ORM that includes this
>> change.  So, getting early feedback before we create JIRAs for the work,
>> is important.
>>
>> The proposal is to private package (or shade), the Javassist classes, so
>> that Hibernate ORM has its own copy of the Javassist classes.  On
>> WildFly, we still would include Javassist for the other components that
>> use it and for Hibernate applications that have "build-time enhanced
>> entity classes" by an earlier Hibernate release.
>>
>> One downside of this change is that Hibernate applications cannot easily
>> switch to a different version of the Javassist classes.
>>
>> Another downside is that applications that depend on an older Hibernate
>> ORM version that includes "build-time enhanced entity classes", will
>> need to be cracked open, to add dependencies on the Javassist module
>> (since we will stop automatically adding Javassist to JPA application
>> deployments).
>>
>> The advantage of this change, is that Hibernate applications can include
>> their own version of Javassist.
>>
>> This will also have an impact on Hibernate build-time enhancing of
>> entity classes (e.g. enhanced bytecode will no longer depend on the
>> public Javassist classes).
>>
>> Scott
>>
>> [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/117dfccd/attachment-0001.html 

From jperkins at redhat.com  Thu Feb 11 14:58:54 2016
From: jperkins at redhat.com (James Perkins)
Date: Thu, 11 Feb 2016 11:58:54 -0800
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAAoo=c6kmjhxu=_7fTBuxExRpuST9a4bywxbeL+X2uA04U3Skg@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CADGwLpiQjO_hkvFJeTPue0S1KZ9fqShS7PbF6eT0Y2hiaxt4VQ@mail.gmail.com>
	<CAAoo=c6kmjhxu=_7fTBuxExRpuST9a4bywxbeL+X2uA04U3Skg@mail.gmail.com>
Message-ID: <CADGwLpho-SdbTf0FnQqnmw01Od9WGSOzHw3NdJo6b4=C9hCP2Q@mail.gmail.com>

Ah, got it. Makes sense then.

On Thu, Feb 11, 2016 at 11:55 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

>
>
> On Fri, 12 Feb 2016 at 06:42 James Perkins <jperkins at redhat.com> wrote:
>
>> I don't recall the previous discussion, but is there a reason we couldn't
>> just use a JBoss module with a different slot?
>>
>
> Nah, the issue is that these classes need to be referenced by the
> deployment and hibernate, so whatever version hibernate uses has to be the
> one exposed to the deployment.
>
> Stuart
>
>
>>
>> On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> As previously discussed, Hibernate applications need access to the
>>> Javassist runtime classes (see example [1] enhanced application entity
>>> if you didn't know this :).  A proposal was discussed on the
>>> hibernate-dev mailing list that I think is the best short term solution.
>>>   I wanted to raise this issue here also, as I would like to later
>>> create a pull request to bring in a new Hibernate ORM that includes this
>>> change.  So, getting early feedback before we create JIRAs for the work,
>>> is important.
>>>
>>> The proposal is to private package (or shade), the Javassist classes, so
>>> that Hibernate ORM has its own copy of the Javassist classes.  On
>>> WildFly, we still would include Javassist for the other components that
>>> use it and for Hibernate applications that have "build-time enhanced
>>> entity classes" by an earlier Hibernate release.
>>>
>>> One downside of this change is that Hibernate applications cannot easily
>>> switch to a different version of the Javassist classes.
>>>
>>> Another downside is that applications that depend on an older Hibernate
>>> ORM version that includes "build-time enhanced entity classes", will
>>> need to be cracked open, to add dependencies on the Javassist module
>>> (since we will stop automatically adding Javassist to JPA application
>>> deployments).
>>>
>>> The advantage of this change, is that Hibernate applications can include
>>> their own version of Javassist.
>>>
>>> This will also have an impact on Hibernate build-time enhancing of
>>> entity classes (e.g. enhanced bytecode will no longer depend on the
>>> public Javassist classes).
>>>
>>> Scott
>>>
>>> [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/8d7a3133/attachment.html 

From fnasser at redhat.com  Thu Feb 11 14:59:21 2016
From: fnasser at redhat.com (Fernando Nasser)
Date: Thu, 11 Feb 2016 14:59:21 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAAoo=c6kmjhxu=_7fTBuxExRpuST9a4bywxbeL+X2uA04U3Skg@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CADGwLpiQjO_hkvFJeTPue0S1KZ9fqShS7PbF6eT0Y2hiaxt4VQ@mail.gmail.com>
	<CAAoo=c6kmjhxu=_7fTBuxExRpuST9a4bywxbeL+X2uA04U3Skg@mail.gmail.com>
Message-ID: <56BCE819.90201@redhat.com>

On 2016-02-11 2:55 PM, Stuart Douglas wrote:
>
>
> On Fri, 12 Feb 2016 at 06:42 James Perkins <jperkins at redhat.com 
> <mailto:jperkins at redhat.com>> wrote:
>
>     I don't recall the previous discussion, but is there a reason we
>     couldn't just use a JBoss module with a different slot?
>
>
> Nah, the issue is that these classes need to be referenced by the 
> deployment and hibernate, so whatever version hibernate uses has to be 
> the one exposed to the deployment.
Can't we require that that alternative module is specified as a 
dependency for the hibernate deployments?

It does put the onus on the user but we already end up having to specify 
a few things for hibernate anyway.

Fernando


>
> Stuart
>
>
>     On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>         As previously discussed, Hibernate applications need access to the
>         Javassist runtime classes (see example [1] enhanced
>         application entity
>         if you didn't know this :).  A proposal was discussed on the
>         hibernate-dev mailing list that I think is the best short term
>         solution.
>           I wanted to raise this issue here also, as I would like to later
>         create a pull request to bring in a new Hibernate ORM that
>         includes this
>         change.  So, getting early feedback before we create JIRAs for
>         the work,
>         is important.
>
>         The proposal is to private package (or shade), the Javassist
>         classes, so
>         that Hibernate ORM has its own copy of the Javassist classes.  On
>         WildFly, we still would include Javassist for the other
>         components that
>         use it and for Hibernate applications that have "build-time
>         enhanced
>         entity classes" by an earlier Hibernate release.
>
>         One downside of this change is that Hibernate applications
>         cannot easily
>         switch to a different version of the Javassist classes.
>
>         Another downside is that applications that depend on an older
>         Hibernate
>         ORM version that includes "build-time enhanced entity
>         classes", will
>         need to be cracked open, to add dependencies on the Javassist
>         module
>         (since we will stop automatically adding Javassist to JPA
>         application
>         deployments).
>
>         The advantage of this change, is that Hibernate applications
>         can include
>         their own version of Javassist.
>
>         This will also have an impact on Hibernate build-time enhancing of
>         entity classes (e.g. enhanced bytecode will no longer depend
>         on the
>         public Javassist classes).
>
>         Scott
>
>         [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>     -- 
>     James R. Perkins
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/8b91eca8/attachment.html 

From stuart.w.douglas at gmail.com  Thu Feb 11 15:02:16 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 11 Feb 2016 20:02:16 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BCB0DB.8030102@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
Message-ID: <CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>

Have you considered a 3rd alternative, which is to use a custom
ProxyFactory instead of javassists built in one?

AFAIK the main issue is that javassist proxies require access to the
'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You could
create a similar org.hibernate interface, and a proxy factory that uses
this method handler instead.

Basically you just copy the code from javassist.util.proxy into hibernate.
This is a relatively small amount of code, so it should not really add any
maintenance burden.

The inability to change javassist versions could be a major pain for
Hibernate later on, as it may mean that older hibernate versions fail to
work with newer JDK's if changes are made to the class file format.

Stuart

On Fri, 12 Feb 2016 at 03:03 Scott Marlow <smarlow at redhat.com> wrote:

> As previously discussed, Hibernate applications need access to the
> Javassist runtime classes (see example [1] enhanced application entity
> if you didn't know this :).  A proposal was discussed on the
> hibernate-dev mailing list that I think is the best short term solution.
>   I wanted to raise this issue here also, as I would like to later
> create a pull request to bring in a new Hibernate ORM that includes this
> change.  So, getting early feedback before we create JIRAs for the work,
> is important.
>
> The proposal is to private package (or shade), the Javassist classes, so
> that Hibernate ORM has its own copy of the Javassist classes.  On
> WildFly, we still would include Javassist for the other components that
> use it and for Hibernate applications that have "build-time enhanced
> entity classes" by an earlier Hibernate release.
>
> One downside of this change is that Hibernate applications cannot easily
> switch to a different version of the Javassist classes.
>
> Another downside is that applications that depend on an older Hibernate
> ORM version that includes "build-time enhanced entity classes", will
> need to be cracked open, to add dependencies on the Javassist module
> (since we will stop automatically adding Javassist to JPA application
> deployments).
>
> The advantage of this change, is that Hibernate applications can include
> their own version of Javassist.
>
> This will also have an impact on Hibernate build-time enhancing of
> entity classes (e.g. enhanced bytecode will no longer depend on the
> public Javassist classes).
>
> Scott
>
> [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/90ec20e0/attachment-0001.html 

From smarlow at redhat.com  Thu Feb 11 15:29:00 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Feb 2016 15:29:00 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BCE819.90201@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CADGwLpiQjO_hkvFJeTPue0S1KZ9fqShS7PbF6eT0Y2hiaxt4VQ@mail.gmail.com>
	<CAAoo=c6kmjhxu=_7fTBuxExRpuST9a4bywxbeL+X2uA04U3Skg@mail.gmail.com>
	<56BCE819.90201@redhat.com>
Message-ID: <56BCEF0C.9070009@redhat.com>



On 02/11/2016 02:59 PM, Fernando Nasser wrote:
> On 2016-02-11 2:55 PM, Stuart Douglas wrote:
>>
>>
>> On Fri, 12 Feb 2016 at 06:42 James Perkins
>> <<mailto:jperkins at redhat.com>jperkins at redhat.com> wrote:
>>
>>     I don't recall the previous discussion, but is there a reason we
>>     couldn't just use a JBoss module with a different slot?
>>
>>
>> Nah, the issue is that these classes need to be referenced by the
>> deployment and hibernate, so whatever version hibernate uses has to be
>> the one exposed to the deployment.
> Can't we require that that alternative module is specified as a
> dependency for the hibernate deployments?

The Javassist module is marked as private api, so applications are 
discouraged from depending on it.  They certainly can but they get a 
warning that the dependency might go away in the future (which means the 
app might not deploy in the future).

>
> It does put the onus on the user but we already end up having to specify
> a few things for hibernate anyway.

For native Hibernate api applications, they currently have to add a 
dependency on Javassist.  For EE JPA container managed applications, we 
automatically add a dependency on Javassist for them.

>
> Fernando
>
>
>>
>> Stuart
>>
>>
>>     On Thu, Feb 11, 2016 at 8:03 AM, Scott Marlow
>>     <<mailto:smarlow at redhat.com>smarlow at redhat.com> wrote:
>>
>>         As previously discussed, Hibernate applications need access to the
>>         Javassist runtime classes (see example [1] enhanced
>>         application entity
>>         if you didn't know this :).  A proposal was discussed on the
>>         hibernate-dev mailing list that I think is the best short term
>>         solution.
>>           I wanted to raise this issue here also, as I would like to later
>>         create a pull request to bring in a new Hibernate ORM that
>>         includes this
>>         change.  So, getting early feedback before we create JIRAs for
>>         the work,
>>         is important.
>>
>>         The proposal is to private package (or shade), the Javassist
>>         classes, so
>>         that Hibernate ORM has its own copy of the Javassist classes.  On
>>         WildFly, we still would include Javassist for the other
>>         components that
>>         use it and for Hibernate applications that have "build-time
>>         enhanced
>>         entity classes" by an earlier Hibernate release.
>>
>>         One downside of this change is that Hibernate applications
>>         cannot easily
>>         switch to a different version of the Javassist classes.
>>
>>         Another downside is that applications that depend on an older
>>         Hibernate
>>         ORM version that includes "build-time enhanced entity
>>         classes", will
>>         need to be cracked open, to add dependencies on the Javassist
>>         module
>>         (since we will stop automatically adding Javassist to JPA
>>         application
>>         deployments).
>>
>>         The advantage of this change, is that Hibernate applications
>>         can include
>>         their own version of Javassist.
>>
>>         This will also have an impact on Hibernate build-time enhancing of
>>         entity classes (e.g. enhanced bytecode will no longer depend
>>         on the
>>         public Javassist classes).
>>
>>         Scott
>>
>>         [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>         _______________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>>     --
>>     James R. Perkins
>>     JBoss by Red Hat
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From smarlow at redhat.com  Thu Feb 11 15:41:07 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Feb 2016 15:41:07 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
Message-ID: <56BCF1E3.9050000@redhat.com>


On 02/11/2016 03:02 PM, Stuart Douglas wrote:
> Have you considered a 3rd alternative, which is to use a custom
> ProxyFactory instead of javassists built in one?
>
> AFAIK the main issue is that javassist proxies require access to the
> 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You could
> create a similar org.hibernate interface, and a proxy factory that uses
> this method handler instead.
>
> Basically you just copy the code from javassist.util.proxy into
> hibernate. This is a relatively small amount of code, so it should not
> really add any maintenance burden.

We talked about this as well via [1].  I understand the concept but have 
not tried doing this.  I like this approach as well, if it works.  One 
of the cons with cloning that Steve Ebersole pointed out (see response 
on Feb-03-2016 9:01am), is that that users lose the ability to drop a 
different version of Javassist in (since we maintain our own cloned copy 
of the Javassist proxy/runtime code).

If we use a private packaged copy of the jars, in order to use a 
different version of Javassist, users would have to get a new version of 
Hibernate that is built with that different Javassist (as you point out).

I would like to create a HHH jira for this issue that doesn't require a 
specific implementation technique, so we can track this issue.

Scott

[1] http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html

>
> The inability to change javassist versions could be a major pain for
> Hibernate later on, as it may mean that older hibernate versions fail to
> work with newer JDK's if changes are made to the class file format.
>
> Stuart
>
> On Fri, 12 Feb 2016 at 03:03 Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     As previously discussed, Hibernate applications need access to the
>     Javassist runtime classes (see example [1] enhanced application entity
>     if you didn't know this :).  A proposal was discussed on the
>     hibernate-dev mailing list that I think is the best short term solution.
>        I wanted to raise this issue here also, as I would like to later
>     create a pull request to bring in a new Hibernate ORM that includes this
>     change.  So, getting early feedback before we create JIRAs for the work,
>     is important.
>
>     The proposal is to private package (or shade), the Javassist classes, so
>     that Hibernate ORM has its own copy of the Javassist classes.  On
>     WildFly, we still would include Javassist for the other components that
>     use it and for Hibernate applications that have "build-time enhanced
>     entity classes" by an earlier Hibernate release.
>
>     One downside of this change is that Hibernate applications cannot easily
>     switch to a different version of the Javassist classes.
>
>     Another downside is that applications that depend on an older Hibernate
>     ORM version that includes "build-time enhanced entity classes", will
>     need to be cracked open, to add dependencies on the Javassist module
>     (since we will stop automatically adding Javassist to JPA application
>     deployments).
>
>     The advantage of this change, is that Hibernate applications can include
>     their own version of Javassist.
>
>     This will also have an impact on Hibernate build-time enhancing of
>     entity classes (e.g. enhanced bytecode will no longer depend on the
>     public Javassist classes).
>
>     Scott
>
>     [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From stuart.w.douglas at gmail.com  Thu Feb 11 17:40:50 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 11 Feb 2016 22:40:50 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BCF1E3.9050000@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
Message-ID: <CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>

On Fri, 12 Feb 2016 at 07:41 Scott Marlow <smarlow at redhat.com> wrote:

>
> On 02/11/2016 03:02 PM, Stuart Douglas wrote:
> > Have you considered a 3rd alternative, which is to use a custom
> > ProxyFactory instead of javassists built in one?
> >
> > AFAIK the main issue is that javassist proxies require access to the
> > 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You could
> > create a similar org.hibernate interface, and a proxy factory that uses
> > this method handler instead.
> >
> > Basically you just copy the code from javassist.util.proxy into
> > hibernate. This is a relatively small amount of code, so it should not
> > really add any maintenance burden.
>
> We talked about this as well via [1].  I understand the concept but have
> not tried doing this.  I like this approach as well, if it works.  One
> of the cons with cloning that Steve Ebersole pointed out (see response
> on Feb-03-2016 9:01am), is that that users lose the ability to drop a
> different version of Javassist in (since we maintain our own cloned copy
> of the Javassist proxy/runtime code).
>

The proxy code is a relatively small part of javassist, so unless a bug is
in the proxy code itself this should not be that big a deal.

If they do go down the shade route will this shaded hibernate+javassist be
a different artifact (i.e. will they still publish a non javassist version
of hibernate)?

Stuart


>
> If we use a private packaged copy of the jars, in order to use a
> different version of Javassist, users would have to get a new version of
> Hibernate that is built with that different Javassist (as you point out).
>
> I would like to create a HHH jira for this issue that doesn't require a
> specific implementation technique, so we can track this issue.
>
> Scott
>
> [1]
> http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html
>
> >
> > The inability to change javassist versions could be a major pain for
> > Hibernate later on, as it may mean that older hibernate versions fail to
> > work with newer JDK's if changes are made to the class file format.
> >
> > Stuart
> >
> > On Fri, 12 Feb 2016 at 03:03 Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     As previously discussed, Hibernate applications need access to the
> >     Javassist runtime classes (see example [1] enhanced application
> entity
> >     if you didn't know this :).  A proposal was discussed on the
> >     hibernate-dev mailing list that I think is the best short term
> solution.
> >        I wanted to raise this issue here also, as I would like to later
> >     create a pull request to bring in a new Hibernate ORM that includes
> this
> >     change.  So, getting early feedback before we create JIRAs for the
> work,
> >     is important.
> >
> >     The proposal is to private package (or shade), the Javassist
> classes, so
> >     that Hibernate ORM has its own copy of the Javassist classes.  On
> >     WildFly, we still would include Javassist for the other components
> that
> >     use it and for Hibernate applications that have "build-time enhanced
> >     entity classes" by an earlier Hibernate release.
> >
> >     One downside of this change is that Hibernate applications cannot
> easily
> >     switch to a different version of the Javassist classes.
> >
> >     Another downside is that applications that depend on an older
> Hibernate
> >     ORM version that includes "build-time enhanced entity classes", will
> >     need to be cracked open, to add dependencies on the Javassist module
> >     (since we will stop automatically adding Javassist to JPA application
> >     deployments).
> >
> >     The advantage of this change, is that Hibernate applications can
> include
> >     their own version of Javassist.
> >
> >     This will also have an impact on Hibernate build-time enhancing of
> >     entity classes (e.g. enhanced bytecode will no longer depend on the
> >     public Javassist classes).
> >
> >     Scott
> >
> >     [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
> >     _______________________________________________
> >     wildfly-dev mailing list
> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160211/2c814ee4/attachment.html 

From smarlow at redhat.com  Thu Feb 11 18:40:53 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Feb 2016 18:40:53 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
Message-ID: <56BD1C05.8030104@redhat.com>



On 02/11/2016 05:40 PM, Stuart Douglas wrote:
>
>
> On Fri, 12 Feb 2016 at 07:41 Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>     On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>      > Have you considered a 3rd alternative, which is to use a custom
>      > ProxyFactory instead of javassists built in one?
>      >
>      > AFAIK the main issue is that javassist proxies require access to the
>      > 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You
>     could
>      > create a similar org.hibernate interface, and a proxy factory
>     that uses
>      > this method handler instead.
>      >
>      > Basically you just copy the code from javassist.util.proxy into
>      > hibernate. This is a relatively small amount of code, so it
>     should not
>      > really add any maintenance burden.
>
>     We talked about this as well via [1].  I understand the concept but have
>     not tried doing this.  I like this approach as well, if it works.  One
>     of the cons with cloning that Steve Ebersole pointed out (see response
>     on Feb-03-2016 9:01am), is that that users lose the ability to drop a
>     different version of Javassist in (since we maintain our own cloned copy
>     of the Javassist proxy/runtime code).
>
>
> The proxy code is a relatively small part of javassist, so unless a bug
> is in the proxy code itself this should not be that big a deal.

Thanks for the encouragement to go down this path.  :)

>
> If they do go down the shade route will this shaded hibernate+javassist
> be a different artifact (i.e. will they still publish a non javassist
> version of hibernate)?

Good question, I'm not really sure.

>
> Stuart
>
>
>     If we use a private packaged copy of the jars, in order to use a
>     different version of Javassist, users would have to get a new version of
>     Hibernate that is built with that different Javassist (as you point
>     out).
>
>     I would like to create a HHH jira for this issue that doesn't require a
>     specific implementation technique, so we can track this issue.
>
>     Scott
>
>     [1]
>     http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html
>
>      >
>      > The inability to change javassist versions could be a major pain for
>      > Hibernate later on, as it may mean that older hibernate versions
>     fail to
>      > work with newer JDK's if changes are made to the class file format.
>      >
>      > Stuart
>      >
>      > On Fri, 12 Feb 2016 at 03:03 Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>
>      > <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >
>      >     As previously discussed, Hibernate applications need access
>     to the
>      >     Javassist runtime classes (see example [1] enhanced
>     application entity
>      >     if you didn't know this :).  A proposal was discussed on the
>      >     hibernate-dev mailing list that I think is the best short
>     term solution.
>      >        I wanted to raise this issue here also, as I would like to
>     later
>      >     create a pull request to bring in a new Hibernate ORM that
>     includes this
>      >     change.  So, getting early feedback before we create JIRAs
>     for the work,
>      >     is important.
>      >
>      >     The proposal is to private package (or shade), the Javassist
>     classes, so
>      >     that Hibernate ORM has its own copy of the Javassist classes.  On
>      >     WildFly, we still would include Javassist for the other
>     components that
>      >     use it and for Hibernate applications that have "build-time
>     enhanced
>      >     entity classes" by an earlier Hibernate release.
>      >
>      >     One downside of this change is that Hibernate applications
>     cannot easily
>      >     switch to a different version of the Javassist classes.
>      >
>      >     Another downside is that applications that depend on an older
>     Hibernate
>      >     ORM version that includes "build-time enhanced entity
>     classes", will
>      >     need to be cracked open, to add dependencies on the Javassist
>     module
>      >     (since we will stop automatically adding Javassist to JPA
>     application
>      >     deployments).
>      >
>      >     The advantage of this change, is that Hibernate applications
>     can include
>      >     their own version of Javassist.
>      >
>      >     This will also have an impact on Hibernate build-time
>     enhancing of
>      >     entity classes (e.g. enhanced bytecode will no longer depend
>     on the
>      >     public Javassist classes).
>      >
>      >     Scott
>      >
>      >     [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>      >     _______________________________________________
>      >     wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>

From smarlow at redhat.com  Thu Feb 11 20:13:01 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Feb 2016 20:13:01 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BD1C05.8030104@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com>
Message-ID: <56BD319D.6040304@redhat.com>

>>
>>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>       > Have you considered a 3rd alternative, which is to use a custom
>>       > ProxyFactory instead of javassists built in one?
>>       >
>>       > AFAIK the main issue is that javassist proxies require access to the
>>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You
>>      could
>>       > create a similar org.hibernate interface, and a proxy factory
>>      that uses
>>       > this method handler instead.
>>       >
>>       > Basically you just copy the code from javassist.util.proxy into
>>       > hibernate. This is a relatively small amount of code, so it
>>      should not
>>       > really add any maintenance burden.
>>
>>      We talked about this as well via [1].  I understand the concept but have
>>      not tried doing this.  I like this approach as well, if it works.  One
>>      of the cons with cloning that Steve Ebersole pointed out (see response
>>      on Feb-03-2016 9:01am), is that that users lose the ability to drop a
>>      different version of Javassist in (since we maintain our own cloned copy
>>      of the Javassist proxy/runtime code).
>>
>>
>> The proxy code is a relatively small part of javassist, so unless a bug
>> is in the proxy code itself this should not be that big a deal.
>
> Thanks for the encouragement to go down this path.  :)
>

Started a hack attempt at the clone via 
https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.  Seems 
to pass the Hibernate ORM unit tests.

Scott

From steve at hibernate.org  Thu Feb 11 20:52:56 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 12 Feb 2016 01:52:56 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BD319D.6040304@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
Message-ID: <CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>

Ugh.  That is an awful lot of classes copied over.  What exactly was the
benefit of this over shading again?  I mean both case lose the ability to
simply drop in fixes from upstream Javassist.  So what does this "clone"
approach gain versus shadowing?



On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com> wrote:

> >>
> >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
> >>       > Have you considered a 3rd alternative, which is to use a custom
> >>       > ProxyFactory instead of javassists built in one?
> >>       >
> >>       > AFAIK the main issue is that javassist proxies require access
> to the
> >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes. You
> >>      could
> >>       > create a similar org.hibernate interface, and a proxy factory
> >>      that uses
> >>       > this method handler instead.
> >>       >
> >>       > Basically you just copy the code from javassist.util.proxy into
> >>       > hibernate. This is a relatively small amount of code, so it
> >>      should not
> >>       > really add any maintenance burden.
> >>
> >>      We talked about this as well via [1].  I understand the concept
> but have
> >>      not tried doing this.  I like this approach as well, if it works.
> One
> >>      of the cons with cloning that Steve Ebersole pointed out (see
> response
> >>      on Feb-03-2016 9:01am), is that that users lose the ability to
> drop a
> >>      different version of Javassist in (since we maintain our own
> cloned copy
> >>      of the Javassist proxy/runtime code).
> >>
> >>
> >> The proxy code is a relatively small part of javassist, so unless a bug
> >> is in the proxy code itself this should not be that big a deal.
> >
> > Thanks for the encouragement to go down this path.  :)
> >
>
> Started a hack attempt at the clone via
> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.  Seems
> to pass the Hibernate ORM unit tests.
>
> Scott
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160212/60b3f6f0/attachment.html 

From stuart.w.douglas at gmail.com  Thu Feb 11 21:04:06 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 12 Feb 2016 02:04:06 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
Message-ID: <CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>

It depends if you are going to shade all the javassist classes or just the
"javassist.util.proxy" package (not sure if this is actually possible with
the shade plugin).

The main advantage is that you can upgrade javassist to get fixes to issues
that affect bytecode generation. So if JDK9 comes out with new bytecodes
that the current version of Javassist does not understand then upgrading
javassist will allow the older version of hibernate to work with classes
compiled against the newer JDK version. If all of javassist is shaded into
hibernate then that version of hibernate will never work with the newer
bytecodes.

I think this is less of an issue if you are still publishing the
non-Javassist shaded hibernate as well as a shaded version, but if the only
published artifact has javassist shaded in then it may limit forward
compatibility.

Stuart


On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org> wrote:

> Ugh.  That is an awful lot of classes copied over.  What exactly was the
> benefit of this over shading again?  I mean both case lose the ability to
> simply drop in fixes from upstream Javassist.  So what does this "clone"
> approach gain versus shadowing?
>
>
>
> On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com> wrote:
>
>> >>
>> >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>> >>       > Have you considered a 3rd alternative, which is to use a custom
>> >>       > ProxyFactory instead of javassists built in one?
>> >>       >
>> >>       > AFAIK the main issue is that javassist proxies require access
>> to the
>> >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport' classes.
>> You
>> >>      could
>> >>       > create a similar org.hibernate interface, and a proxy factory
>> >>      that uses
>> >>       > this method handler instead.
>> >>       >
>> >>       > Basically you just copy the code from javassist.util.proxy into
>> >>       > hibernate. This is a relatively small amount of code, so it
>> >>      should not
>> >>       > really add any maintenance burden.
>> >>
>> >>      We talked about this as well via [1].  I understand the concept
>> but have
>> >>      not tried doing this.  I like this approach as well, if it
>> works.  One
>> >>      of the cons with cloning that Steve Ebersole pointed out (see
>> response
>> >>      on Feb-03-2016 9:01am), is that that users lose the ability to
>> drop a
>> >>      different version of Javassist in (since we maintain our own
>> cloned copy
>> >>      of the Javassist proxy/runtime code).
>> >>
>> >>
>> >> The proxy code is a relatively small part of javassist, so unless a bug
>> >> is in the proxy code itself this should not be that big a deal.
>> >
>> > Thanks for the encouragement to go down this path.  :)
>> >
>>
>> Started a hack attempt at the clone via
>> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.  Seems
>> to pass the Hibernate ORM unit tests.
>>
>> Scott
>>
> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160212/e4b4c044/attachment.html 

From smarlow at redhat.com  Thu Feb 11 22:19:01 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 11 Feb 2016 22:19:01 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
Message-ID: <56BD4F25.9020304@redhat.com>

What if Javassist packaged these same (proxy/runtime) classes in a 
separate javassist-runtime jar and we shaded only the proxy/runtime 
classes?  That way we only repackage the same classes that we included 
for this hack test (e.g. 
org.hibernate.bytecode.internal.javassist.proxy.*).

Early testing results of the hack test look good 
(https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).

Scott

On 02/11/2016 09:04 PM, Stuart Douglas wrote:
> It depends if you are going to shade all the javassist classes or just
> the "javassist.util.proxy" package (not sure if this is actually
> possible with the shade plugin).
>
> The main advantage is that you can upgrade javassist to get fixes to
> issues that affect bytecode generation. So if JDK9 comes out with new
> bytecodes that the current version of Javassist does not understand then
> upgrading javassist will allow the older version of hibernate to work
> with classes compiled against the newer JDK version. If all of javassist
> is shaded into hibernate then that version of hibernate will never work
> with the newer bytecodes.
>
> I think this is less of an issue if you are still publishing the
> non-Javassist shaded hibernate as well as a shaded version, but if the
> only published artifact has javassist shaded in then it may limit
> forward compatibility.
>
> Stuart
>
>
> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
> <mailto:steve at hibernate.org>> wrote:
>
>     Ugh.  That is an awful lot of classes copied over.  What exactly was
>     the benefit of this over shading again?  I mean both case lose the
>     ability to simply drop in fixes from upstream Javassist.  So what
>     does this "clone" approach gain versus shadowing?
>
>
>
>     On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>          >>
>          >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>          >>       > Have you considered a 3rd alternative, which is to
>         use a custom
>          >>       > ProxyFactory instead of javassists built in one?
>          >>       >
>          >>       > AFAIK the main issue is that javassist proxies
>         require access to the
>          >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>         classes. You
>          >>      could
>          >>       > create a similar org.hibernate interface, and a
>         proxy factory
>          >>      that uses
>          >>       > this method handler instead.
>          >>       >
>          >>       > Basically you just copy the code from
>         javassist.util.proxy into
>          >>       > hibernate. This is a relatively small amount of
>         code, so it
>          >>      should not
>          >>       > really add any maintenance burden.
>          >>
>          >>      We talked about this as well via [1].  I understand the
>         concept but have
>          >>      not tried doing this.  I like this approach as well, if
>         it works.  One
>          >>      of the cons with cloning that Steve Ebersole pointed
>         out (see response
>          >>      on Feb-03-2016 9:01am), is that that users lose the
>         ability to drop a
>          >>      different version of Javassist in (since we maintain
>         our own cloned copy
>          >>      of the Javassist proxy/runtime code).
>          >>
>          >>
>          >> The proxy code is a relatively small part of javassist, so
>         unless a bug
>          >> is in the proxy code itself this should not be that big a deal.
>          >
>          > Thanks for the encouragement to go down this path.  :)
>          >
>
>         Started a hack attempt at the clone via
>         https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>         Seems
>         to pass the Hibernate ORM unit tests.
>
>         Scott
>
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From mmusgrov at redhat.com  Sun Feb 14 17:40:20 2016
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Sun, 14 Feb 2016 22:40:20 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
Message-ID: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>

I am attempting to lookup a remote EJB from WildFly to WLS.

If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY
to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the
WildFly end:
  "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"

If I use the default wildfly name service (new
InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
I get the following error on the WLS end (presumably because I am not
using CNCtxFactory):
  "A RuntimeException was generated by the RMI server:
weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"

I did try adding the CosNaming dependency (<path
name="com/sun/jndi/cosnaming"/>) to
modules/system/layers/base/sun/jdk/main/module.xml or to
jboss-deployment-structure.xml in my deployment but that approach did not
work.


[1] row 3 of Table 2-1 in
https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html

-- 
Michael Musgrove
Transactions Team
e: mmusgrov at redhat.com
t: +44 191 243 0870

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
(US), Charles Peters (US)

Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
O'Neill(Ireland)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160214/98e0b9c8/attachment-0001.html 

From stuart.w.douglas at gmail.com  Sun Feb 14 17:44:12 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 14 Feb 2016 22:44:12 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
Message-ID: <CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>

You should be able to use this if you have a dependency on the sun.jdk
module.

Stuart

On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com> wrote:

> I am attempting to lookup a remote EJB from WildFly to WLS.
>
> If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY
> to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the
> WildFly end:
>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>
> If I use the default wildfly name service (new
> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
> I get the following error on the WLS end (presumably because I am not
> using CNCtxFactory):
>   "A RuntimeException was generated by the RMI server:
> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>
> I did try adding the CosNaming dependency (<path
> name="com/sun/jndi/cosnaming"/>) to
> modules/system/layers/base/sun/jdk/main/module.xml or to
> jboss-deployment-structure.xml in my deployment but that approach did not
> work.
>
>
> [1] row 3 of Table 2-1 in
> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
>
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
> O'Neill(Ireland)
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160214/fa2de44b/attachment.html 

From stuart.w.douglas at gmail.com  Sun Feb 14 17:46:10 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 14 Feb 2016 22:46:10 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
Message-ID: <CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>

Oops, disregard that, looks like it is actually not defined in any of our
pre-defined modules.

What is the full stack trace you get when you include the path in your
jboss-deployment-structure.xml ? (and what does this file look like)

Stuart

On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> You should be able to use this if you have a dependency on the sun.jdk
> module.
>
> Stuart
>
> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com> wrote:
>
>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>
>> If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY
>> to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the
>> WildFly end:
>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>
>> If I use the default wildfly name service (new
>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>> I get the following error on the WLS end (presumably because I am not
>> using CNCtxFactory):
>>   "A RuntimeException was generated by the RMI server:
>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>
>> I did try adding the CosNaming dependency (<path
>> name="com/sun/jndi/cosnaming"/>) to
>> modules/system/layers/base/sun/jdk/main/module.xml or to
>> jboss-deployment-structure.xml in my deployment but that approach did not
>> work.
>>
>>
>> [1] row 3 of Table 2-1 in
>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>
>> --
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com
>> t: +44 191 243 0870
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>>
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>> O'Neill(Ireland)
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160214/5cd9c5fd/attachment.html 

From mmusgrov at redhat.com  Mon Feb 15 04:23:17 2016
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Mon, 15 Feb 2016 09:23:17 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
Message-ID: <CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>

The lookup code is:

    private ISession getRemoteSession() throws Throwable {
        final Properties env = new Properties();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
        env.put(Context.PROVIDER_URL,
"corbaloc::localhost:7001/NameService");

        final InitialContext context = new InitialContext(env);
        final Object iiopObj = context.lookup("SessionBean");
        return
ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj,
ISessionHome.class)).create();
    }

and the stacktrace is:

2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean] (p:
default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
Failed instantiate InitialContextFactory
com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
Loader [Root exception is java.lang.ClassNotFoundException:
com.sun.jndi.cosnaming.CNCtxFactory from [Module
"deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
at
org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at
org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at
support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
at
com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
at
com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
at
com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
at
com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
at
com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
Caused by: java.lang.ClassNotFoundException:
com.sun.jndi.cosnaming.CNCtxFactory from [Module
"deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
... 87 more


On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

> Oops, disregard that, looks like it is actually not defined in any of our
> pre-defined modules.
>
> What is the full stack trace you get when you include the path in your
> jboss-deployment-structure.xml ? (and what does this file look like)
>
> Stuart
>
> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
>
>> You should be able to use this if you have a dependency on the sun.jdk
>> module.
>>
>> Stuart
>>
>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com>
>> wrote:
>>
>>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>>
>>> If I use COSNaming as required by [1] (by setting
>>> INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the
>>> following error on the WildFly end:
>>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>>
>>> If I use the default wildfly name service (new
>>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>>> I get the following error on the WLS end (presumably because I am not
>>> using CNCtxFactory):
>>>   "A RuntimeException was generated by the RMI server:
>>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>>
>>> I did try adding the CosNaming dependency (<path
>>> name="com/sun/jndi/cosnaming"/>) to
>>> modules/system/layers/base/sun/jdk/main/module.xml or to
>>> jboss-deployment-structure.xml in my deployment but that approach did not
>>> work.
>>>
>>>
>>> [1] row 3 of Table 2-1 in
>>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>>
>>> --
>>> Michael Musgrove
>>> Transactions Team
>>> e: mmusgrov at redhat.com
>>> t: +44 191 243 0870
>>>
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>> (US), Charles Peters (US)
>>>
>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>>> O'Neill(Ireland)
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>


-- 
Michael Musgrove
Transactions Team
e: mmusgrov at redhat.com
t: +44 191 243 0870

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
(US), Charles Peters (US)

Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
O'Neill(Ireland)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/0dba136c/attachment-0001.html 

From mmusgrov at redhat.com  Mon Feb 15 04:27:33 2016
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Mon, 15 Feb 2016 09:27:33 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
Message-ID: <CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>

Wait you asked for the stacktrace when I include the dependency in
jboss-deployment-structure.xml,
sorry - here is the error when I do that:

2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean] (p:
default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
Failed instantiate InitialContextFactory
com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate
default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB
 vmcid: 0x0  minor code: 0  completed: No]
at
org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at
org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at
support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
at
com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
at
com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
at
com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
at
com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
at
com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
at
com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
at
com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB
implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0
 minor code: 0  completed: No
at org.omg.CORBA.ORB.create_impl(ORB.java:311)
at org.omg.CORBA.ORB.init(ORB.java:351)
at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
at
com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
at
org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
... 87 more
Caused by: java.lang.ClassCastException: class
com.sun.corba.se.internal.Interceptors.PIORB
at java.lang.Class.asSubclass(Class.java:3404)
at org.omg.CORBA.ORB.create_impl(ORB.java:308)
... 94 more





On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com>
wrote:

> The lookup code is:
>
>     private ISession getRemoteSession() throws Throwable {
>         final Properties env = new Properties();
>         env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.cosnaming.CNCtxFactory");
>         env.put(Context.PROVIDER_URL,
> "corbaloc::localhost:7001/NameService");
>
>         final InitialContext context = new InitialContext(env);
>         final Object iiopObj = context.lookup("SessionBean");
>         return
> ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj,
> ISessionHome.class)).create();
>     }
>
> and the stacktrace is:
>
> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean] (p:
> default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
> Failed instantiate InitialContextFactory
> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
> Loader [Root exception is java.lang.ClassNotFoundException:
> com.sun.jndi.cosnaming.CNCtxFactory from [Module
> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
> at
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at
> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.<init>(InitialContext.java:216)
> at
> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at
> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
> at
> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> at
> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> at
> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> at
> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> at
> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> at
> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> at
> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: java.lang.ClassNotFoundException:
> com.sun.jndi.cosnaming.CNCtxFactory from [Module
> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
> at
> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at
> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> ... 87 more
>
>
> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> Oops, disregard that, looks like it is actually not defined in any of our
>> pre-defined modules.
>>
>> What is the full stack trace you get when you include the path in your
>> jboss-deployment-structure.xml ? (and what does this file look like)
>>
>> Stuart
>>
>> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com>
>> wrote:
>>
>>> You should be able to use this if you have a dependency on the sun.jdk
>>> module.
>>>
>>> Stuart
>>>
>>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com>
>>> wrote:
>>>
>>>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>>>
>>>> If I use COSNaming as required by [1] (by setting
>>>> INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the
>>>> following error on the WildFly end:
>>>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>>>
>>>> If I use the default wildfly name service (new
>>>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>>>> I get the following error on the WLS end (presumably because I am not
>>>> using CNCtxFactory):
>>>>   "A RuntimeException was generated by the RMI server:
>>>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>>>
>>>> I did try adding the CosNaming dependency (<path
>>>> name="com/sun/jndi/cosnaming"/>) to
>>>> modules/system/layers/base/sun/jdk/main/module.xml or to
>>>> jboss-deployment-structure.xml in my deployment but that approach did not
>>>> work.
>>>>
>>>>
>>>> [1] row 3 of Table 2-1 in
>>>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>>>
>>>> --
>>>> Michael Musgrove
>>>> Transactions Team
>>>> e: mmusgrov at redhat.com
>>>> t: +44 191 243 0870
>>>>
>>>> Registered in England and Wales under Company Registration No. 03798903
>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>>> (US), Charles Peters (US)
>>>>
>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>>>> O'Neill(Ireland)
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>
>
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
>
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
> O'Neill(Ireland)
>



-- 
Michael Musgrove
Transactions Team
e: mmusgrov at redhat.com
t: +44 191 243 0870

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
(US), Charles Peters (US)

Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
O'Neill(Ireland)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/76cc08e1/attachment-0001.html 

From stuart.w.douglas at gmail.com  Mon Feb 15 04:50:09 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 15 Feb 2016 09:50:09 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
	<CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
Message-ID: <CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>

Did you try adding com.sun.corba.se.internal.Interceptors to the
jboss-deployment-structure.xml file?

Stuart

On Mon, 15 Feb 2016 at 20:27 Michael Musgrove <mmusgrov at redhat.com> wrote:

> Wait you asked for the stacktrace when I include the dependency in jboss-deployment-structure.xml,
> sorry - here is the error when I do that:
>
> 2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean] (p:
> default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
> Failed instantiate InitialContextFactory
> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
> Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate
> default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB
>  vmcid: 0x0  minor code: 0  completed: No]
> at
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at
> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.<init>(InitialContext.java:216)
> at
> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at
> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
> at
> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> at
> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> at
> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> at
> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> at
> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> at
> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> at
> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB
> implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0
>  minor code: 0  completed: No
> at org.omg.CORBA.ORB.create_impl(ORB.java:311)
> at org.omg.CORBA.ORB.init(ORB.java:351)
> at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
> at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
> at
> com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
> at
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> ... 87 more
> Caused by: java.lang.ClassCastException: class
> com.sun.corba.se.internal.Interceptors.PIORB
> at java.lang.Class.asSubclass(Class.java:3404)
> at org.omg.CORBA.ORB.create_impl(ORB.java:308)
> ... 94 more
>
>
>
>
>
> On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com>
> wrote:
>
>> The lookup code is:
>>
>>     private ISession getRemoteSession() throws Throwable {
>>         final Properties env = new Properties();
>>         env.put(Context.INITIAL_CONTEXT_FACTORY,
>> "com.sun.jndi.cosnaming.CNCtxFactory");
>>         env.put(Context.PROVIDER_URL,
>> "corbaloc::localhost:7001/NameService");
>>
>>         final InitialContext context = new InitialContext(env);
>>         final Object iiopObj = context.lookup("SessionBean");
>>         return
>> ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj,
>> ISessionHome.class)).create();
>>     }
>>
>> and the stacktrace is:
>>
>> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean]
>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>> Failed instantiate InitialContextFactory
>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>> Loader [Root exception is java.lang.ClassNotFoundException:
>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
>> at
>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>> at
>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>> at
>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>> at
>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>> at javax.naming.InitialContext.init(InitialContext.java:244)
>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>> at
>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at
>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> at
>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>> at
>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>> at
>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> at
>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>> at
>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> at
>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>> at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>> at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> at
>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>> at
>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> at
>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>> at
>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>> at
>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>> at
>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>> at
>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>> at
>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>> at
>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>> at
>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>> at
>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>> Caused by: java.lang.ClassNotFoundException:
>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
>> at
>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
>> at
>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
>> at
>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
>> at
>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
>> at
>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:348)
>> at
>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
>> ... 87 more
>>
>>
>> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <
>> stuart.w.douglas at gmail.com> wrote:
>>
>>> Oops, disregard that, looks like it is actually not defined in any of
>>> our pre-defined modules.
>>>
>>> What is the full stack trace you get when you include the path in your
>>> jboss-deployment-structure.xml ? (and what does this file look like)
>>>
>>> Stuart
>>>
>>> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com>
>>> wrote:
>>>
>>>> You should be able to use this if you have a dependency on the sun.jdk
>>>> module.
>>>>
>>>> Stuart
>>>>
>>>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com>
>>>> wrote:
>>>>
>>>>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>>>>
>>>>> If I use COSNaming as required by [1] (by setting
>>>>> INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the
>>>>> following error on the WildFly end:
>>>>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>>>>
>>>>> If I use the default wildfly name service (new
>>>>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>>>>> I get the following error on the WLS end (presumably because I am not
>>>>> using CNCtxFactory):
>>>>>   "A RuntimeException was generated by the RMI server:
>>>>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>>>>
>>>>> I did try adding the CosNaming dependency (<path
>>>>> name="com/sun/jndi/cosnaming"/>) to
>>>>> modules/system/layers/base/sun/jdk/main/module.xml or to
>>>>> jboss-deployment-structure.xml in my deployment but that approach did not
>>>>> work.
>>>>>
>>>>>
>>>>> [1] row 3 of Table 2-1 in
>>>>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>>>>
>>>>> --
>>>>> Michael Musgrove
>>>>> Transactions Team
>>>>> e: mmusgrov at redhat.com
>>>>> t: +44 191 243 0870
>>>>>
>>>>> Registered in England and Wales under Company Registration No. 03798903
>>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>>>> (US), Charles Peters (US)
>>>>>
>>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
>>>>> Michael O'Neill(Ireland)
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>
>>
>> --
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com
>> t: +44 191 243 0870
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>>
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>> O'Neill(Ireland)
>>
>
>
>
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
>
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
> O'Neill(Ireland)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/38a22fa0/attachment-0001.html 

From mmusgrov at redhat.com  Mon Feb 15 07:14:57 2016
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Mon, 15 Feb 2016 12:14:57 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
	<CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
	<CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>
Message-ID: <CACKZbavubtYf_3knTROjsQvLYeiqq946AEPimD5fB2ByVwQTwg@mail.gmail.com>

Thanks,

That has got me much further. Now I can successfully lookup the EJB that is
on WLS but when I narrow (using PortableRemoteObject.narrow) the object I
get java.lang.ClassCastException:
com.sun.corba.se.impl.corba.CORBAObjectImpl cannot be cast to
org.omg.CORBA.Object

I guess that is a different issue but I cannot figure out how to proceed -
any ideas?

On Mon, Feb 15, 2016 at 9:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> Did you try adding com.sun.corba.se.internal.Interceptors to the
> jboss-deployment-structure.xml file?
>
> Stuart
>
> On Mon, 15 Feb 2016 at 20:27 Michael Musgrove <mmusgrov at redhat.com> wrote:
>
>> Wait you asked for the stacktrace when I include the dependency in jboss-deployment-structure.xml,
>> sorry - here is the error when I do that:
>>
>> 2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean]
>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>> Failed instantiate InitialContextFactory
>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>> Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate
>> default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB
>>  vmcid: 0x0  minor code: 0  completed: No]
>> at
>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>> at
>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>> at
>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>> at
>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>> at javax.naming.InitialContext.init(InitialContext.java:244)
>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>> at
>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at
>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> at
>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>> at
>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>> at
>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> at
>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>> at
>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> at
>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>> at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>> at
>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> at
>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>> at
>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> at
>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>> at
>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> at
>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>> at
>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>> at
>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>> at
>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>> at
>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>> at
>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>> at
>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>> at
>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>> at
>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>> at
>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB
>> implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0
>>  minor code: 0  completed: No
>> at org.omg.CORBA.ORB.create_impl(ORB.java:311)
>> at org.omg.CORBA.ORB.init(ORB.java:351)
>> at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
>> at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
>> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
>> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
>> at
>> com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
>> at
>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
>> ... 87 more
>> Caused by: java.lang.ClassCastException: class
>> com.sun.corba.se.internal.Interceptors.PIORB
>> at java.lang.Class.asSubclass(Class.java:3404)
>> at org.omg.CORBA.ORB.create_impl(ORB.java:308)
>> ... 94 more
>>
>>
>>
>>
>>
>> On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com>
>> wrote:
>>
>>> The lookup code is:
>>>
>>>     private ISession getRemoteSession() throws Throwable {
>>>         final Properties env = new Properties();
>>>         env.put(Context.INITIAL_CONTEXT_FACTORY,
>>> "com.sun.jndi.cosnaming.CNCtxFactory");
>>>         env.put(Context.PROVIDER_URL,
>>> "corbaloc::localhost:7001/NameService");
>>>
>>>         final InitialContext context = new InitialContext(env);
>>>         final Object iiopObj = context.lookup("SessionBean");
>>>         return
>>> ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj,
>>> ISessionHome.class)).create();
>>>     }
>>>
>>> and the stacktrace is:
>>>
>>> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean]
>>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>>> Failed instantiate InitialContextFactory
>>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>>> Loader [Root exception is java.lang.ClassNotFoundException:
>>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
>>> at
>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>>> at
>>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>>> at
>>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>>> at
>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>>> at javax.naming.InitialContext.init(InitialContext.java:244)
>>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>>> at
>>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>> at
>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>> at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>>> at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>>> at
>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>> at
>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>>> at
>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>> at
>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>> at
>>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>>> at
>>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>> at
>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>> at
>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>>> at
>>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>>> at
>>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>>> at
>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>>> at
>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>>> at
>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>>> at
>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>>> Caused by: java.lang.ClassNotFoundException:
>>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
>>> at
>>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:348)
>>> at
>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
>>> ... 87 more
>>>
>>>
>>> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <
>>> stuart.w.douglas at gmail.com> wrote:
>>>
>>>> Oops, disregard that, looks like it is actually not defined in any of
>>>> our pre-defined modules.
>>>>
>>>> What is the full stack trace you get when you include the path in your
>>>> jboss-deployment-structure.xml ? (and what does this file look like)
>>>>
>>>> Stuart
>>>>
>>>> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com>
>>>> wrote:
>>>>
>>>>> You should be able to use this if you have a dependency on the sun.jdk
>>>>> module.
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>>>>>
>>>>>> If I use COSNaming as required by [1] (by setting
>>>>>> INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the
>>>>>> following error on the WildFly end:
>>>>>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>>>>>
>>>>>> If I use the default wildfly name service (new
>>>>>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>>>>>> I get the following error on the WLS end (presumably because I am not
>>>>>> using CNCtxFactory):
>>>>>>   "A RuntimeException was generated by the RMI server:
>>>>>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>>>>>
>>>>>> I did try adding the CosNaming dependency (<path
>>>>>> name="com/sun/jndi/cosnaming"/>) to
>>>>>> modules/system/layers/base/sun/jdk/main/module.xml or to
>>>>>> jboss-deployment-structure.xml in my deployment but that approach did not
>>>>>> work.
>>>>>>
>>>>>>
>>>>>> [1] row 3 of Table 2-1 in
>>>>>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>>>>>
>>>>>> --
>>>>>> Michael Musgrove
>>>>>> Transactions Team
>>>>>> e: mmusgrov at redhat.com
>>>>>> t: +44 191 243 0870
>>>>>>
>>>>>> Registered in England and Wales under Company Registration No.
>>>>>> 03798903
>>>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>>>>> (US), Charles Peters (US)
>>>>>>
>>>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
>>>>>> Michael O'Neill(Ireland)
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Michael Musgrove
>>> Transactions Team
>>> e: mmusgrov at redhat.com
>>> t: +44 191 243 0870
>>>
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>> (US), Charles Peters (US)
>>>
>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>>> O'Neill(Ireland)
>>>
>>
>>
>>
>> --
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com
>> t: +44 191 243 0870
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>>
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>> O'Neill(Ireland)
>>
>


-- 
Michael Musgrove
Transactions Team
e: mmusgrov at redhat.com
t: +44 191 243 0870

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
(US), Charles Peters (US)

Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
O'Neill(Ireland)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/804f461b/attachment-0001.html 

From tom.jenkinson at redhat.com  Mon Feb 15 07:44:41 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Mon, 15 Feb 2016 12:44:41 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CACKZbavubtYf_3knTROjsQvLYeiqq946AEPimD5fB2ByVwQTwg@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
	<CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
	<CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>
	<CACKZbavubtYf_3knTROjsQvLYeiqq946AEPimD5fB2ByVwQTwg@mail.gmail.com>
Message-ID: <CALaezvXHLgeepn2sw4OJO3HNijtcXtm1Tuvp82zodvr-S3tD8A@mail.gmail.com>

It seems that
https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/org/jboss/com/sun/corba/se/impl/corba/CORBAObjectImpl.html
does implement
http://docs.oracle.com/javase/7/docs/api/org/omg/CORBA/Object.html so my
guess is that the org.omg.CORBA classes are coming out of a different
classloader to the com.sun.corba.se.impl.corba ones.

On 15 February 2016 at 12:14, Michael Musgrove <mmusgrov at redhat.com> wrote:

> Thanks,
>
> That has got me much further. Now I can successfully lookup the EJB that
> is on WLS but when I narrow (using PortableRemoteObject.narrow) the object
> I get java.lang.ClassCastException:
> com.sun.corba.se.impl.corba.CORBAObjectImpl cannot be cast to
> org.omg.CORBA.Object
>
> I guess that is a different issue but I cannot figure out how to proceed -
> any ideas?
>
> On Mon, Feb 15, 2016 at 9:50 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> Did you try adding com.sun.corba.se.internal.Interceptors to the
>> jboss-deployment-structure.xml file?
>>
>> Stuart
>>
>> On Mon, 15 Feb 2016 at 20:27 Michael Musgrove <mmusgrov at redhat.com>
>> wrote:
>>
>>> Wait you asked for the stacktrace when I include the dependency in jboss-deployment-structure.xml,
>>> sorry - here is the error when I do that:
>>>
>>> 2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean]
>>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>>> Failed instantiate InitialContextFactory
>>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>>> Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate
>>> default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB
>>>  vmcid: 0x0  minor code: 0  completed: No]
>>> at
>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>>> at
>>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>>> at
>>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>>> at
>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>>> at javax.naming.InitialContext.init(InitialContext.java:244)
>>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>>> at
>>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>> at
>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>> at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>>> at
>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>>> at
>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>> at
>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>>> at
>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>> at
>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>>> at
>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>> at
>>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>>> at
>>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>> at
>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>>> at
>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>> at
>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>> at
>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>>> at
>>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>>> at
>>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>>> at
>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>>> at
>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>>> at
>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>>> at
>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>>> at
>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>>> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB
>>> implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0
>>>  minor code: 0  completed: No
>>> at org.omg.CORBA.ORB.create_impl(ORB.java:311)
>>> at org.omg.CORBA.ORB.init(ORB.java:351)
>>> at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
>>> at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
>>> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
>>> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
>>> at
>>> com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
>>> at
>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
>>> ... 87 more
>>> Caused by: java.lang.ClassCastException: class
>>> com.sun.corba.se.internal.Interceptors.PIORB
>>> at java.lang.Class.asSubclass(Class.java:3404)
>>> at org.omg.CORBA.ORB.create_impl(ORB.java:308)
>>> ... 94 more
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com>
>>> wrote:
>>>
>>>> The lookup code is:
>>>>
>>>>     private ISession getRemoteSession() throws Throwable {
>>>>         final Properties env = new Properties();
>>>>         env.put(Context.INITIAL_CONTEXT_FACTORY,
>>>> "com.sun.jndi.cosnaming.CNCtxFactory");
>>>>         env.put(Context.PROVIDER_URL,
>>>> "corbaloc::localhost:7001/NameService");
>>>>
>>>>         final InitialContext context = new InitialContext(env);
>>>>         final Object iiopObj = context.lookup("SessionBean");
>>>>         return
>>>> ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj,
>>>> ISessionHome.class)).create();
>>>>     }
>>>>
>>>> and the stacktrace is:
>>>>
>>>> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean]
>>>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>>>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>>>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>>>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>>>> Failed instantiate InitialContextFactory
>>>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>>>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>>>> Loader [Root exception is java.lang.ClassNotFoundException:
>>>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>>>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
>>>> at
>>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>>>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>>>> at
>>>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>>>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>>>> at
>>>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>>>> at
>>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>>>> at
>>>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>>>> at javax.naming.InitialContext.init(InitialContext.java:244)
>>>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>>>> at
>>>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>>>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>>> at
>>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>>> at
>>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>>>> at
>>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>>>> at
>>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>>> at
>>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>>>> at
>>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>> at
>>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>>>> at
>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>>>> at
>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>>> at
>>>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>>>> at
>>>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>>> at
>>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>> at
>>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>>>> at
>>>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>>>> at
>>>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>>>> at
>>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>>>> at
>>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>>>> at
>>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>>>> at
>>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>>>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
>>>> at
>>>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
>>>> at
>>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
>>>> at
>>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
>>>> at
>>>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
>>>> at
>>>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
>>>> at java.lang.Class.forName0(Native Method)
>>>> at java.lang.Class.forName(Class.java:348)
>>>> at
>>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
>>>> ... 87 more
>>>>
>>>>
>>>> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <
>>>> stuart.w.douglas at gmail.com> wrote:
>>>>
>>>>> Oops, disregard that, looks like it is actually not defined in any of
>>>>> our pre-defined modules.
>>>>>
>>>>> What is the full stack trace you get when you include the path in your
>>>>> jboss-deployment-structure.xml ? (and what does this file look like)
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <
>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>
>>>>>> You should be able to use this if you have a dependency on the
>>>>>> sun.jdk module.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>>>>>>
>>>>>>> If I use COSNaming as required by [1] (by setting
>>>>>>> INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the
>>>>>>> following error on the WildFly end:
>>>>>>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>>>>>>
>>>>>>> If I use the default wildfly name service (new
>>>>>>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>>>>>>> I get the following error on the WLS end (presumably because I am not
>>>>>>> using CNCtxFactory):
>>>>>>>   "A RuntimeException was generated by the RMI server:
>>>>>>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>>>>>>
>>>>>>> I did try adding the CosNaming dependency (<path
>>>>>>> name="com/sun/jndi/cosnaming"/>) to
>>>>>>> modules/system/layers/base/sun/jdk/main/module.xml or to
>>>>>>> jboss-deployment-structure.xml in my deployment but that approach did not
>>>>>>> work.
>>>>>>>
>>>>>>>
>>>>>>> [1] row 3 of Table 2-1 in
>>>>>>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>>>>>>
>>>>>>> --
>>>>>>> Michael Musgrove
>>>>>>> Transactions Team
>>>>>>> e: mmusgrov at redhat.com
>>>>>>> t: +44 191 243 0870
>>>>>>>
>>>>>>> Registered in England and Wales under Company Registration No.
>>>>>>> 03798903
>>>>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt
>>>>>>> Parson
>>>>>>> (US), Charles Peters (US)
>>>>>>>
>>>>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
>>>>>>> Michael O'Neill(Ireland)
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Musgrove
>>>> Transactions Team
>>>> e: mmusgrov at redhat.com
>>>> t: +44 191 243 0870
>>>>
>>>> Registered in England and Wales under Company Registration No. 03798903
>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>>> (US), Charles Peters (US)
>>>>
>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>>>> O'Neill(Ireland)
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Musgrove
>>> Transactions Team
>>> e: mmusgrov at redhat.com
>>> t: +44 191 243 0870
>>>
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>> (US), Charles Peters (US)
>>>
>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>>> O'Neill(Ireland)
>>>
>>
>
>
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
>
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
>
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
> O'Neill(Ireland)
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/9d36ff02/attachment-0001.html 

From jason.greene at redhat.com  Mon Feb 15 12:17:31 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 15 Feb 2016 11:17:31 -0600
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CALaezvXHLgeepn2sw4OJO3HNijtcXtm1Tuvp82zodvr-S3tD8A@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
	<CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
	<CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>
	<CACKZbavubtYf_3knTROjsQvLYeiqq946AEPimD5fB2ByVwQTwg@mail.gmail.com>
	<CALaezvXHLgeepn2sw4OJO3HNijtcXtm1Tuvp82zodvr-S3tD8A@mail.gmail.com>
Message-ID: <FA135825-5474-427A-B8F2-597F945A50BC@redhat.com>

Right, the issue is that we need to pull over ?com.sun.jndi.cosnaming.CNCtxFactory? into our openjdk subsystem, otherwise that class will see the wrong corba impl.

> On Feb 15, 2016, at 6:44 AM, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> 
> It seems that https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/org/jboss/com/sun/corba/se/impl/corba/CORBAObjectImpl.html <https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/org/jboss/com/sun/corba/se/impl/corba/CORBAObjectImpl.html> does implement http://docs.oracle.com/javase/7/docs/api/org/omg/CORBA/Object.html <http://docs.oracle.com/javase/7/docs/api/org/omg/CORBA/Object.html> so my guess is that the org.omg.CORBA classes are coming out of a different classloader to the com.sun.corba.se.impl.corba ones.
> 
> On 15 February 2016 at 12:14, Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
> Thanks,
> 
> That has got me much further. Now I can successfully lookup the EJB that is on WLS but when I narrow (using PortableRemoteObject.narrow) the object I get java.lang.ClassCastException: com.sun.corba.se.impl.corba.CORBAObjectImpl cannot be cast to org.omg.CORBA.Object
> 
> I guess that is a different issue but I cannot figure out how to proceed - any ideas?
> 
> On Mon, Feb 15, 2016 at 9:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
> Did you try adding com.sun.corba.se.internal.Interceptors to the jboss-deployment-structure.xml file?
> 
> Stuart
> 
> On Mon, 15 Feb 2016 at 20:27 Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
> Wait you asked for the stacktrace when I include the dependency in jboss-deployment-structure.xml, sorry - here is the error when I do that:
> 
> 2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean] (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0  minor code: 0  completed: No]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:216)
> 	at support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
> 	at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0  minor code: 0  completed: No
> 	at org.omg.CORBA.ORB.create_impl(ORB.java:311)
> 	at org.omg.CORBA.ORB.init(ORB.java:351)
> 	at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
> 	at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
> 	at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
> 	at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
> 	at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	... 87 more
> Caused by: java.lang.ClassCastException: class com.sun.corba.se.internal.Interceptors.PIORB
> 	at java.lang.Class.asSubclass(Class.java:3404)
> 	at org.omg.CORBA.ORB.create_impl(ORB.java:308)
> 	... 94 more
> 
> 
> 
> 
> 
> On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
> The lookup code is:
> 
>     private ISession getRemoteSession() throws Throwable {
>         final Properties env = new Properties();
>         env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
>         env.put(Context.PROVIDER_URL, "corbaloc::localhost:7001/NameService");
> 
>         final InitialContext context = new InitialContext(env);
>         final Object iiopObj = context.lookup("SessionBean");
>         return ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj, ISessionHome.class)).create();
>     }
> 
> and the stacktrace is:
> 
> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean] (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory from [Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:216)
> 	at support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
> 	at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory from [Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 87 more
> 
> 
> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
> Oops, disregard that, looks like it is actually not defined in any of our pre-defined modules.
> 
> What is the full stack trace you get when you include the path in your jboss-deployment-structure.xml ? (and what does this file look like)
> 
> Stuart
> 
> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
> You should be able to use this if you have a dependency on the sun.jdk module.
> 
> Stuart
> 
> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
> I am attempting to lookup a remote EJB from WildFly to WLS.
> 
> If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the WildFly end:
>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
> 
> If I use the default wildfly name service (new InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean")) I get the following error on the WLS end (presumably because I am not using CNCtxFactory):
>   "A RuntimeException was generated by the RMI server: weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
> 
> I did try adding the CosNaming dependency (<path name="com/sun/jndi/cosnaming"/>) to modules/system/layers/base/sun/jdk/main/module.xml or to jboss-deployment-structure.xml in my deployment but that approach did not work.
> 
>  
> [1] row 3 of Table 2-1 in https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html <https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html>
> 
> -- 
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
> 
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> 
> -- 
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
> 
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
> 
> 
> 
> -- 
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
> 
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
> 
> 
> 
> -- 
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
> 
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/51c2e1e8/attachment-0001.html 

From rodakr at gmx.ch  Mon Feb 15 17:03:40 2016
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Mon, 15 Feb 2016 23:03:40 +0100
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
Message-ID: <595B7D36-DE69-46A3-A3A3-02A29A922481@gmx.ch>

?. and what would be the reason for any Java Client calling Weblogic, not to use oracle recommended way, faster Client "t3 thin client? with include Cluster Support and developed for 3-td part JEE App servers :-)
According to oracle interoperability list Java SE IIOP Client is without web logic cluster support.
https://docs.oracle.com/middleware/1221/wls/SACLT/basics.htm#SACLT121 ( -> look for  Foreign Server Applications )

P.S:

Of cours the best would be to move Application to Wildfly and just call Wildfly :-)

Cheers Radek


Am 14.02.2016 um 23:40 schrieb Michael Musgrove <mmusgrov at redhat.com>:

> I am attempting to lookup a remote EJB from WildFly to WLS.
> 
> If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the WildFly end:
>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
> 
> If I use the default wildfly name service (new InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean")) I get the following error on the WLS end (presumably because I am not using CNCtxFactory):
>   "A RuntimeException was generated by the RMI server: weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
> 
> I did try adding the CosNaming dependency (<path name="com/sun/jndi/cosnaming"/>) to modules/system/layers/base/sun/jdk/main/module.xml or to jboss-deployment-structure.xml in my deployment but that approach did not work.
> 
>  
> [1] row 3 of Table 2-1 in https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
> 
> -- 
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com
> t: +44 191 243 0870
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
> 
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/004a5436/attachment.html 

From stuart.w.douglas at gmail.com  Mon Feb 15 17:08:47 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 15 Feb 2016 22:08:47 +0000
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <FA135825-5474-427A-B8F2-597F945A50BC@redhat.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
	<CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
	<CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>
	<CACKZbavubtYf_3knTROjsQvLYeiqq946AEPimD5fB2ByVwQTwg@mail.gmail.com>
	<CALaezvXHLgeepn2sw4OJO3HNijtcXtm1Tuvp82zodvr-S3tD8A@mail.gmail.com>
	<FA135825-5474-427A-B8F2-597F945A50BC@redhat.com>
Message-ID: <CAAoo=c6UsKbSKJNwUfJy8i-iV1LKceGvLa=2ZSOJoT7ORqfuiQ@mail.gmail.com>

So something that may work if you are not using CORBA except as a client is
to exclude our openjdk modules that contain our CORBA classes, and then
import the underlying JDK ones directly.

This will stop you using JTS or anything else that requires CORBA on the
server though, so it would not be a great solution (and may not actually
work).

Stuart

On Tue, 16 Feb 2016 at 04:19 Jason Greene <jason.greene at redhat.com> wrote:

> Right, the issue is that we need to pull over
> ?com.sun.jndi.cosnaming.CNCtxFactory? into our openjdk subsystem, otherwise
> that class will see the wrong corba impl.
>
> On Feb 15, 2016, at 6:44 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
>
> It seems that
> https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/org/jboss/com/sun/corba/se/impl/corba/CORBAObjectImpl.html
> does implement
> http://docs.oracle.com/javase/7/docs/api/org/omg/CORBA/Object.html so my
> guess is that the org.omg.CORBA classes are coming out of a different
> classloader to the com.sun.corba.se.impl.corba ones.
>
> On 15 February 2016 at 12:14, Michael Musgrove <mmusgrov at redhat.com>
> wrote:
>
>> Thanks,
>>
>> That has got me much further. Now I can successfully lookup the EJB that
>> is on WLS but when I narrow (using PortableRemoteObject.narrow) the object
>> I get java.lang.ClassCastException:
>> com.sun.corba.se.impl.corba.CORBAObjectImpl cannot be cast to
>> org.omg.CORBA.Object
>>
>> I guess that is a different issue but I cannot figure out how to proceed
>> - any ideas?
>>
>> On Mon, Feb 15, 2016 at 9:50 AM, Stuart Douglas <
>> stuart.w.douglas at gmail.com> wrote:
>>
>>> Did you try adding com.sun.corba.se.internal.Interceptors to the
>>> jboss-deployment-structure.xml file?
>>>
>>> Stuart
>>>
>>> On Mon, 15 Feb 2016 at 20:27 Michael Musgrove <mmusgrov at redhat.com>
>>> wrote:
>>>
>>>> Wait you asked for the stacktrace when I include the dependency in jboss-deployment-structure.xml,
>>>> sorry - here is the error when I do that:
>>>>
>>>> 2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean]
>>>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>>>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>>>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>>>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>>>> Failed instantiate InitialContextFactory
>>>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>>>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>>>> Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate
>>>> default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB
>>>>  vmcid: 0x0  minor code: 0  completed: No]
>>>> at
>>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>>>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>>>> at
>>>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>>>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>>>> at
>>>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>>>> at
>>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>>>> at
>>>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>>>> at javax.naming.InitialContext.init(InitialContext.java:244)
>>>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>>>> at
>>>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>>>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>>> at
>>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>>> at
>>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>>>> at
>>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>>>> at
>>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>>> at
>>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>>>> at
>>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>> at
>>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>>>> at
>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>>>> at
>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>>> at
>>>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>>>> at
>>>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>>> at
>>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>>>> at
>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>> at
>>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>> at
>>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>>>> at
>>>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>>>> at
>>>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>>>> at
>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>>>> at
>>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>>>> at
>>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>>>> at
>>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>>>> at
>>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>>>> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB
>>>> implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0
>>>>  minor code: 0  completed: No
>>>> at org.omg.CORBA.ORB.create_impl(ORB.java:311)
>>>> at org.omg.CORBA.ORB.init(ORB.java:351)
>>>> at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
>>>> at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
>>>> at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
>>>> at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
>>>> at
>>>> com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
>>>> at
>>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
>>>> ... 87 more
>>>> Caused by: java.lang.ClassCastException: class
>>>> com.sun.corba.se.internal.Interceptors.PIORB
>>>> at java.lang.Class.asSubclass(Class.java:3404)
>>>> at org.omg.CORBA.ORB.create_impl(ORB.java:308)
>>>> ... 94 more
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com>
>>>> wrote:
>>>>
>>>>> The lookup code is:
>>>>>
>>>>>     private ISession getRemoteSession() throws Throwable {
>>>>>         final Properties env = new Properties();
>>>>>         env.put(Context.INITIAL_CONTEXT_FACTORY,
>>>>> "com.sun.jndi.cosnaming.CNCtxFactory");
>>>>>         env.put(Context.PROVIDER_URL,
>>>>> "corbaloc::localhost:7001/NameService");
>>>>>
>>>>>         final InitialContext context = new InitialContext(env);
>>>>>         final Object iiopObj = context.lookup("SessionBean");
>>>>>         return
>>>>> ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj,
>>>>> ISessionHome.class)).create();
>>>>>     }
>>>>>
>>>>> and the stacktrace is:
>>>>>
>>>>> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean]
>>>>> (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate
>>>>> InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader
>>>>> ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main"
>>>>> from Service Module Loader: javax.naming.NamingException: WFLYNAM0027:
>>>>> Failed instantiate InitialContextFactory
>>>>> com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for
>>>>> Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module
>>>>> Loader [Root exception is java.lang.ClassNotFoundException:
>>>>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>>>>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
>>>>> at
>>>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>>>>> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>>>>> at
>>>>> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>>>>> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>>>>> at
>>>>> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>>>>> at
>>>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>>>>> at
>>>>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>>>>> at javax.naming.InitialContext.init(InitialContext.java:244)
>>>>> at javax.naming.InitialContext.<init>(InitialContext.java:216)
>>>>> at
>>>>> support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>>>>> at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>>>> at
>>>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>>>> at
>>>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>>>>> at
>>>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>>>>> at
>>>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>>>>> at
>>>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>>>>> at
>>>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>>> at
>>>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>>>>> at
>>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>>>>> at
>>>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>>>> at
>>>>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>>>>> at
>>>>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>>>>> at
>>>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>>>>> at
>>>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>>>>> at
>>>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>>> at
>>>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>>>>> at
>>>>> org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>>>>> at
>>>>> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>>>>> at
>>>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>>>>> at
>>>>> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>>>>> at
>>>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>>>>> at
>>>>> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>> com.sun.jndi.cosnaming.CNCtxFactory from [Module
>>>>> "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
>>>>> at
>>>>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
>>>>> at
>>>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
>>>>> at
>>>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
>>>>> at
>>>>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
>>>>> at
>>>>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
>>>>> at java.lang.Class.forName0(Native Method)
>>>>> at java.lang.Class.forName(Class.java:348)
>>>>> at
>>>>> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
>>>>> ... 87 more
>>>>>
>>>>>
>>>>> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <
>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>
>>>>>> Oops, disregard that, looks like it is actually not defined in any of
>>>>>> our pre-defined modules.
>>>>>>
>>>>>> What is the full stack trace you get when you include the path in
>>>>>> your jboss-deployment-structure.xml ? (and what does this file look like)
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <
>>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>>
>>>>>>> You should be able to use this if you have a dependency on the
>>>>>>> sun.jdk module.
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I am attempting to lookup a remote EJB from WildFly to WLS.
>>>>>>>>
>>>>>>>> If I use COSNaming as required by [1] (by setting
>>>>>>>> INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the
>>>>>>>> following error on the WildFly end:
>>>>>>>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>>>>>>>>
>>>>>>>> If I use the default wildfly name service (new
>>>>>>>> InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean"))
>>>>>>>> I get the following error on the WLS end (presumably because I am not
>>>>>>>> using CNCtxFactory):
>>>>>>>>   "A RuntimeException was generated by the RMI server:
>>>>>>>> weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>>>>>>>>
>>>>>>>> I did try adding the CosNaming dependency (<path
>>>>>>>> name="com/sun/jndi/cosnaming"/>) to
>>>>>>>> modules/system/layers/base/sun/jdk/main/module.xml or to
>>>>>>>> jboss-deployment-structure.xml in my deployment but that approach did not
>>>>>>>> work.
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] row 3 of Table 2-1 in
>>>>>>>> https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael Musgrove
>>>>>>>> Transactions Team
>>>>>>>> e: mmusgrov at redhat.com
>>>>>>>> t: +44 191 243 0870
>>>>>>>>
>>>>>>>> Registered in England and Wales under Company Registration No.
>>>>>>>> 03798903
>>>>>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt
>>>>>>>> Parson
>>>>>>>> (US), Charles Peters (US)
>>>>>>>>
>>>>>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
>>>>>>>> Michael O'Neill(Ireland)
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Musgrove
>>>>> Transactions Team
>>>>> e: mmusgrov at redhat.com
>>>>> t: +44 191 243 0870
>>>>>
>>>>> Registered in England and Wales under Company Registration No. 03798903
>>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>>>> (US), Charles Peters (US)
>>>>>
>>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US),
>>>>> Michael O'Neill(Ireland)
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Musgrove
>>>> Transactions Team
>>>> e: mmusgrov at redhat.com
>>>> t: +44 191 243 0870
>>>>
>>>> Registered in England and Wales under Company Registration No. 03798903
>>>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>>>> (US), Charles Peters (US)
>>>>
>>>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>>>> O'Neill(Ireland)
>>>>
>>>
>>
>>
>> --
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com
>> t: +44 191 243 0870
>>
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>>
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael
>> O'Neill(Ireland)
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/2c435484/attachment-0001.html 

From jason.greene at redhat.com  Mon Feb 15 17:15:17 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 15 Feb 2016 16:15:17 -0600
Subject: [wildfly-dev] How to use CNCtxFactory from WildFly
In-Reply-To: <CAAoo=c6UsKbSKJNwUfJy8i-iV1LKceGvLa=2ZSOJoT7ORqfuiQ@mail.gmail.com>
References: <CACKZbatvqfSREfs=6TfYKTeu-Dxa1SfkCoPf8yogXsuNmZm1EA@mail.gmail.com>
	<CAAoo=c4vXVNqU2bFVg+dMPiefC7x3U3jdAeaPT9nRuh9hohMPg@mail.gmail.com>
	<CAAoo=c4KpdDZO+eQnU0ZsBAu+NeOrjhd=KYgv_mMWvhGB=+cTw@mail.gmail.com>
	<CACKZbavKBJgMsx6Ubk6HkagOPNHDV1Pya+37aEY7BYWmV6oocg@mail.gmail.com>
	<CACKZbatXdVF0NQXS+yz2kvqUxeFeyKcCd4AFvy9wu9fKSgXZJw@mail.gmail.com>
	<CAAoo=c6Qxds5YgVZPUBr-m5dWL9umRx+gixRLOksN4SWQkA=cw@mail.gmail.com>
	<CACKZbavubtYf_3knTROjsQvLYeiqq946AEPimD5fB2ByVwQTwg@mail.gmail.com>
	<CALaezvXHLgeepn2sw4OJO3HNijtcXtm1Tuvp82zodvr-S3tD8A@mail.gmail.com>
	<FA135825-5474-427A-B8F2-597F945A50BC@redhat.com>
	<CAAoo=c6UsKbSKJNwUfJy8i-iV1LKceGvLa=2ZSOJoT7ORqfuiQ@mail.gmail.com>
Message-ID: <4EA2E26A-77D2-4C0E-96E0-8414C2D0AFEB@redhat.com>

So I just checked, and it looks like we already have something here?.

org.wildfly.iiop.openjdk.naming.jndi.JBossCNCtxFactory

and 

org.wildfly.iiop.openjdk.naming.jndi.CNCtxFactory



> On Feb 15, 2016, at 4:08 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> So something that may work if you are not using CORBA except as a client is to exclude our openjdk modules that contain our CORBA classes, and then import the underlying JDK ones directly.
> 
> This will stop you using JTS or anything else that requires CORBA on the server though, so it would not be a great solution (and may not actually work).
> 
> Stuart
> 
> On Tue, 16 Feb 2016 at 04:19 Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> Right, the issue is that we need to pull over ?com.sun.jndi.cosnaming.CNCtxFactory? into our openjdk subsystem, otherwise that class will see the wrong corba impl.
> 
>> On Feb 15, 2016, at 6:44 AM, Tom Jenkinson <tom.jenkinson at redhat.com <mailto:tom.jenkinson at redhat.com>> wrote:
>> 
>> It seems that https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/org/jboss/com/sun/corba/se/impl/corba/CORBAObjectImpl.html <https://docs.jboss.org/jbossas/javadoc/7.1.2.Final/org/jboss/com/sun/corba/se/impl/corba/CORBAObjectImpl.html> does implement http://docs.oracle.com/javase/7/docs/api/org/omg/CORBA/Object.html <http://docs.oracle.com/javase/7/docs/api/org/omg/CORBA/Object.html> so my guess is that the org.omg.CORBA classes are coming out of a different classloader to the com.sun.corba.se.impl.corba ones.
>> 
>> On 15 February 2016 at 12:14, Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
>> Thanks,
>> 
>> That has got me much further. Now I can successfully lookup the EJB that is on WLS but when I narrow (using PortableRemoteObject.narrow) the object I get java.lang.ClassCastException: com.sun.corba.se.impl.corba.CORBAObjectImpl cannot be cast to org.omg.CORBA.Object
>> 
>> I guess that is a different issue but I cannot figure out how to proceed - any ideas?
>> 
>> On Mon, Feb 15, 2016 at 9:50 AM, Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>> Did you try adding com.sun.corba.se.internal.Interceptors to the jboss-deployment-structure.xml file?
>> 
>> Stuart
>> 
>> On Mon, 15 Feb 2016 at 20:27 Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
>> Wait you asked for the stacktrace when I include the dependency in jboss-deployment-structure.xml, sorry - here is the error when I do that:
>> 
>> 2016-02-15 09:24:15,210 SEVERE [support.jboss.ejb.session.SessionBean] (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader [Root exception is org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0  minor code: 0  completed: No]
>> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>> 	at javax.naming.InitialContext.init(InitialContext.java:244)
>> 	at javax.naming.InitialContext.<init>(InitialContext.java:216)
>> 	at support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>> 	at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:497)
>> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>> 	at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation com.sun.corba.se.internal.Interceptors.PIORB  vmcid: 0x0  minor code: 0  completed: No
>> 	at org.omg.CORBA.ORB.create_impl(ORB.java:311)
>> 	at org.omg.CORBA.ORB.init(ORB.java:351)
>> 	at com.sun.jndi.toolkit.corba.CorbaUtils.getOrb(CorbaUtils.java:203)
>> 	at com.sun.jndi.cosnaming.CNCtx.getDefaultOrb(CNCtx.java:71)
>> 	at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:235)
>> 	at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
>> 	at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
>> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
>> 	... 87 more
>> Caused by: java.lang.ClassCastException: class com.sun.corba.se.internal.Interceptors.PIORB
>> 	at java.lang.Class.asSubclass(Class.java:3404)
>> 	at org.omg.CORBA.ORB.create_impl(ORB.java:308)
>> 	... 94 more
>> 
>> 
>> 
>> 
>> 
>> On Mon, Feb 15, 2016 at 9:23 AM, Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
>> The lookup code is:
>> 
>>     private ISession getRemoteSession() throws Throwable {
>>         final Properties env = new Properties();
>>         env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
>>         env.put(Context.PROVIDER_URL, "corbaloc::localhost:7001/NameService");
>> 
>>         final InitialContext context = new InitialContext(env);
>>         final Object iiopObj = context.lookup("SessionBean");
>>         return ISessionHome.class.cast(javax.rmi.PortableRemoteObject.narrow(iiopObj, ISessionHome.class)).create();
>>     }
>> 
>> and the stacktrace is:
>> 
>> 2016-02-15 09:18:47,720 SEVERE [support.jboss.ejb.session.SessionBean] (p: default-threadpool; w: Idle) WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.cosnaming.CNCtxFactory from classloader ModuleClassLoader for Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory from [Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]]
>> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
>> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
>> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
>> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
>> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>> 	at javax.naming.InitialContext.init(InitialContext.java:244)
>> 	at javax.naming.InitialContext.<init>(InitialContext.java:216)
>> 	at support.jboss.ejb.session.SessionBean.getRemoteSession(SessionBean.java:289)
>> 	at support.jboss.ejb.session.SessionBean.test(SessionBean.java:156)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:497)
>> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
>> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
>> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
>> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
>> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
>> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor.processInvocation(EjbIIOPTransactionInterceptor.java:71)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>> 	at org.jboss.as.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:318)
>> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
>> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
>> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
>> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
>> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
>> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
>> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
>> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
>> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory from [Module "deployment.jboss.eap-1.0-SNAPSHOT.jar:main" from Service Module Loader]
>> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
>> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
>> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
>> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
>> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
>> 	at java.lang.Class.forName0(Native Method)
>> 	at java.lang.Class.forName(Class.java:348)
>> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
>> 	... 87 more
>> 
>> 
>> On Sun, Feb 14, 2016 at 10:46 PM, Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>> Oops, disregard that, looks like it is actually not defined in any of our pre-defined modules.
>> 
>> What is the full stack trace you get when you include the path in your jboss-deployment-structure.xml ? (and what does this file look like)
>> 
>> Stuart
>> 
>> On Mon, 15 Feb 2016 at 09:44 Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>> You should be able to use this if you have a dependency on the sun.jdk module.
>> 
>> Stuart
>> 
>> On Mon, 15 Feb 2016 at 09:41 Michael Musgrove <mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>> wrote:
>> I am attempting to lookup a remote EJB from WildFly to WLS.
>> 
>> If I use COSNaming as required by [1] (by setting INITIAL_CONTEXT_FACTORY to "com.sun.jndi.cosnaming.CNCtxFactory") I get the following error on the WildFly end:
>>   "ClassNotFoundException: com.sun.jndi.cosnaming.CNCtxFactory"
>> 
>> If I use the default wildfly name service (new InitialContext().lookup("corbaname:iiop:localhost:7001/NameService#SessionBean")) I get the following error on the WLS end (presumably because I am not using CNCtxFactory):
>>   "A RuntimeException was generated by the RMI server: weblogic.corba.cos.naming.RootNamingContextImpl.resolve([Lorg.omg.CosNaming.NameComponent"
>> 
>> I did try adding the CosNaming dependency (<path name="com/sun/jndi/cosnaming"/>) to modules/system/layers/base/sun/jdk/main/module.xml or to jboss-deployment-structure.xml in my deployment but that approach did not work.
>> 
>>  
>> [1] row 3 of Table 2-1 in https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html <https://docs.oracle.com/cd/E13222_01/wls/docs81/rmi_iiop/rmiiiop2.html>
>> 
>> -- 
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
>> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
>> 
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>> 
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> 
>> 
>> -- 
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
>> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
>> 
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>> 
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>> 
>> 
>> 
>> -- 
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
>> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
>> 
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>> 
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>> 
>> 
>> 
>> -- 
>> Michael Musgrove
>> Transactions Team
>> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
>> t: +44 191 243 0870 <tel:%2B44%20191%20243%200870>
>> 
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
>> (US), Charles Peters (US)
>> 
>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160215/2043f1e9/attachment-0001.html 

From sanne at hibernate.org  Thu Feb 18 06:11:31 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 18 Feb 2016 11:11:31 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56BD4F25.9020304@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
Message-ID: <CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>

It seems we're discussing this issue in multiple places,
so to let you all know I'll repeat it hare:
I think shading is a really really bad idea :)

Could we try to have the enhanced entities to not need Javassist in in
their *direct* classloader; we can still have a normal Javassist as a
module dependency of Hibernate?
That would require to just make sure the generated bytecode doesn't
directly refer to Javassist types but uses an indirection controlled
by Hibernate code.. which in turn can use Javassist or even
alternatives in future, if we'd like to experiment.

I'm not familiar enough with Javassist to know if that's an option
as-is but we can either improve Javassist to allow such a thing or use
some alternatives, like Gunnar and Hardy also suggested on the
hibernate-dev mailing list.

To summarize, I agree with Stuart and would hope that Scott's branch
can be improved by minimizing the amount of Javassist code which
actually needs to be copied by using some simple delegation to
Hibernte types, which in turn can use a private, non-shaded Javassist
taking advantage of the isolation provided by JBoss Modules.

--Sanne



On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
> What if Javassist packaged these same (proxy/runtime) classes in a
> separate javassist-runtime jar and we shaded only the proxy/runtime
> classes?  That way we only repackage the same classes that we included
> for this hack test (e.g.
> org.hibernate.bytecode.internal.javassist.proxy.*).
>
> Early testing results of the hack test look good
> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>
> Scott
>
> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>> It depends if you are going to shade all the javassist classes or just
>> the "javassist.util.proxy" package (not sure if this is actually
>> possible with the shade plugin).
>>
>> The main advantage is that you can upgrade javassist to get fixes to
>> issues that affect bytecode generation. So if JDK9 comes out with new
>> bytecodes that the current version of Javassist does not understand then
>> upgrading javassist will allow the older version of hibernate to work
>> with classes compiled against the newer JDK version. If all of javassist
>> is shaded into hibernate then that version of hibernate will never work
>> with the newer bytecodes.
>>
>> I think this is less of an issue if you are still publishing the
>> non-Javassist shaded hibernate as well as a shaded version, but if the
>> only published artifact has javassist shaded in then it may limit
>> forward compatibility.
>>
>> Stuart
>>
>>
>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>> <mailto:steve at hibernate.org>> wrote:
>>
>>     Ugh.  That is an awful lot of classes copied over.  What exactly was
>>     the benefit of this over shading again?  I mean both case lose the
>>     ability to simply drop in fixes from upstream Javassist.  So what
>>     does this "clone" approach gain versus shadowing?
>>
>>
>>
>>     On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>>     <mailto:smarlow at redhat.com>> wrote:
>>
>>          >>
>>          >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>          >>       > Have you considered a 3rd alternative, which is to
>>         use a custom
>>          >>       > ProxyFactory instead of javassists built in one?
>>          >>       >
>>          >>       > AFAIK the main issue is that javassist proxies
>>         require access to the
>>          >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>>         classes. You
>>          >>      could
>>          >>       > create a similar org.hibernate interface, and a
>>         proxy factory
>>          >>      that uses
>>          >>       > this method handler instead.
>>          >>       >
>>          >>       > Basically you just copy the code from
>>         javassist.util.proxy into
>>          >>       > hibernate. This is a relatively small amount of
>>         code, so it
>>          >>      should not
>>          >>       > really add any maintenance burden.
>>          >>
>>          >>      We talked about this as well via [1].  I understand the
>>         concept but have
>>          >>      not tried doing this.  I like this approach as well, if
>>         it works.  One
>>          >>      of the cons with cloning that Steve Ebersole pointed
>>         out (see response
>>          >>      on Feb-03-2016 9:01am), is that that users lose the
>>         ability to drop a
>>          >>      different version of Javassist in (since we maintain
>>         our own cloned copy
>>          >>      of the Javassist proxy/runtime code).
>>          >>
>>          >>
>>          >> The proxy code is a relatively small part of javassist, so
>>         unless a bug
>>          >> is in the proxy code itself this should not be that big a deal.
>>          >
>>          > Thanks for the encouragement to go down this path.  :)
>>          >
>>
>>         Started a hack attempt at the clone via
>>         https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>>         Seems
>>         to pass the Hibernate ORM unit tests.
>>
>>         Scott
>>
>>         _______________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From gunnar at hibernate.org  Thu Feb 18 06:35:40 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 18 Feb 2016 12:35:40 +0100
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
Message-ID: <CADGJaX_F+7rdTULjT_iK_z6XfkiPSM6bRB7+9vfiEdZ7j0k+0A@mail.gmail.com>

My branch at https://github.com/gunnarmorling/hibernate-orm/tree/HHH-10536
is exactly doing this (using ByteBuddy).

Generated proxy types invoke java.lang.reflect.InvocationHandler, i.e.
no dependency to any library. Of course the same could be done either
using ASM directly or ripping ProxyFactory out of Javassist and adapt
it to do the same.

--Gunnar


2016-02-18 12:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> It seems we're discussing this issue in multiple places,
> so to let you all know I'll repeat it hare:
> I think shading is a really really bad idea :)
>
> Could we try to have the enhanced entities to not need Javassist in in
> their *direct* classloader; we can still have a normal Javassist as a
> module dependency of Hibernate?
> That would require to just make sure the generated bytecode doesn't
> directly refer to Javassist types but uses an indirection controlled
> by Hibernate code.. which in turn can use Javassist or even
> alternatives in future, if we'd like to experiment.
>
> I'm not familiar enough with Javassist to know if that's an option
> as-is but we can either improve Javassist to allow such a thing or use
> some alternatives, like Gunnar and Hardy also suggested on the
> hibernate-dev mailing list.
>
> To summarize, I agree with Stuart and would hope that Scott's branch
> can be improved by minimizing the amount of Javassist code which
> actually needs to be copied by using some simple delegation to
> Hibernte types, which in turn can use a private, non-shaded Javassist
> taking advantage of the isolation provided by JBoss Modules.
>
> --Sanne
>
>
>
> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>> What if Javassist packaged these same (proxy/runtime) classes in a
>> separate javassist-runtime jar and we shaded only the proxy/runtime
>> classes?  That way we only repackage the same classes that we included
>> for this hack test (e.g.
>> org.hibernate.bytecode.internal.javassist.proxy.*).
>>
>> Early testing results of the hack test look good
>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>>
>> Scott
>>
>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>>> It depends if you are going to shade all the javassist classes or just
>>> the "javassist.util.proxy" package (not sure if this is actually
>>> possible with the shade plugin).
>>>
>>> The main advantage is that you can upgrade javassist to get fixes to
>>> issues that affect bytecode generation. So if JDK9 comes out with new
>>> bytecodes that the current version of Javassist does not understand then
>>> upgrading javassist will allow the older version of hibernate to work
>>> with classes compiled against the newer JDK version. If all of javassist
>>> is shaded into hibernate then that version of hibernate will never work
>>> with the newer bytecodes.
>>>
>>> I think this is less of an issue if you are still publishing the
>>> non-Javassist shaded hibernate as well as a shaded version, but if the
>>> only published artifact has javassist shaded in then it may limit
>>> forward compatibility.
>>>
>>> Stuart
>>>
>>>
>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>>> <mailto:steve at hibernate.org>> wrote:
>>>
>>>     Ugh.  That is an awful lot of classes copied over.  What exactly was
>>>     the benefit of this over shading again?  I mean both case lose the
>>>     ability to simply drop in fixes from upstream Javassist.  So what
>>>     does this "clone" approach gain versus shadowing?
>>>
>>>
>>>
>>>     On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>>>     <mailto:smarlow at redhat.com>> wrote:
>>>
>>>          >>
>>>          >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>>          >>       > Have you considered a 3rd alternative, which is to
>>>         use a custom
>>>          >>       > ProxyFactory instead of javassists built in one?
>>>          >>       >
>>>          >>       > AFAIK the main issue is that javassist proxies
>>>         require access to the
>>>          >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>>>         classes. You
>>>          >>      could
>>>          >>       > create a similar org.hibernate interface, and a
>>>         proxy factory
>>>          >>      that uses
>>>          >>       > this method handler instead.
>>>          >>       >
>>>          >>       > Basically you just copy the code from
>>>         javassist.util.proxy into
>>>          >>       > hibernate. This is a relatively small amount of
>>>         code, so it
>>>          >>      should not
>>>          >>       > really add any maintenance burden.
>>>          >>
>>>          >>      We talked about this as well via [1].  I understand the
>>>         concept but have
>>>          >>      not tried doing this.  I like this approach as well, if
>>>         it works.  One
>>>          >>      of the cons with cloning that Steve Ebersole pointed
>>>         out (see response
>>>          >>      on Feb-03-2016 9:01am), is that that users lose the
>>>         ability to drop a
>>>          >>      different version of Javassist in (since we maintain
>>>         our own cloned copy
>>>          >>      of the Javassist proxy/runtime code).
>>>          >>
>>>          >>
>>>          >> The proxy code is a relatively small part of javassist, so
>>>         unless a bug
>>>          >> is in the proxy code itself this should not be that big a deal.
>>>          >
>>>          > Thanks for the encouragement to go down this path.  :)
>>>          >
>>>
>>>         Started a hack attempt at the clone via
>>>         https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>>>         Seems
>>>         to pass the Hibernate ORM unit tests.
>>>
>>>         Scott
>>>
>>>         _______________________________________________
>>>         wildfly-dev mailing list
>>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>
>>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From cdewolf at redhat.com  Thu Feb 18 13:17:22 2016
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Thu, 18 Feb 2016 19:17:22 +0100
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
Message-ID: <56C60AB2.8040606@redhat.com>

Looks to me like Hibernate is exposing bad proxies to the user.

Would it not be possible to use a custom class loader at the point where 
the proxy is defined?
Than you could use one that takes the version of javassist that 
Hibernate requires and delegates everything else to the deployment class 
loader.

I don't like to see any sort of shading as this means the full 
maintenance burden of those classes are carried over into Hibernate.

Carlo

On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
> It seems we're discussing this issue in multiple places,
> so to let you all know I'll repeat it hare:
> I think shading is a really really bad idea :)
>
> Could we try to have the enhanced entities to not need Javassist in in
> their *direct* classloader; we can still have a normal Javassist as a
> module dependency of Hibernate?
> That would require to just make sure the generated bytecode doesn't
> directly refer to Javassist types but uses an indirection controlled
> by Hibernate code.. which in turn can use Javassist or even
> alternatives in future, if we'd like to experiment.
>
> I'm not familiar enough with Javassist to know if that's an option
> as-is but we can either improve Javassist to allow such a thing or use
> some alternatives, like Gunnar and Hardy also suggested on the
> hibernate-dev mailing list.
>
> To summarize, I agree with Stuart and would hope that Scott's branch
> can be improved by minimizing the amount of Javassist code which
> actually needs to be copied by using some simple delegation to
> Hibernte types, which in turn can use a private, non-shaded Javassist
> taking advantage of the isolation provided by JBoss Modules.
>
> --Sanne
>
>
>
> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>> What if Javassist packaged these same (proxy/runtime) classes in a
>> separate javassist-runtime jar and we shaded only the proxy/runtime
>> classes?  That way we only repackage the same classes that we included
>> for this hack test (e.g.
>> org.hibernate.bytecode.internal.javassist.proxy.*).
>>
>> Early testing results of the hack test look good
>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>>
>> Scott
>>
>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>>> It depends if you are going to shade all the javassist classes or just
>>> the "javassist.util.proxy" package (not sure if this is actually
>>> possible with the shade plugin).
>>>
>>> The main advantage is that you can upgrade javassist to get fixes to
>>> issues that affect bytecode generation. So if JDK9 comes out with new
>>> bytecodes that the current version of Javassist does not understand then
>>> upgrading javassist will allow the older version of hibernate to work
>>> with classes compiled against the newer JDK version. If all of javassist
>>> is shaded into hibernate then that version of hibernate will never work
>>> with the newer bytecodes.
>>>
>>> I think this is less of an issue if you are still publishing the
>>> non-Javassist shaded hibernate as well as a shaded version, but if the
>>> only published artifact has javassist shaded in then it may limit
>>> forward compatibility.
>>>
>>> Stuart
>>>
>>>
>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>>> <mailto:steve at hibernate.org>> wrote:
>>>
>>>      Ugh.  That is an awful lot of classes copied over.  What exactly was
>>>      the benefit of this over shading again?  I mean both case lose the
>>>      ability to simply drop in fixes from upstream Javassist.  So what
>>>      does this "clone" approach gain versus shadowing?
>>>
>>>
>>>
>>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>>>      <mailto:smarlow at redhat.com>> wrote:
>>>
>>>           >>
>>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>>           >>       > Have you considered a 3rd alternative, which is to
>>>          use a custom
>>>           >>       > ProxyFactory instead of javassists built in one?
>>>           >>       >
>>>           >>       > AFAIK the main issue is that javassist proxies
>>>          require access to the
>>>           >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>>>          classes. You
>>>           >>      could
>>>           >>       > create a similar org.hibernate interface, and a
>>>          proxy factory
>>>           >>      that uses
>>>           >>       > this method handler instead.
>>>           >>       >
>>>           >>       > Basically you just copy the code from
>>>          javassist.util.proxy into
>>>           >>       > hibernate. This is a relatively small amount of
>>>          code, so it
>>>           >>      should not
>>>           >>       > really add any maintenance burden.
>>>           >>
>>>           >>      We talked about this as well via [1].  I understand the
>>>          concept but have
>>>           >>      not tried doing this.  I like this approach as well, if
>>>          it works.  One
>>>           >>      of the cons with cloning that Steve Ebersole pointed
>>>          out (see response
>>>           >>      on Feb-03-2016 9:01am), is that that users lose the
>>>          ability to drop a
>>>           >>      different version of Javassist in (since we maintain
>>>          our own cloned copy
>>>           >>      of the Javassist proxy/runtime code).
>>>           >>
>>>           >>
>>>           >> The proxy code is a relatively small part of javassist, so
>>>          unless a bug
>>>           >> is in the proxy code itself this should not be that big a deal.
>>>           >
>>>           > Thanks for the encouragement to go down this path.  :)
>>>           >
>>>
>>>          Started a hack attempt at the clone via
>>>          https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>>>          Seems
>>>          to pass the Hibernate ORM unit tests.
>>>
>>>          Scott
>>>
>>>          _______________________________________________
>>>          wildfly-dev mailing list
>>>          wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>
>>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From steve at hibernate.org  Thu Feb 18 13:26:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Feb 2016 18:26:48 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56C60AB2.8040606@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<56C60AB2.8040606@redhat.com>
Message-ID: <CAFdSV9vUZgLnc99D=e779yQpgTBUhDYUfMMw5hV725k8QKgZTA@mail.gmail.com>

Guys chill about the shading :)  That was only ever mentioned as a
preference over the original suggestion to copy large number of classes
from Javassist into Hibernate source.  I simply said that if we are copying
these classes from Javassist that shading would be a better option for
achieving that.  Neither of those are really good options, but forced to
choose between the 2 I'd chose shading.

I think we all agree that (if possible) Hibernate not using using Javassist
at all beyond actually generating the proxy and/or enhancing would be the
best option.  So if this is possible lets go that route.

On Thu, Feb 18, 2016 at 12:17 PM Carlo de Wolf <cdewolf at redhat.com> wrote:

> Looks to me like Hibernate is exposing bad proxies to the user.
>
> Would it not be possible to use a custom class loader at the point where
> the proxy is defined?
> Than you could use one that takes the version of javassist that
> Hibernate requires and delegates everything else to the deployment class
> loader.
>
> I don't like to see any sort of shading as this means the full
> maintenance burden of those classes are carried over into Hibernate.
>
> Carlo
>
> On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
> > It seems we're discussing this issue in multiple places,
> > so to let you all know I'll repeat it hare:
> > I think shading is a really really bad idea :)
> >
> > Could we try to have the enhanced entities to not need Javassist in in
> > their *direct* classloader; we can still have a normal Javassist as a
> > module dependency of Hibernate?
> > That would require to just make sure the generated bytecode doesn't
> > directly refer to Javassist types but uses an indirection controlled
> > by Hibernate code.. which in turn can use Javassist or even
> > alternatives in future, if we'd like to experiment.
> >
> > I'm not familiar enough with Javassist to know if that's an option
> > as-is but we can either improve Javassist to allow such a thing or use
> > some alternatives, like Gunnar and Hardy also suggested on the
> > hibernate-dev mailing list.
> >
> > To summarize, I agree with Stuart and would hope that Scott's branch
> > can be improved by minimizing the amount of Javassist code which
> > actually needs to be copied by using some simple delegation to
> > Hibernte types, which in turn can use a private, non-shaded Javassist
> > taking advantage of the isolation provided by JBoss Modules.
> >
> > --Sanne
> >
> >
> >
> > On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
> >> What if Javassist packaged these same (proxy/runtime) classes in a
> >> separate javassist-runtime jar and we shaded only the proxy/runtime
> >> classes?  That way we only repackage the same classes that we included
> >> for this hack test (e.g.
> >> org.hibernate.bytecode.internal.javassist.proxy.*).
> >>
> >> Early testing results of the hack test look good
> >> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
> >>
> >> Scott
> >>
> >> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
> >>> It depends if you are going to shade all the javassist classes or just
> >>> the "javassist.util.proxy" package (not sure if this is actually
> >>> possible with the shade plugin).
> >>>
> >>> The main advantage is that you can upgrade javassist to get fixes to
> >>> issues that affect bytecode generation. So if JDK9 comes out with new
> >>> bytecodes that the current version of Javassist does not understand
> then
> >>> upgrading javassist will allow the older version of hibernate to work
> >>> with classes compiled against the newer JDK version. If all of
> javassist
> >>> is shaded into hibernate then that version of hibernate will never work
> >>> with the newer bytecodes.
> >>>
> >>> I think this is less of an issue if you are still publishing the
> >>> non-Javassist shaded hibernate as well as a shaded version, but if the
> >>> only published artifact has javassist shaded in then it may limit
> >>> forward compatibility.
> >>>
> >>> Stuart
> >>>
> >>>
> >>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
> >>> <mailto:steve at hibernate.org>> wrote:
> >>>
> >>>      Ugh.  That is an awful lot of classes copied over.  What exactly
> was
> >>>      the benefit of this over shading again?  I mean both case lose the
> >>>      ability to simply drop in fixes from upstream Javassist.  So what
> >>>      does this "clone" approach gain versus shadowing?
> >>>
> >>>
> >>>
> >>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
> >>>      <mailto:smarlow at redhat.com>> wrote:
> >>>
> >>>           >>
> >>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
> >>>           >>       > Have you considered a 3rd alternative, which is to
> >>>          use a custom
> >>>           >>       > ProxyFactory instead of javassists built in one?
> >>>           >>       >
> >>>           >>       > AFAIK the main issue is that javassist proxies
> >>>          require access to the
> >>>           >>       >
> 'javassist.util.proxy.MethodHandler|RuntimeSupport'
> >>>          classes. You
> >>>           >>      could
> >>>           >>       > create a similar org.hibernate interface, and a
> >>>          proxy factory
> >>>           >>      that uses
> >>>           >>       > this method handler instead.
> >>>           >>       >
> >>>           >>       > Basically you just copy the code from
> >>>          javassist.util.proxy into
> >>>           >>       > hibernate. This is a relatively small amount of
> >>>          code, so it
> >>>           >>      should not
> >>>           >>       > really add any maintenance burden.
> >>>           >>
> >>>           >>      We talked about this as well via [1].  I understand
> the
> >>>          concept but have
> >>>           >>      not tried doing this.  I like this approach as well,
> if
> >>>          it works.  One
> >>>           >>      of the cons with cloning that Steve Ebersole pointed
> >>>          out (see response
> >>>           >>      on Feb-03-2016 9:01am), is that that users lose the
> >>>          ability to drop a
> >>>           >>      different version of Javassist in (since we maintain
> >>>          our own cloned copy
> >>>           >>      of the Javassist proxy/runtime code).
> >>>           >>
> >>>           >>
> >>>           >> The proxy code is a relatively small part of javassist, so
> >>>          unless a bug
> >>>           >> is in the proxy code itself this should not be that big a
> deal.
> >>>           >
> >>>           > Thanks for the encouragement to go down this path.  :)
> >>>           >
> >>>
> >>>          Started a hack attempt at the clone via
> >>>
> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
> >>>          Seems
> >>>          to pass the Hibernate ORM unit tests.
> >>>
> >>>          Scott
> >>>
> >>>          _______________________________________________
> >>>          wildfly-dev mailing list
> >>>          wildfly-dev at lists.jboss.org <mailto:
> wildfly-dev at lists.jboss.org>
> >>>
> >>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160218/a1305808/attachment-0001.html 

From steve at hibernate.org  Thu Feb 18 14:00:23 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Feb 2016 19:00:23 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CADGJaX_F+7rdTULjT_iK_z6XfkiPSM6bRB7+9vfiEdZ7j0k+0A@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<CADGJaX_F+7rdTULjT_iK_z6XfkiPSM6bRB7+9vfiEdZ7j0k+0A@mail.gmail.com>
Message-ID: <CAFdSV9tNb4R1mng7WTUk+Bh-PCbDr=yVrvJwKkDY9AGhPejHhw@mail.gmail.com>

This is definitely an interesting option.  I actually think the same could
be achieved with Javassist too however.  That said, Javassist definitely
has drawbacks.  I am not familiar with ByteBuddy.


On Thu, Feb 18, 2016 at 5:35 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> My branch at https://github.com/gunnarmorling/hibernate-orm/tree/HHH-10536
> is exactly doing this (using ByteBuddy).
>
> Generated proxy types invoke java.lang.reflect.InvocationHandler, i.e.
> no dependency to any library. Of course the same could be done either
> using ASM directly or ripping ProxyFactory out of Javassist and adapt
> it to do the same.
>
> --Gunnar
>
>
> 2016-02-18 12:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > It seems we're discussing this issue in multiple places,
> > so to let you all know I'll repeat it hare:
> > I think shading is a really really bad idea :)
> >
> > Could we try to have the enhanced entities to not need Javassist in in
> > their *direct* classloader; we can still have a normal Javassist as a
> > module dependency of Hibernate?
> > That would require to just make sure the generated bytecode doesn't
> > directly refer to Javassist types but uses an indirection controlled
> > by Hibernate code.. which in turn can use Javassist or even
> > alternatives in future, if we'd like to experiment.
> >
> > I'm not familiar enough with Javassist to know if that's an option
> > as-is but we can either improve Javassist to allow such a thing or use
> > some alternatives, like Gunnar and Hardy also suggested on the
> > hibernate-dev mailing list.
> >
> > To summarize, I agree with Stuart and would hope that Scott's branch
> > can be improved by minimizing the amount of Javassist code which
> > actually needs to be copied by using some simple delegation to
> > Hibernte types, which in turn can use a private, non-shaded Javassist
> > taking advantage of the isolation provided by JBoss Modules.
> >
> > --Sanne
> >
> >
> >
> > On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
> >> What if Javassist packaged these same (proxy/runtime) classes in a
> >> separate javassist-runtime jar and we shaded only the proxy/runtime
> >> classes?  That way we only repackage the same classes that we included
> >> for this hack test (e.g.
> >> org.hibernate.bytecode.internal.javassist.proxy.*).
> >>
> >> Early testing results of the hack test look good
> >> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
> >>
> >> Scott
> >>
> >> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
> >>> It depends if you are going to shade all the javassist classes or just
> >>> the "javassist.util.proxy" package (not sure if this is actually
> >>> possible with the shade plugin).
> >>>
> >>> The main advantage is that you can upgrade javassist to get fixes to
> >>> issues that affect bytecode generation. So if JDK9 comes out with new
> >>> bytecodes that the current version of Javassist does not understand
> then
> >>> upgrading javassist will allow the older version of hibernate to work
> >>> with classes compiled against the newer JDK version. If all of
> javassist
> >>> is shaded into hibernate then that version of hibernate will never work
> >>> with the newer bytecodes.
> >>>
> >>> I think this is less of an issue if you are still publishing the
> >>> non-Javassist shaded hibernate as well as a shaded version, but if the
> >>> only published artifact has javassist shaded in then it may limit
> >>> forward compatibility.
> >>>
> >>> Stuart
> >>>
> >>>
> >>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
> >>> <mailto:steve at hibernate.org>> wrote:
> >>>
> >>>     Ugh.  That is an awful lot of classes copied over.  What exactly
> was
> >>>     the benefit of this over shading again?  I mean both case lose the
> >>>     ability to simply drop in fixes from upstream Javassist.  So what
> >>>     does this "clone" approach gain versus shadowing?
> >>>
> >>>
> >>>
> >>>     On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
> >>>     <mailto:smarlow at redhat.com>> wrote:
> >>>
> >>>          >>
> >>>          >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
> >>>          >>       > Have you considered a 3rd alternative, which is to
> >>>         use a custom
> >>>          >>       > ProxyFactory instead of javassists built in one?
> >>>          >>       >
> >>>          >>       > AFAIK the main issue is that javassist proxies
> >>>         require access to the
> >>>          >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
> >>>         classes. You
> >>>          >>      could
> >>>          >>       > create a similar org.hibernate interface, and a
> >>>         proxy factory
> >>>          >>      that uses
> >>>          >>       > this method handler instead.
> >>>          >>       >
> >>>          >>       > Basically you just copy the code from
> >>>         javassist.util.proxy into
> >>>          >>       > hibernate. This is a relatively small amount of
> >>>         code, so it
> >>>          >>      should not
> >>>          >>       > really add any maintenance burden.
> >>>          >>
> >>>          >>      We talked about this as well via [1].  I understand
> the
> >>>         concept but have
> >>>          >>      not tried doing this.  I like this approach as well,
> if
> >>>         it works.  One
> >>>          >>      of the cons with cloning that Steve Ebersole pointed
> >>>         out (see response
> >>>          >>      on Feb-03-2016 9:01am), is that that users lose the
> >>>         ability to drop a
> >>>          >>      different version of Javassist in (since we maintain
> >>>         our own cloned copy
> >>>          >>      of the Javassist proxy/runtime code).
> >>>          >>
> >>>          >>
> >>>          >> The proxy code is a relatively small part of javassist, so
> >>>         unless a bug
> >>>          >> is in the proxy code itself this should not be that big a
> deal.
> >>>          >
> >>>          > Thanks for the encouragement to go down this path.  :)
> >>>          >
> >>>
> >>>         Started a hack attempt at the clone via
> >>>
> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
> >>>         Seems
> >>>         to pass the Hibernate ORM unit tests.
> >>>
> >>>         Scott
> >>>
> >>>         _______________________________________________
> >>>         wildfly-dev mailing list
> >>>         wildfly-dev at lists.jboss.org <mailto:
> wildfly-dev at lists.jboss.org>
> >>>
> >>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160218/3efa0d12/attachment.html 

From smarlow at redhat.com  Fri Feb 19 12:41:35 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 19 Feb 2016 12:41:35 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
Message-ID: <56C753CF.9060001@redhat.com>


On 02/18/2016 06:11 AM, Sanne Grinovero wrote:
> It seems we're discussing this issue in multiple places,
> so to let you all know I'll repeat it hare:

I don't really like discussing the same issue on multiple lists but I 
thought it made sense to ask here for further input (especially since I 
would like to create a PR for the updated ORM that solves this problem 
and having some buy in now that the PR will get merged, is helpful). :)

> I think shading is a really really bad idea :)
>
> Could we try to have the enhanced entities to not need Javassist in in
> their *direct* classloader; we can still have a normal Javassist as a
> module dependency of Hibernate?
> That would require to just make sure the generated bytecode doesn't
> directly refer to Javassist types but uses an indirection controlled
> by Hibernate code.. which in turn can use Javassist or even
> alternatives in future, if we'd like to experiment.
>
> I'm not familiar enough with Javassist to know if that's an option
> as-is but we can either improve Javassist to allow such a thing or use
> some alternatives, like Gunnar and Hardy also suggested on the
> hibernate-dev mailing list.
>
> To summarize, I agree with Stuart and would hope that Scott's branch
> can be improved by minimizing the amount of Javassist code which
> actually needs to be copied by using some simple delegation to
> Hibernte types, which in turn can use a private, non-shaded Javassist
> taking advantage of the isolation provided by JBoss Modules.

 From a timing point of view, it seems to me that it will likely take a 
while before a future release of Hibernate ORM addresses this.  If I am 
wrong about that, great.  But, I think that leaves the following options 
for WildFly 10.1.0 and the proposed pr [1]:

A. Remove the private API label from the WildFly javassist static module 
so that Hibernate native applications can depend on Javassist without 
fear that their application may fail to deploy in the future because of 
the Javassist dependency.

B.  Stick with the current [1] hack of exporting the Javassist 
dependency to applications that have a dependency on the Hibernate ORM 
module.

Scott

[1] https://github.com/wildfly/wildfly/pull/8474 which has a sad "fix 
me" label.

From smarlow at redhat.com  Fri Feb 19 12:42:50 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 19 Feb 2016 12:42:50 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CADGJaX_F+7rdTULjT_iK_z6XfkiPSM6bRB7+9vfiEdZ7j0k+0A@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<CADGJaX_F+7rdTULjT_iK_z6XfkiPSM6bRB7+9vfiEdZ7j0k+0A@mail.gmail.com>
Message-ID: <56C7541A.3040207@redhat.com>

It will be interesting to see what happens when we run the WildFly 
testsuite with your branch.  Thanks for jumping in Gunnar on helping! :-)

On 02/18/2016 06:35 AM, Gunnar Morling wrote:
> My branch at https://github.com/gunnarmorling/hibernate-orm/tree/HHH-10536
> is exactly doing this (using ByteBuddy).
>
> Generated proxy types invoke java.lang.reflect.InvocationHandler, i.e.
> no dependency to any library. Of course the same could be done either
> using ASM directly or ripping ProxyFactory out of Javassist and adapt
> it to do the same.
>
> --Gunnar
>
>
> 2016-02-18 12:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> It seems we're discussing this issue in multiple places,
>> so to let you all know I'll repeat it hare:
>> I think shading is a really really bad idea :)
>>
>> Could we try to have the enhanced entities to not need Javassist in in
>> their *direct* classloader; we can still have a normal Javassist as a
>> module dependency of Hibernate?
>> That would require to just make sure the generated bytecode doesn't
>> directly refer to Javassist types but uses an indirection controlled
>> by Hibernate code.. which in turn can use Javassist or even
>> alternatives in future, if we'd like to experiment.
>>
>> I'm not familiar enough with Javassist to know if that's an option
>> as-is but we can either improve Javassist to allow such a thing or use
>> some alternatives, like Gunnar and Hardy also suggested on the
>> hibernate-dev mailing list.
>>
>> To summarize, I agree with Stuart and would hope that Scott's branch
>> can be improved by minimizing the amount of Javassist code which
>> actually needs to be copied by using some simple delegation to
>> Hibernte types, which in turn can use a private, non-shaded Javassist
>> taking advantage of the isolation provided by JBoss Modules.
>>
>> --Sanne
>>
>>
>>
>> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>>> What if Javassist packaged these same (proxy/runtime) classes in a
>>> separate javassist-runtime jar and we shaded only the proxy/runtime
>>> classes?  That way we only repackage the same classes that we included
>>> for this hack test (e.g.
>>> org.hibernate.bytecode.internal.javassist.proxy.*).
>>>
>>> Early testing results of the hack test look good
>>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>>>
>>> Scott
>>>
>>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>>>> It depends if you are going to shade all the javassist classes or just
>>>> the "javassist.util.proxy" package (not sure if this is actually
>>>> possible with the shade plugin).
>>>>
>>>> The main advantage is that you can upgrade javassist to get fixes to
>>>> issues that affect bytecode generation. So if JDK9 comes out with new
>>>> bytecodes that the current version of Javassist does not understand then
>>>> upgrading javassist will allow the older version of hibernate to work
>>>> with classes compiled against the newer JDK version. If all of javassist
>>>> is shaded into hibernate then that version of hibernate will never work
>>>> with the newer bytecodes.
>>>>
>>>> I think this is less of an issue if you are still publishing the
>>>> non-Javassist shaded hibernate as well as a shaded version, but if the
>>>> only published artifact has javassist shaded in then it may limit
>>>> forward compatibility.
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>>>> <mailto:steve at hibernate.org>> wrote:
>>>>
>>>>      Ugh.  That is an awful lot of classes copied over.  What exactly was
>>>>      the benefit of this over shading again?  I mean both case lose the
>>>>      ability to simply drop in fixes from upstream Javassist.  So what
>>>>      does this "clone" approach gain versus shadowing?
>>>>
>>>>
>>>>
>>>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>>>>      <mailto:smarlow at redhat.com>> wrote:
>>>>
>>>>           >>
>>>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>>>           >>       > Have you considered a 3rd alternative, which is to
>>>>          use a custom
>>>>           >>       > ProxyFactory instead of javassists built in one?
>>>>           >>       >
>>>>           >>       > AFAIK the main issue is that javassist proxies
>>>>          require access to the
>>>>           >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>>>>          classes. You
>>>>           >>      could
>>>>           >>       > create a similar org.hibernate interface, and a
>>>>          proxy factory
>>>>           >>      that uses
>>>>           >>       > this method handler instead.
>>>>           >>       >
>>>>           >>       > Basically you just copy the code from
>>>>          javassist.util.proxy into
>>>>           >>       > hibernate. This is a relatively small amount of
>>>>          code, so it
>>>>           >>      should not
>>>>           >>       > really add any maintenance burden.
>>>>           >>
>>>>           >>      We talked about this as well via [1].  I understand the
>>>>          concept but have
>>>>           >>      not tried doing this.  I like this approach as well, if
>>>>          it works.  One
>>>>           >>      of the cons with cloning that Steve Ebersole pointed
>>>>          out (see response
>>>>           >>      on Feb-03-2016 9:01am), is that that users lose the
>>>>          ability to drop a
>>>>           >>      different version of Javassist in (since we maintain
>>>>          our own cloned copy
>>>>           >>      of the Javassist proxy/runtime code).
>>>>           >>
>>>>           >>
>>>>           >> The proxy code is a relatively small part of javassist, so
>>>>          unless a bug
>>>>           >> is in the proxy code itself this should not be that big a deal.
>>>>           >
>>>>           > Thanks for the encouragement to go down this path.  :)
>>>>           >
>>>>
>>>>          Started a hack attempt at the clone via
>>>>          https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>>>>          Seems
>>>>          to pass the Hibernate ORM unit tests.
>>>>
>>>>          Scott
>>>>
>>>>          _______________________________________________
>>>>          wildfly-dev mailing list
>>>>          wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>
>>>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From smarlow at redhat.com  Fri Feb 19 12:47:18 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 19 Feb 2016 12:47:18 -0500
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56C60AB2.8040606@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<56C60AB2.8040606@redhat.com>
Message-ID: <56C75526.3040202@redhat.com>



On 02/18/2016 01:17 PM, Carlo de Wolf wrote:
> Looks to me like Hibernate is exposing bad proxies to the user.

Its not bad or new, just how we always did it.  Other Javassist users 
have also done the same and ended up shading Javassist classes.

>
> Would it not be possible to use a custom class loader at the point where
> the proxy is defined?
> Than you could use one that takes the version of javassist that
> Hibernate requires and delegates everything else to the deployment class
> loader.

This sounds similar to my https://github.com/wildfly/wildfly/pull/8474 
pull request that changes the Hibernate ORM static module to export the 
Javassist classes.

>
> I don't like to see any sort of shading as this means the full
> maintenance burden of those classes are carried over into Hibernate.
>
> Carlo
>
> On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
>> It seems we're discussing this issue in multiple places,
>> so to let you all know I'll repeat it hare:
>> I think shading is a really really bad idea :)
>>
>> Could we try to have the enhanced entities to not need Javassist in in
>> their *direct* classloader; we can still have a normal Javassist as a
>> module dependency of Hibernate?
>> That would require to just make sure the generated bytecode doesn't
>> directly refer to Javassist types but uses an indirection controlled
>> by Hibernate code.. which in turn can use Javassist or even
>> alternatives in future, if we'd like to experiment.
>>
>> I'm not familiar enough with Javassist to know if that's an option
>> as-is but we can either improve Javassist to allow such a thing or use
>> some alternatives, like Gunnar and Hardy also suggested on the
>> hibernate-dev mailing list.
>>
>> To summarize, I agree with Stuart and would hope that Scott's branch
>> can be improved by minimizing the amount of Javassist code which
>> actually needs to be copied by using some simple delegation to
>> Hibernte types, which in turn can use a private, non-shaded Javassist
>> taking advantage of the isolation provided by JBoss Modules.
>>
>> --Sanne
>>
>>
>>
>> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>>> What if Javassist packaged these same (proxy/runtime) classes in a
>>> separate javassist-runtime jar and we shaded only the proxy/runtime
>>> classes?  That way we only repackage the same classes that we included
>>> for this hack test (e.g.
>>> org.hibernate.bytecode.internal.javassist.proxy.*).
>>>
>>> Early testing results of the hack test look good
>>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>>>
>>> Scott
>>>
>>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>>>> It depends if you are going to shade all the javassist classes or just
>>>> the "javassist.util.proxy" package (not sure if this is actually
>>>> possible with the shade plugin).
>>>>
>>>> The main advantage is that you can upgrade javassist to get fixes to
>>>> issues that affect bytecode generation. So if JDK9 comes out with new
>>>> bytecodes that the current version of Javassist does not understand
>>>> then
>>>> upgrading javassist will allow the older version of hibernate to work
>>>> with classes compiled against the newer JDK version. If all of
>>>> javassist
>>>> is shaded into hibernate then that version of hibernate will never work
>>>> with the newer bytecodes.
>>>>
>>>> I think this is less of an issue if you are still publishing the
>>>> non-Javassist shaded hibernate as well as a shaded version, but if the
>>>> only published artifact has javassist shaded in then it may limit
>>>> forward compatibility.
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>>>> <mailto:steve at hibernate.org>> wrote:
>>>>
>>>>      Ugh.  That is an awful lot of classes copied over.  What
>>>> exactly was
>>>>      the benefit of this over shading again?  I mean both case lose the
>>>>      ability to simply drop in fixes from upstream Javassist.  So what
>>>>      does this "clone" approach gain versus shadowing?
>>>>
>>>>
>>>>
>>>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>>>>      <mailto:smarlow at redhat.com>> wrote:
>>>>
>>>>           >>
>>>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>>>           >>       > Have you considered a 3rd alternative, which is to
>>>>          use a custom
>>>>           >>       > ProxyFactory instead of javassists built in one?
>>>>           >>       >
>>>>           >>       > AFAIK the main issue is that javassist proxies
>>>>          require access to the
>>>>           >>       >
>>>> 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>>>>          classes. You
>>>>           >>      could
>>>>           >>       > create a similar org.hibernate interface, and a
>>>>          proxy factory
>>>>           >>      that uses
>>>>           >>       > this method handler instead.
>>>>           >>       >
>>>>           >>       > Basically you just copy the code from
>>>>          javassist.util.proxy into
>>>>           >>       > hibernate. This is a relatively small amount of
>>>>          code, so it
>>>>           >>      should not
>>>>           >>       > really add any maintenance burden.
>>>>           >>
>>>>           >>      We talked about this as well via [1].  I
>>>> understand the
>>>>          concept but have
>>>>           >>      not tried doing this.  I like this approach as
>>>> well, if
>>>>          it works.  One
>>>>           >>      of the cons with cloning that Steve Ebersole pointed
>>>>          out (see response
>>>>           >>      on Feb-03-2016 9:01am), is that that users lose the
>>>>          ability to drop a
>>>>           >>      different version of Javassist in (since we maintain
>>>>          our own cloned copy
>>>>           >>      of the Javassist proxy/runtime code).
>>>>           >>
>>>>           >>
>>>>           >> The proxy code is a relatively small part of javassist, so
>>>>          unless a bug
>>>>           >> is in the proxy code itself this should not be that big
>>>> a deal.
>>>>           >
>>>>           > Thanks for the encouragement to go down this path.  :)
>>>>           >
>>>>
>>>>          Started a hack attempt at the clone via
>>>>
>>>> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>>>>          Seems
>>>>          to pass the Hibernate ORM unit tests.
>>>>
>>>>          Scott
>>>>
>>>>          _______________________________________________
>>>>          wildfly-dev mailing list
>>>>          wildfly-dev at lists.jboss.org
>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>
>>>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>

From pbenedict at apache.org  Fri Feb 19 14:55:49 2016
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 19 Feb 2016 13:55:49 -0600
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <56C75526.3040202@redhat.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<56C60AB2.8040606@redhat.com> <56C75526.3040202@redhat.com>
Message-ID: <CABLGb9xj1BeDq0QjMCApKVpbFLjWAQfRVnpWvBmeuDDXaAk93A@mail.gmail.com>

I think the answer should depend on how the Hibernate developers view
Javassist. Is Javassist seen as a pluggable part of the API? Or is it seen
as fundamentally an internal component? If it's the former, then do not
shade it; otherwise do shade it. I think the latter is very sensible as
long as that perspective is maintained in the code base.

Cheers,
Paul

On Fri, Feb 19, 2016 at 11:47 AM, Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 02/18/2016 01:17 PM, Carlo de Wolf wrote:
> > Looks to me like Hibernate is exposing bad proxies to the user.
>
> Its not bad or new, just how we always did it.  Other Javassist users
> have also done the same and ended up shading Javassist classes.
>
> >
> > Would it not be possible to use a custom class loader at the point where
> > the proxy is defined?
> > Than you could use one that takes the version of javassist that
> > Hibernate requires and delegates everything else to the deployment class
> > loader.
>
> This sounds similar to my https://github.com/wildfly/wildfly/pull/8474
> pull request that changes the Hibernate ORM static module to export the
> Javassist classes.
>
> >
> > I don't like to see any sort of shading as this means the full
> > maintenance burden of those classes are carried over into Hibernate.
> >
> > Carlo
> >
> > On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
> >> It seems we're discussing this issue in multiple places,
> >> so to let you all know I'll repeat it hare:
> >> I think shading is a really really bad idea :)
> >>
> >> Could we try to have the enhanced entities to not need Javassist in in
> >> their *direct* classloader; we can still have a normal Javassist as a
> >> module dependency of Hibernate?
> >> That would require to just make sure the generated bytecode doesn't
> >> directly refer to Javassist types but uses an indirection controlled
> >> by Hibernate code.. which in turn can use Javassist or even
> >> alternatives in future, if we'd like to experiment.
> >>
> >> I'm not familiar enough with Javassist to know if that's an option
> >> as-is but we can either improve Javassist to allow such a thing or use
> >> some alternatives, like Gunnar and Hardy also suggested on the
> >> hibernate-dev mailing list.
> >>
> >> To summarize, I agree with Stuart and would hope that Scott's branch
> >> can be improved by minimizing the amount of Javassist code which
> >> actually needs to be copied by using some simple delegation to
> >> Hibernte types, which in turn can use a private, non-shaded Javassist
> >> taking advantage of the isolation provided by JBoss Modules.
> >>
> >> --Sanne
> >>
> >>
> >>
> >> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
> >>> What if Javassist packaged these same (proxy/runtime) classes in a
> >>> separate javassist-runtime jar and we shaded only the proxy/runtime
> >>> classes?  That way we only repackage the same classes that we included
> >>> for this hack test (e.g.
> >>> org.hibernate.bytecode.internal.javassist.proxy.*).
> >>>
> >>> Early testing results of the hack test look good
> >>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
> >>>
> >>> Scott
> >>>
> >>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
> >>>> It depends if you are going to shade all the javassist classes or just
> >>>> the "javassist.util.proxy" package (not sure if this is actually
> >>>> possible with the shade plugin).
> >>>>
> >>>> The main advantage is that you can upgrade javassist to get fixes to
> >>>> issues that affect bytecode generation. So if JDK9 comes out with new
> >>>> bytecodes that the current version of Javassist does not understand
> >>>> then
> >>>> upgrading javassist will allow the older version of hibernate to work
> >>>> with classes compiled against the newer JDK version. If all of
> >>>> javassist
> >>>> is shaded into hibernate then that version of hibernate will never
> work
> >>>> with the newer bytecodes.
> >>>>
> >>>> I think this is less of an issue if you are still publishing the
> >>>> non-Javassist shaded hibernate as well as a shaded version, but if the
> >>>> only published artifact has javassist shaded in then it may limit
> >>>> forward compatibility.
> >>>>
> >>>> Stuart
> >>>>
> >>>>
> >>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
> >>>> <mailto:steve at hibernate.org>> wrote:
> >>>>
> >>>>      Ugh.  That is an awful lot of classes copied over.  What
> >>>> exactly was
> >>>>      the benefit of this over shading again?  I mean both case lose
> the
> >>>>      ability to simply drop in fixes from upstream Javassist.  So what
> >>>>      does this "clone" approach gain versus shadowing?
> >>>>
> >>>>
> >>>>
> >>>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
> >>>>      <mailto:smarlow at redhat.com>> wrote:
> >>>>
> >>>>           >>
> >>>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
> >>>>           >>       > Have you considered a 3rd alternative, which is
> to
> >>>>          use a custom
> >>>>           >>       > ProxyFactory instead of javassists built in one?
> >>>>           >>       >
> >>>>           >>       > AFAIK the main issue is that javassist proxies
> >>>>          require access to the
> >>>>           >>       >
> >>>> 'javassist.util.proxy.MethodHandler|RuntimeSupport'
> >>>>          classes. You
> >>>>           >>      could
> >>>>           >>       > create a similar org.hibernate interface, and a
> >>>>          proxy factory
> >>>>           >>      that uses
> >>>>           >>       > this method handler instead.
> >>>>           >>       >
> >>>>           >>       > Basically you just copy the code from
> >>>>          javassist.util.proxy into
> >>>>           >>       > hibernate. This is a relatively small amount of
> >>>>          code, so it
> >>>>           >>      should not
> >>>>           >>       > really add any maintenance burden.
> >>>>           >>
> >>>>           >>      We talked about this as well via [1].  I
> >>>> understand the
> >>>>          concept but have
> >>>>           >>      not tried doing this.  I like this approach as
> >>>> well, if
> >>>>          it works.  One
> >>>>           >>      of the cons with cloning that Steve Ebersole pointed
> >>>>          out (see response
> >>>>           >>      on Feb-03-2016 9:01am), is that that users lose the
> >>>>          ability to drop a
> >>>>           >>      different version of Javassist in (since we maintain
> >>>>          our own cloned copy
> >>>>           >>      of the Javassist proxy/runtime code).
> >>>>           >>
> >>>>           >>
> >>>>           >> The proxy code is a relatively small part of javassist,
> so
> >>>>          unless a bug
> >>>>           >> is in the proxy code itself this should not be that big
> >>>> a deal.
> >>>>           >
> >>>>           > Thanks for the encouragement to go down this path.  :)
> >>>>           >
> >>>>
> >>>>          Started a hack attempt at the clone via
> >>>>
> >>>> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
> >>>>          Seems
> >>>>          to pass the Hibernate ORM unit tests.
> >>>>
> >>>>          Scott
> >>>>
> >>>>          _______________________________________________
> >>>>          wildfly-dev mailing list
> >>>>          wildfly-dev at lists.jboss.org
> >>>> <mailto:wildfly-dev at lists.jboss.org>
> >>>>
> >>>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160219/3514c6cb/attachment-0001.html 

From steve at hibernate.org  Fri Feb 19 15:59:24 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 19 Feb 2016 20:59:24 +0000
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CABLGb9xj1BeDq0QjMCApKVpbFLjWAQfRVnpWvBmeuDDXaAk93A@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<56C60AB2.8040606@redhat.com> <56C75526.3040202@redhat.com>
	<CABLGb9xj1BeDq0QjMCApKVpbFLjWAQfRVnpWvBmeuDDXaAk93A@mail.gmail.com>
Message-ID: <CAFdSV9uiFiT2xHVaOe_JGK+XcCXyzJ=d=7Z1AstEMyCu+Sfrig@mail.gmail.com>

Personally I do not see this distinction as the important factor.  I get
what you are saying, and if we intentionally were exposing Javassist as an
API detail I would agree that copying and shading would be bad.  But I say
it is not important because even though I do *not* view Javassist as
something we intentionally expose as an API detail I still think it is
important to copy/shade only as a last resort.

The mistake in our current OOTB bytecode manipulation implementation seems
to be that we expose some of its impl details (usage of Javassist) into the
manipulated bytecode.  What I like specifically about the some of the
suggestions here so far (and Gunnar's work IIUC) is that it splits this
problem into distinct concerns:

   1. Actually performing the manipulation and/or proxy generation
   2. Runtime usage of that manipulated class or proxy.

So I can use Javassist or ByteBuddy or ASM or ... to deal with (1) as long
as that choice does not leak into (2).  That is the important part to me.

That's the best option IMO if possible.  And I think it is.

On Fri, Feb 19, 2016 at 1:56 PM Paul Benedict <pbenedict at apache.org> wrote:

> I think the answer should depend on how the Hibernate developers view
> Javassist. Is Javassist seen as a pluggable part of the API? Or is it seen
> as fundamentally an internal component? If it's the former, then do not
> shade it; otherwise do shade it. I think the latter is very sensible as
> long as that perspective is maintained in the code base.
>
> Cheers,
> Paul
>
> On Fri, Feb 19, 2016 at 11:47 AM, Scott Marlow <smarlow at redhat.com> wrote:
>
>>
>>
>> On 02/18/2016 01:17 PM, Carlo de Wolf wrote:
>> > Looks to me like Hibernate is exposing bad proxies to the user.
>>
>> Its not bad or new, just how we always did it.  Other Javassist users
>> have also done the same and ended up shading Javassist classes.
>>
>> >
>> > Would it not be possible to use a custom class loader at the point where
>> > the proxy is defined?
>> > Than you could use one that takes the version of javassist that
>> > Hibernate requires and delegates everything else to the deployment class
>> > loader.
>>
>> This sounds similar to my https://github.com/wildfly/wildfly/pull/8474
>> pull request that changes the Hibernate ORM static module to export the
>> Javassist classes.
>>
>> >
>> > I don't like to see any sort of shading as this means the full
>> > maintenance burden of those classes are carried over into Hibernate.
>> >
>> > Carlo
>> >
>> > On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
>> >> It seems we're discussing this issue in multiple places,
>> >> so to let you all know I'll repeat it hare:
>> >> I think shading is a really really bad idea :)
>> >>
>> >> Could we try to have the enhanced entities to not need Javassist in in
>> >> their *direct* classloader; we can still have a normal Javassist as a
>> >> module dependency of Hibernate?
>> >> That would require to just make sure the generated bytecode doesn't
>> >> directly refer to Javassist types but uses an indirection controlled
>> >> by Hibernate code.. which in turn can use Javassist or even
>> >> alternatives in future, if we'd like to experiment.
>> >>
>> >> I'm not familiar enough with Javassist to know if that's an option
>> >> as-is but we can either improve Javassist to allow such a thing or use
>> >> some alternatives, like Gunnar and Hardy also suggested on the
>> >> hibernate-dev mailing list.
>> >>
>> >> To summarize, I agree with Stuart and would hope that Scott's branch
>> >> can be improved by minimizing the amount of Javassist code which
>> >> actually needs to be copied by using some simple delegation to
>> >> Hibernte types, which in turn can use a private, non-shaded Javassist
>> >> taking advantage of the isolation provided by JBoss Modules.
>> >>
>> >> --Sanne
>> >>
>> >>
>> >>
>> >> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>> >>> What if Javassist packaged these same (proxy/runtime) classes in a
>> >>> separate javassist-runtime jar and we shaded only the proxy/runtime
>> >>> classes?  That way we only repackage the same classes that we included
>> >>> for this hack test (e.g.
>> >>> org.hibernate.bytecode.internal.javassist.proxy.*).
>> >>>
>> >>> Early testing results of the hack test look good
>> >>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>> >>>
>> >>> Scott
>> >>>
>> >>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>> >>>> It depends if you are going to shade all the javassist classes or
>> just
>> >>>> the "javassist.util.proxy" package (not sure if this is actually
>> >>>> possible with the shade plugin).
>> >>>>
>> >>>> The main advantage is that you can upgrade javassist to get fixes to
>> >>>> issues that affect bytecode generation. So if JDK9 comes out with new
>> >>>> bytecodes that the current version of Javassist does not understand
>> >>>> then
>> >>>> upgrading javassist will allow the older version of hibernate to work
>> >>>> with classes compiled against the newer JDK version. If all of
>> >>>> javassist
>> >>>> is shaded into hibernate then that version of hibernate will never
>> work
>> >>>> with the newer bytecodes.
>> >>>>
>> >>>> I think this is less of an issue if you are still publishing the
>> >>>> non-Javassist shaded hibernate as well as a shaded version, but if
>> the
>> >>>> only published artifact has javassist shaded in then it may limit
>> >>>> forward compatibility.
>> >>>>
>> >>>> Stuart
>> >>>>
>> >>>>
>> >>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>> >>>> <mailto:steve at hibernate.org>> wrote:
>> >>>>
>> >>>>      Ugh.  That is an awful lot of classes copied over.  What
>> >>>> exactly was
>> >>>>      the benefit of this over shading again?  I mean both case lose
>> the
>> >>>>      ability to simply drop in fixes from upstream Javassist.  So
>> what
>> >>>>      does this "clone" approach gain versus shadowing?
>> >>>>
>> >>>>
>> >>>>
>> >>>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <
>> smarlow at redhat.com
>> >>>>      <mailto:smarlow at redhat.com>> wrote:
>> >>>>
>> >>>>           >>
>> >>>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>> >>>>           >>       > Have you considered a 3rd alternative, which is
>> to
>> >>>>          use a custom
>> >>>>           >>       > ProxyFactory instead of javassists built in one?
>> >>>>           >>       >
>> >>>>           >>       > AFAIK the main issue is that javassist proxies
>> >>>>          require access to the
>> >>>>           >>       >
>> >>>> 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>> >>>>          classes. You
>> >>>>           >>      could
>> >>>>           >>       > create a similar org.hibernate interface, and a
>> >>>>          proxy factory
>> >>>>           >>      that uses
>> >>>>           >>       > this method handler instead.
>> >>>>           >>       >
>> >>>>           >>       > Basically you just copy the code from
>> >>>>          javassist.util.proxy into
>> >>>>           >>       > hibernate. This is a relatively small amount of
>> >>>>          code, so it
>> >>>>           >>      should not
>> >>>>           >>       > really add any maintenance burden.
>> >>>>           >>
>> >>>>           >>      We talked about this as well via [1].  I
>> >>>> understand the
>> >>>>          concept but have
>> >>>>           >>      not tried doing this.  I like this approach as
>> >>>> well, if
>> >>>>          it works.  One
>> >>>>           >>      of the cons with cloning that Steve Ebersole
>> pointed
>> >>>>          out (see response
>> >>>>           >>      on Feb-03-2016 9:01am), is that that users lose the
>> >>>>          ability to drop a
>> >>>>           >>      different version of Javassist in (since we
>> maintain
>> >>>>          our own cloned copy
>> >>>>           >>      of the Javassist proxy/runtime code).
>> >>>>           >>
>> >>>>           >>
>> >>>>           >> The proxy code is a relatively small part of javassist,
>> so
>> >>>>          unless a bug
>> >>>>           >> is in the proxy code itself this should not be that big
>> >>>> a deal.
>> >>>>           >
>> >>>>           > Thanks for the encouragement to go down this path.  :)
>> >>>>           >
>> >>>>
>> >>>>          Started a hack attempt at the clone via
>> >>>>
>> >>>> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>> >>>>          Seems
>> >>>>          to pass the Hibernate ORM unit tests.
>> >>>>
>> >>>>          Scott
>> >>>>
>> >>>>          _______________________________________________
>> >>>>          wildfly-dev mailing list
>> >>>>          wildfly-dev at lists.jboss.org
>> >>>> <mailto:wildfly-dev at lists.jboss.org>
>> >>>>
>> >>>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160219/f368f8b7/attachment.html 

From gathila1992haris at gmail.com  Sun Feb 21 01:00:07 2016
From: gathila1992haris at gmail.com (gathila harischandra)
Date: Sun, 21 Feb 2016 11:30:07 +0530
Subject: [wildfly-dev] Build failed in MessagingSubsystem30TestCase
Message-ID: <CA+T2GnxLQ8fWArW73Bo+C15chbNhqSLTFBASGumNdgzaLDnmvQ@mail.gmail.com>

Hi all,

I ?m trying to run build.bat and this build failure occurred test set
org.jboss.as.messaging.test.MessagingSubsystem30TestCase



java.lang.RuntimeException:
org.eclipse.aether.resolution.ArtifactResolutionException: Could not
transfer artifact org.jboss.as:jboss-as-messaging:jar:7.3.0.Final-redhat-14
from/to product-repository
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160221/a61cd748/attachment-0001.html 

From eduardo.santanadasilva at gmail.com  Sun Feb 21 11:51:36 2016
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Sun, 21 Feb 2016 13:51:36 -0300
Subject: [wildfly-dev] Build failed in MessagingSubsystem30TestCase
In-Reply-To: <CA+T2GnxLQ8fWArW73Bo+C15chbNhqSLTFBASGumNdgzaLDnmvQ@mail.gmail.com>
References: <CA+T2GnxLQ8fWArW73Bo+C15chbNhqSLTFBASGumNdgzaLDnmvQ@mail.gmail.com>
Message-ID: <CAFVp3Z7iQw4id=X50aiFQe5b3WBYrLeaHxqUvf36+zmkM0L5uQ@mail.gmail.com>

Try mvn clean install -U  instead.


2016-02-21 3:00 GMT-03:00 gathila harischandra <gathila1992haris at gmail.com>:

> Hi all,
>
> I ?m trying to run build.bat and this build failure occurred test set
> org.jboss.as.messaging.test.MessagingSubsystem30TestCase
>
>
>
> java.lang.RuntimeException:
> org.eclipse.aether.resolution.ArtifactResolutionException: Could not
> transfer artifact org.jboss.as:jboss-as-messaging:jar:7.3.0.Final-redhat-14
> from/to product-repository
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160221/eaed664f/attachment.html 

From gunnar at hibernate.org  Sun Feb 21 13:24:23 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 21 Feb 2016 19:24:23 +0100
Subject: [wildfly-dev] private packaging Javassist jar in Hibernate ORM,
 so applications can have their own Javassist jar...
In-Reply-To: <CAFdSV9uiFiT2xHVaOe_JGK+XcCXyzJ=d=7Z1AstEMyCu+Sfrig@mail.gmail.com>
References: <56BCB0DB.8030102@redhat.com>
	<CAAoo=c4nmKmHa-5Lf-TU+zSuW8C+G8mOaKa+rbK8V5BFoXmv-A@mail.gmail.com>
	<56BCF1E3.9050000@redhat.com>
	<CAAoo=c7P_GFdbFGM9z=0WiLB67tN69zZBtGd=N3agdFfm+ONGw@mail.gmail.com>
	<56BD1C05.8030104@redhat.com> <56BD319D.6040304@redhat.com>
	<CAFdSV9sr7W9VSjPrgABFYF5+XSRX5uXUR3YJ-yDPqom+FywZJQ@mail.gmail.com>
	<CAAoo=c7JZXK_sSKHOx3=_Va0kXeKO7osEatGYhhFgg=hEBAUmA@mail.gmail.com>
	<56BD4F25.9020304@redhat.com>
	<CAFm4XO0cJP8hcfW+OTcJgyRdOq0BUQ9fxshqEAzYvNnO7WJ+zA@mail.gmail.com>
	<56C60AB2.8040606@redhat.com> <56C75526.3040202@redhat.com>
	<CABLGb9xj1BeDq0QjMCApKVpbFLjWAQfRVnpWvBmeuDDXaAk93A@mail.gmail.com>
	<CAFdSV9uiFiT2xHVaOe_JGK+XcCXyzJ=d=7Z1AstEMyCu+Sfrig@mail.gmail.com>
Message-ID: <CADGJaX-j4tYnZm06a7bM9hv35_5CK7RF=4M9WC9+=+hReq9CjA@mail.gmail.com>

I've updated the implementation based on ByteBuddy at
https://github.com/gunnarmorling/hibernate-orm/tree/HHH-10536 so it's
passing all tests in ORM now. The implementation is not polished but
should be good enough for doing some testing on WF.

One nice side-effect of using ByteBuddy is that was trivial to
implement BasicProxyFactory so it generates types that use actual
typed fields as the basis for the property getters/setters instead of
the hashmap implementation used in the Javassist implementation. So
that piece should be a bit more efficient, too.

Let me know if there is interest in this implementation, I'd then
clean up some things and also could take a look into providing a
ReflectionOptimizer implementation.

> So I can use Javassist or ByteBuddy or ASM or ... to deal with (1) as long as that choice does not leak into (2).  That is the important part to me.

+1.

As said, the same could be done using plain ASM, but ByteBuddy makes
it just much simpler to achieve this goal.

--Gunnar

2016-02-19 21:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Personally I do not see this distinction as the important factor.  I get
> what you are saying, and if we intentionally were exposing Javassist as an
> API detail I would agree that copying and shading would be bad.  But I say
> it is not important because even though I do *not* view Javassist as
> something we intentionally expose as an API detail I still think it is
> important to copy/shade only as a last resort.
>
> The mistake in our current OOTB bytecode manipulation implementation seems
> to be that we expose some of its impl details (usage of Javassist) into the
> manipulated bytecode.  What I like specifically about the some of the
> suggestions here so far (and Gunnar's work IIUC) is that it splits this
> problem into distinct concerns:
>
> Actually performing the manipulation and/or proxy generation
> Runtime usage of that manipulated class or proxy.
>
> So I can use Javassist or ByteBuddy or ASM or ... to deal with (1) as long
> as that choice does not leak into (2).  That is the important part to me.
>
> That's the best option IMO if possible.  And I think it is.
>
> On Fri, Feb 19, 2016 at 1:56 PM Paul Benedict <pbenedict at apache.org> wrote:
>>
>> I think the answer should depend on how the Hibernate developers view
>> Javassist. Is Javassist seen as a pluggable part of the API? Or is it seen
>> as fundamentally an internal component? If it's the former, then do not
>> shade it; otherwise do shade it. I think the latter is very sensible as long
>> as that perspective is maintained in the code base.
>>
>> Cheers,
>> Paul
>>
>> On Fri, Feb 19, 2016 at 11:47 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>
>>>
>>> On 02/18/2016 01:17 PM, Carlo de Wolf wrote:
>>> > Looks to me like Hibernate is exposing bad proxies to the user.
>>>
>>> Its not bad or new, just how we always did it.  Other Javassist users
>>> have also done the same and ended up shading Javassist classes.
>>>
>>> >
>>> > Would it not be possible to use a custom class loader at the point
>>> > where
>>> > the proxy is defined?
>>> > Than you could use one that takes the version of javassist that
>>> > Hibernate requires and delegates everything else to the deployment
>>> > class
>>> > loader.
>>>
>>> This sounds similar to my https://github.com/wildfly/wildfly/pull/8474
>>> pull request that changes the Hibernate ORM static module to export the
>>> Javassist classes.
>>>
>>> >
>>> > I don't like to see any sort of shading as this means the full
>>> > maintenance burden of those classes are carried over into Hibernate.
>>> >
>>> > Carlo
>>> >
>>> > On 02/18/2016 12:11 PM, Sanne Grinovero wrote:
>>> >> It seems we're discussing this issue in multiple places,
>>> >> so to let you all know I'll repeat it hare:
>>> >> I think shading is a really really bad idea :)
>>> >>
>>> >> Could we try to have the enhanced entities to not need Javassist in in
>>> >> their *direct* classloader; we can still have a normal Javassist as a
>>> >> module dependency of Hibernate?
>>> >> That would require to just make sure the generated bytecode doesn't
>>> >> directly refer to Javassist types but uses an indirection controlled
>>> >> by Hibernate code.. which in turn can use Javassist or even
>>> >> alternatives in future, if we'd like to experiment.
>>> >>
>>> >> I'm not familiar enough with Javassist to know if that's an option
>>> >> as-is but we can either improve Javassist to allow such a thing or use
>>> >> some alternatives, like Gunnar and Hardy also suggested on the
>>> >> hibernate-dev mailing list.
>>> >>
>>> >> To summarize, I agree with Stuart and would hope that Scott's branch
>>> >> can be improved by minimizing the amount of Javassist code which
>>> >> actually needs to be copied by using some simple delegation to
>>> >> Hibernte types, which in turn can use a private, non-shaded Javassist
>>> >> taking advantage of the isolation provided by JBoss Modules.
>>> >>
>>> >> --Sanne
>>> >>
>>> >>
>>> >>
>>> >> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>>> >>> What if Javassist packaged these same (proxy/runtime) classes in a
>>> >>> separate javassist-runtime jar and we shaded only the proxy/runtime
>>> >>> classes?  That way we only repackage the same classes that we
>>> >>> included
>>> >>> for this hack test (e.g.
>>> >>> org.hibernate.bytecode.internal.javassist.proxy.*).
>>> >>>
>>> >>> Early testing results of the hack test look good
>>> >>> (https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).
>>> >>>
>>> >>> Scott
>>> >>>
>>> >>> On 02/11/2016 09:04 PM, Stuart Douglas wrote:
>>> >>>> It depends if you are going to shade all the javassist classes or
>>> >>>> just
>>> >>>> the "javassist.util.proxy" package (not sure if this is actually
>>> >>>> possible with the shade plugin).
>>> >>>>
>>> >>>> The main advantage is that you can upgrade javassist to get fixes to
>>> >>>> issues that affect bytecode generation. So if JDK9 comes out with
>>> >>>> new
>>> >>>> bytecodes that the current version of Javassist does not understand
>>> >>>> then
>>> >>>> upgrading javassist will allow the older version of hibernate to
>>> >>>> work
>>> >>>> with classes compiled against the newer JDK version. If all of
>>> >>>> javassist
>>> >>>> is shaded into hibernate then that version of hibernate will never
>>> >>>> work
>>> >>>> with the newer bytecodes.
>>> >>>>
>>> >>>> I think this is less of an issue if you are still publishing the
>>> >>>> non-Javassist shaded hibernate as well as a shaded version, but if
>>> >>>> the
>>> >>>> only published artifact has javassist shaded in then it may limit
>>> >>>> forward compatibility.
>>> >>>>
>>> >>>> Stuart
>>> >>>>
>>> >>>>
>>> >>>> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
>>> >>>> <mailto:steve at hibernate.org>> wrote:
>>> >>>>
>>> >>>>      Ugh.  That is an awful lot of classes copied over.  What
>>> >>>> exactly was
>>> >>>>      the benefit of this over shading again?  I mean both case lose
>>> >>>> the
>>> >>>>      ability to simply drop in fixes from upstream Javassist.  So
>>> >>>> what
>>> >>>>      does this "clone" approach gain versus shadowing?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>      On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow
>>> >>>> <smarlow at redhat.com
>>> >>>>      <mailto:smarlow at redhat.com>> wrote:
>>> >>>>
>>> >>>>           >>
>>> >>>>           >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>>> >>>>           >>       > Have you considered a 3rd alternative, which is
>>> >>>> to
>>> >>>>          use a custom
>>> >>>>           >>       > ProxyFactory instead of javassists built in
>>> >>>> one?
>>> >>>>           >>       >
>>> >>>>           >>       > AFAIK the main issue is that javassist proxies
>>> >>>>          require access to the
>>> >>>>           >>       >
>>> >>>> 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>>> >>>>          classes. You
>>> >>>>           >>      could
>>> >>>>           >>       > create a similar org.hibernate interface, and a
>>> >>>>          proxy factory
>>> >>>>           >>      that uses
>>> >>>>           >>       > this method handler instead.
>>> >>>>           >>       >
>>> >>>>           >>       > Basically you just copy the code from
>>> >>>>          javassist.util.proxy into
>>> >>>>           >>       > hibernate. This is a relatively small amount of
>>> >>>>          code, so it
>>> >>>>           >>      should not
>>> >>>>           >>       > really add any maintenance burden.
>>> >>>>           >>
>>> >>>>           >>      We talked about this as well via [1].  I
>>> >>>> understand the
>>> >>>>          concept but have
>>> >>>>           >>      not tried doing this.  I like this approach as
>>> >>>> well, if
>>> >>>>          it works.  One
>>> >>>>           >>      of the cons with cloning that Steve Ebersole
>>> >>>> pointed
>>> >>>>          out (see response
>>> >>>>           >>      on Feb-03-2016 9:01am), is that that users lose
>>> >>>> the
>>> >>>>          ability to drop a
>>> >>>>           >>      different version of Javassist in (since we
>>> >>>> maintain
>>> >>>>          our own cloned copy
>>> >>>>           >>      of the Javassist proxy/runtime code).
>>> >>>>           >>
>>> >>>>           >>
>>> >>>>           >> The proxy code is a relatively small part of javassist,
>>> >>>> so
>>> >>>>          unless a bug
>>> >>>>           >> is in the proxy code itself this should not be that big
>>> >>>> a deal.
>>> >>>>           >
>>> >>>>           > Thanks for the encouragement to go down this path.  :)
>>> >>>>           >
>>> >>>>
>>> >>>>          Started a hack attempt at the clone via
>>> >>>>
>>> >>>> https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>>> >>>>          Seems
>>> >>>>          to pass the Hibernate ORM unit tests.
>>> >>>>
>>> >>>>          Scott
>>> >>>>
>>> >>>>          _______________________________________________
>>> >>>>          wildfly-dev mailing list
>>> >>>>          wildfly-dev at lists.jboss.org
>>> >>>> <mailto:wildfly-dev at lists.jboss.org>
>>> >>>>
>>> >>>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>> _______________________________________________
>>> >>> wildfly-dev mailing list
>>> >>> wildfly-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >> _______________________________________________
>>> >> wildfly-dev mailing list
>>> >> wildfly-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>
>>> >>
>>> >
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From jperkins at redhat.com  Fri Feb 26 14:57:30 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 26 Feb 2016 11:57:30 -0800
Subject: [wildfly-dev] WildFly Arquillian 2.0.0
Message-ID: <CADGwLphLVAJ4zN1Ag21T9Am1duqR_OvP1cgNWMQ9YzU2QHg-bQ@mail.gmail.com>

Hello All,
In WildFly Core the embedded standalone server factory was renamed from
EmbeddedStandAloneServerFactory to EmbeddedStandaloneServerFactory. This
caused an issue with wildfly-arquillian-embedded not being able to work
with WildFly 10 (WildFly Core 2). As a result of this WildFly Arquillian
was bumped to version 2.0.0, now requires Java 8 and WIldFly Core 2.

Both 2.x and 1.x versions should work with WildFly 8.x and higher with the
exception of wildfly-arquillian-embedded. This means that if embedded is
required 1.x needs to be used for WildFly 9 where as 2.x needs to be used
for WildFly 10+.

I've released a 2.0.0.Alpha1 version of wildfly-arquillian that can be used
with WildFly 10. We'll move into an Alpha2 after some work is done with the
managed domain container.

-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160226/84c617ad/attachment.html 

From eduardo.santanadasilva at gmail.com  Sat Feb 27 13:29:56 2016
From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=)
Date: Sat, 27 Feb 2016 15:29:56 -0300
Subject: [wildfly-dev] integration-tests scripts failure
Message-ID: <CAFVp3Z7wtv_gBZ34HKPi2KH6CJxb8uWwzu1h6NpwfOSj6RmKPA@mail.gmail.com>

I'm trying to reproduce some issues, but a lot of them could not be done
since integration-tests.sh script is claiming about the latest
wildfly-testsuite-shared on the nexus repository 10.1.0.Final-SNAPSHOT, the
latest over there is: 10.0.0.Alpha1

-- 
__________________________
Eduardo Sant'Ana da Silva - Ph.D.
Researcher / IT Conultant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160227/237035f4/attachment.html 

From dominique.broeglin at gmail.com  Sun Feb 28 05:21:55 2016
From: dominique.broeglin at gmail.com (Dominique Broeglin)
Date: Sun, 28 Feb 2016 11:21:55 +0100
Subject: [wildfly-dev] OSv & Logging subsystem requires org.j.l.LogManager
Message-ID: <1A8C1D37-15D7-468C-B2EC-46E3252EFB0B@gmail.com>

Hello!

I?m trying to run JBoss inside OSv (http://osv.io/ <http://osv.io/>). OSv is a kernel as a library. Meaning the JVM *is* both the kernel and the only process that is launched inside the hypervisor VM. That required a few tricks on OSv?s part to make things work. One of them is that, they wrap the LogManager in their own class:

https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main/java/io/osv/jul/LogManagerWrapper.java <https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main/java/io/osv/jul/LogManagerWrapper.java>

Which obviously triggers an error at that point:

https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java/org/jboss/as/logging/LoggingExtension.java#L147 <https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java/org/jboss/as/logging/LoggingExtension.java#L147>

A few years back there was a thread about : [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager So I have basic understanding of the issue at hand. 

As OSv does not really _replace_ the LogManager with their own but merely wraps it. I thought I could try to just remove the above check and see how far I could go. And actually, wildfly seems to start without an issue. However, I?m not sure it will not cause issues down the road. 

Could somebody help me assert if this wrapping can cause issues ?

Thanks in advance, 
Dominique


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160228/5b5552a2/attachment-0001.html 

From david.lloyd at redhat.com  Sun Feb 28 11:07:26 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Sun, 28 Feb 2016 10:07:26 -0600
Subject: [wildfly-dev] OSv & Logging subsystem requires
	org.j.l.LogManager
In-Reply-To: <1A8C1D37-15D7-468C-B2EC-46E3252EFB0B@gmail.com>
References: <1A8C1D37-15D7-468C-B2EC-46E3252EFB0B@gmail.com>
Message-ID: <56D31B3E.4050409@redhat.com>

I think this should be fine.  In fact IMO we probably should have a 
system property (or something along those lines) which disables this 
check for special cases like this.

On 02/28/2016 04:21 AM, Dominique Broeglin wrote:
> Hello!
>
> I?m trying to run JBoss inside OSv (http://osv.io/ <http://osv.io/>). OSv is a kernel as a library. Meaning the JVM *is* both the kernel and the only process that is launched inside the hypervisor VM. That required a few tricks on OSv?s part to make things work. One of them is that, they wrap the LogManager in their own class:
>
> https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main/java/io/osv/jul/LogManagerWrapper.java <https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main/java/io/osv/jul/LogManagerWrapper.java>
>
> Which obviously triggers an error at that point:
>
> https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java/org/jboss/as/logging/LoggingExtension.java#L147 <https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java/org/jboss/as/logging/LoggingExtension.java#L147>
>
> A few years back there was a thread about : [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager So I have basic understanding of the issue at hand.
>
> As OSv does not really _replace_ the LogManager with their own but merely wraps it. I thought I could try to just remove the above check and see how far I could go. And actually, wildfly seems to start without an issue. However, I?m not sure it will not cause issues down the road.
>
> Could somebody help me assert if this wrapping can cause issues ?
>
> Thanks in advance,
> Dominique
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML