According to ACE_INET_Addr implementation we can not get reply if hostname is
not resolved (just error printout):
```
// Creates a ACE_INET_Addr from a PORT_NUMBER and the remote
// HOST_NAME.
ACE_INET_Addr::ACE_INET_Addr (u_short port_number,
const char host_name[],
So with deeper investigation I learned, that in function
```
// Initializes a ACE_INET_Addr from a PORT_NUMBER and the remote
// HOST_NAME.
int
ACE_INET_Addr::set (u_short port_number,
const char host_name[],
int encode,
int address_fami
Ok, cool. Maybe put a comment in the source since unless you look at the ACE
source this would not be intuitive.
`// ACE will not initialize port if hostname is not resolved.`
[ Full content available at: https://github.com/apache/geode-native/pull/521 ]
This message was relayed via gitbox.apach
@mcmellawatt @kirklund
> Would geode-log4j be an appropriate place to move the classes we need to
> break the dependency on geode-core?
The goal of this PR is to remove geode-core's dependency on log4j-core, so that
users may use a different logging backend (such as logback) more easily. See
`
[ pull request closed by nabarunnag ]
[ Full content available at: https://github.com/apache/geode/pull/4059 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
> @jdeppe-pivotal - I'm ok with removing geode-http-service from the classpath
> in another PR as long as the circular dependencies this PR introduces
> (geode-http-service -> geode-core -> geode-http-service) don't break
> developers IDEs.
Is there a way to *avoid* creating a circular dependen
[ pull request closed by agingade ]
[ Full content available at: https://github.com/apache/geode/pull/4051 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
[ Full content available at: https://github.com/apache/geode/pull/4050 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
[ pull request closed by gesterzhou ]
[ Full content available at: https://github.com/apache/geode/pull/4058 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
This pull request **fixes 4 alerts** when merging
25b980ae332898252e5e223c6e785ffcb26400b0 into
1a1d221c482cd740002d4fadfff56aee92db2b4d - [view on
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-0cf66e1ebfb7bdfd322c44519c0857a4fcb30921)
**fixed alerts:**
* 4 for Non\-synchronized ov
Building examples has required a published Geode tgz and jars. Use
Gradle's `includeBuild` feature to allow mapping to a custom Geode clone
for integration and API testing. Invoke with:
`./gradlew -Dcomposite -PgeodeCompositeDirectory=../geode build`
[ Full content available at: https://github.com
Thanks for comment.
[ Full content available at: https://github.com/apache/geode-native/pull/521 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
@metatype Sorry I missed your comment before merging. I'm working on the next
part which is exactly that: removing the circular dependency.
[ Full content available at: https://github.com/apache/geode/pull/4040 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
This pull request **introduces 1 alert** and **fixes 2** when merging
bb87060ed1a399e4cbb4a3703235ad481125714c into
1ea49f0e22db51f18802064abf5359772a5c91fe - [view on
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-ef4f290b07297cfcd9d9584228d6861bd6b2a9c2)
**new alerts:**
* 1 for Us
[ pull request closed by nabarunnag ]
[ Full content available at: https://github.com/apache/geode/pull/4064 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
out of curiosity, I tried introducing compile error in geode-management, which
is a module that geode-core depends on, and it was not picked up. So does the
"composite" feature only apply to the 3 modules explicitly listed, not their
dependencies?
Also this should be merged to develop, probab
@onichols-pivotal I'll test that more on my side. `-Dcomposite` should pick up
such compile-time errors on all sub-projects of the dependencies we name (an
error in geode-management should cause a problem for geode-core, and therefore
in geode-examples).
[ Full content available at: https://g
oh, it was user error on my part...I was in geode-web-management not
geode-management. It does pick up changes to geode-management just fine :)
[ Full content available at: https://github.com/apache/geode-examples/pull/86 ]
This message was relayed via gitbox.apache.org for
notifications@geode.
This pull request **fixes 4 alerts** when merging
55da9424a12d3e72c3ddafb4a418180142f53fff into
97e1d1907bde63fb0053f5605dbb1113a418e106 - [view on
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-2852d3820255f65073615a351588f471c86a5000)
**fixed alerts:**
* 4 for Non\-synchronized ov
Thanks for the picture @aaronlindsey! I think we are on the same page
regarding the end result. Currently in the GEODE-7177 PR we have moved select
classes which depend on log4j into geode-logging, but now that seems a bit odd
since those should really be in geode-log4j (as they are in this PR
These header changes makes me think that maybe someone's IntelliJ formatting is
setup differently? Do we want these changes?
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
Does AlertinService need to be fully qualified here?
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
Fully qualified?
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
We used `implementation` here before which would have hidden the log4j API from
consumers of geode-core. Is that not what we want in this new model, since we
are now using `api`?
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.
This test doesn't make sense anymore with the new logging model?
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
Probably fully qualified from a move refactor
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
Is this TODO still relevant? If not, can we remove it? If so, can we address
it in this PR or create a follow up ticket and remove the TODO?
[ Full content available at: https://github.com/apache/geode/pull/4003 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.or
27 matches
Mail list logo
